Website Security Vulnerabilities With Examples
Even the most experienced CIO and web security expert must stay vigilant and guard against the bad guys. No one is safe without knowing what to look out for. Here are six of the most common website security vulnerabilities you must protect yourself against along with examples .
The web security vulnerabilities are prioritized depending on exploitability, detectability and impact on software.
Exploitability –
What is needed to exploit the security vulnerability? Highest exploitability when the attack needs only web browser and lowest being advanced programming and tools.
Detectability –
How easy is it to detect the threat? Highest being the information displayed on URL, Form or Error message and lowest being source code.
Impact or Damage –
How much damage will be done if the security vulnerability is exposed or attacked? Highest being complete system crash and lowest being nothing at all.
6 Common Website Security Vulnerabilities
1. SQL Injections
SQL injection is a type of web application security vulnerability in which an attacker attempts to use application code to access or corrupt database content. If successful, this allows the attacker to create, read, update, alter, or delete data stored in the back-end database. SQL injection is one of the most prevalent types of web application security
Injection occurs when the user input is sent to an interpreter as part of command or query and trick the interpreter into executing unintended commands and gives access to unauthorized data.
The SQL command which when executed by web application can also expose the back-end database.vulnerabilities.
Examples:
SQL injection on the Login Page
Logging into an application without having valid credentials.
Valid user Name is available, and password is not available.
Test URL: http://demo.testfire.net/default.aspx
User Name: sjones
Password: 1=1′ or pass123
SQL query created and sent to Interpreter as below
SELECT * FROM Users WHERE User_Name = sjones AND Password = 1=1′ or pass123;
2. Cross Site Scripting (XSS)
Cross Site Scripting is also shortly known as XSS. Cross-site scripting (XSS) targets an application’s users by injecting code, usually a client-side script such as JavaScript, into a web application’s output. The concept of XSS is to manipulate client-side scripts of a web application to execute in the manner desired by the attacker. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface websites or redirect the user to malicious sites.
Attackers can use XSS to execute malicious scripts on the users in this case victim browsers. Since the browser cannot know if the script is trusty or not, the script will be executed, and the attacker can hijack session cookies, deface websites, or redirect the user to an unwanted and malicious websites.
XSS is an attack which allows the attacker to execute the scripts on the victim’s browser.
Examples
1. http://www.testsite.com/home?”alert(“xss”)
The above script when run on a browser, a message box will be displayed if the site is vulnerable to XSS.
The more serious attack can be done if the attacker wants to display or store session cookie.
2. http://demo.testsite.net/search.aspx?txtSearch
The above script when run, the browser will load an invisible frame pointing to http://google.com.
The attack can be made serious by running a malicious script on the browser.
Broken Authentication and Session Management
Broken authentication and session management encompass several security issues, all of them having to do with maintaining the identity of a user. If authentication credentials and session identifiers are not protected at all times, an attacker can hijack an active session and assume the identity of a user. The websites usually create a session cookie and session ID for each valid session, and these cookies contain sensitive data like username, password, etc. When the session is ended either by logout or browser closed abruptly, these cookies should be invalidated i.e. for each session there should be a new cookie.
If the cookies are not invalidated, the sensitive data will exist in the system. For example, a user using a public computer (Cyber Cafe), the cookies of the vulnerable site sits on the system and exposed to an attacker. An attacker uses the same public computer after some time, the sensitive data is compromised.
In the same manner, a user using a public computer, instead of logging off, he closes the browser abruptly. An attacker uses the same system, when browses the same vulnerable site, the previous session of the victim will be opened. The attacker can do whatever he wants to do from stealing profile information, credit card information, etc.
A check should be done to find the strength of the authentication and session management. Keys, session tokens, cookies should be implemented properly without compromising passwords.
Examples
Airline reservation application supports URL rewriting, putting session IDs in the URL:
http://Examplesite.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Sale of tickets to Maldives)
An authenticated user of the site wants to let his friends know about the sale and sends an email across. The friends receive the session ID and can be used to do unauthorized modifications or misuse the saved credit card details.
An application is vulnerable to XSS, by which an attacker can access the session ID and can be used to hijack the session.
Applications timeouts are not set properly. The user uses a public computer and closes the browser instead of logging off and walks away. The attacker uses the same browser some time later, and the session is authenticated.
4. Insecure Direct Object References
Insecure direct object reference is when a web application exposes a reference to an internal implementation object. Internal implementation objects include files, database records, directories and database keys. When an application exposes a reference to one of these objects in a URL, hackers can manipulate it to gain access to a user’s personal data.
It occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key as in URL or as a FORM parameter. The attacker can use this information to access other objects and can create a future attack to access the unauthorized data.
Examples:
Changing “userid” in the following URL can make an attacker to view other user’s information.
http://www.abcsite.com/userid=123 Modified to http://www.defsite.com/userid=124
An attacker can view others information by changing user id value.
5. Security Misconfiguration
A secure configuration must be defined and deployed for the application, frameworks, application server, web server, database server and platform. Security misconfiguration gives hackers access to private data or features and can result in a complete system compromise.
Security Configuration must be defined and deployed for the application, frameworks, application server, web server, database server, and platform. If these are properly configured, an attacker can have unauthorized access to sensitive data or functionality.
Sometimes such flaws result in complete system compromise. Keeping the software up to date is also good security.
Examples
The application server admin console is automatically installed and not removed. Default accounts are not changed. The attacker can log in with default passwords and can gain unauthorized access.
Directory Listing is not disabled on your server. Attacker discovers and can simply list directories to find any file.
6. Cross-Site Request Forgery (CSRF)
CSRF attack is an attack that occurs when a malicious website, email, or program causes a user’s browser to perform an unwanted action on a trusted site for which the user is currently authenticated.
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application.
A link will be sent by the attacker to the victim when the user clicks on the URL when logged into the original website, the data will be stolen from the website.
Examples
The victim is logged into a bank website using valid credentials. He receives mail from an attacker saying “Please click here to donate $1 to cause.”
When the victim clicks on it, a valid request will be created to donate $1 to a particular account.
http://www.abcbank.com/transfer.do?account=cause&amount=1
The attacker captures this request and creates below request and embeds in a button saying “I Support Cause.”
http://www.abcbank.com/transfer.do?account=Attacker&amount=1000
Since the session is authenticated and the request is coming through the bank website, the server would transfer $1000 dollars to the attacker.
Don’t get caught with your guard down. Practice safe website security measures and always be ready to protect yourself, and your company’s future, from an attack that you might never recover from. The best way to tell if your website or server is vulnerable is to conduct regular security audits.
Want to learn how you can protect your website from these common web security vulnerabilities? Here are few simple tips to improve wordpress security right now.