[Part 1] Web Application Security Testing: Top 10 Risks & Solutions

Mantra Labs organized a conference at their Bangalore office, where their seasoned Test Engineer Rijin Raj discussed the current top 10 web application security risks in the evolving digital world. He elaborated on vulnerabilities with examples and offered suggestions to avoid them.

The Open Web Application Security Project (OWASP) is an international organization for enhancing the security of web applications. The top 10 web application security risks worldwide are:

1. Injection
2. Broken authentication and session management
3. Cross-site scripting
4. Indirect object security reference
5. Security misconfiguration

In the second part of this series, we will cover the following web application security testing parameters:

1. Sensitive data exposure
2. Missing function level access control
3. Cross-site forgery
4. Using components with known vulnerabilities: Heartbleed and Shellshock
5. Unvalidated redirects and forwards

To get an idea about how hackers are exploiting web applications and prevailing security/penetration bugs, you can go through the exploit database’s list. Now let’s delve deep into the risks and web application security testing measures.

1. Injection

Here, an attacker sends rogue content to a web application interpreter resulting in executing authorized commands. The most common forms of code injection attacks are SQL Injection ( or SQLi). An SQLi attack sends malformed code into the database server, leading to exposure of your data. This style of attack is so simple that anyone with access to the internet can do it. In fact, SQLi scripts are available for download. 

How is SQLi or Injection attack done?

The attacker enters characters — “” into the search field and presses the button. It leads to an error page that displays more information than required. The following example shows a badly and insecurely programmed application that is not capable of handling SQL Injections. 

Just a few illegal characters with a little sniffing around leads the hacker to this string: “‘ union select password from users;”. He can then implement this finding to harvest usernames and passwords from the database. This is just one basic way to exploit application databases.

Commonly used tools for detecting & preventing SQL Injection attacks

SQLmap: It is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking-over of database servers. It is commonly used in Kali-linux.

After finding a vulnerable page you can find database by typing:

sqlmap –u (url) –dbs

Tip: You can use the Hackers Arise guide on how to use SQLmap.

For web application security testing practice, you can use the following websites:

• http://www.shumka.com/shumka-at-50/news/index.php?id=847
• http://waytogonatural.com/product_detail.php?ID=4526

You can also find SQL vulnerable websites on your own. You just have to look for:

• php?id=(any Number)
• login.php?id=(any number)
• index.php?id=(any number)

Also, go through these examples of SQLi attacks: blind SQL Injection attack, SQL Injection vulnerability.

2. Broken authentication and session management

Incorrect implementation of authentication schemes and session management can allow unauthorized users to assume identities of valid users.

Broken Authentication and Session Management attacks are anonymous attacks with an intention to try and retrieve passwords, user account information, IDs and other details.

Key Points to check if you are vulnerable:

1. Unprotected user authentication credentials while storing using hashing or encryption.
2. Possibility of guessing or overwriting credentials because of weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
3. Exposed Session IDs in the URL (e.g., URL rewriting).
4. Session IDs are vulnerable to session fixation attacks.
5. Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, lack of proper invalidation during logout.
6. Passwords, session IDs, and other credentials are sent over unencrypted connections.
7. Session IDs aren’t rotated after successful login.

Examples of broken authentication attack scenarios

Scenario #1

Airline reservations application supports URL rewriting, putting session IDs in the URL. 

http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii

An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.

Scenario #2

An application’s timeouts aren’t set properly. A User uses a public computer to access a site. Instead of selecting “logout” the user simply closes the browser tab and walks away. Attacker uses the same browser an hour later, and that browser is still authenticated.

Scenario #3

Insider or external attacker gains access to the system’s password database. User passwords are not properly hashed, exposing every users’ password to the attacker.

Check vulnerability to ‘Sensitive Data exposure’

1. Are you storing any crucial data in clear text long term, including backups of this data?
2. Are you using any old / weak cryptographic algorithms?
3. Check if you’re transmitting any of the data in clear text, internally or externally? Internet traffic is especially dangerous.
4. Are weak crypto keys generated, or is proper key management or rotation missing?
5. Are any browser security directives or headers missing while providing sensitive data to the browser? (Nikto)

Web application security testing and prevention from Sensitive data exposure

1. Make sure you encrypt all sensitive data .
2. Don’t store sensitive data unnecessarily. Discard it as soon as possible. No one can steal the data that you don’t have, right?
3. Ensure using strong standard algorithms and strong keys.
4. Make sure proper key management is in place.
5. Ensure storing passwords with powerful password protection algorithms such as bcrypt, PBKDF2, or scrypt.
6. Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data.

How to protect your application against broken authentication and session management?

Password strength:

• Define minimum size and complexity. Complexity depends on the usage of combinations of alphabetic, numeric, and/or non-alphanumeric characters.
• Change password periodically
• Prevent reusing previous passwords.

Password use:

• Restrict to a small, finite number of login attempts per unit of time and log repeated failed login attempts.
• System should not indicate whether it was the username or password that was wrong if a login  attempt fails.

Password change controls:

• Ask users to provide both their old and new password while changing their password.
• If your system emails forgotten passwords to users, ask users to re-authenticate whenever they’re changing their email address. Otherwise, an attacker who has won temporary access to their session (e.g. by walking up to their computer while the actual user is logged in) can simply change their email address and request an email for ‘forgotten password”.

Password storage:

• Store passwords in either hashed or encrypted form.
• Use encryption whenever plain text password is required.

Session ID protection:

• Protect the entire user session via SSL.
• Never include Session ID in the URL as they can be cached by the browser.
• Session IDs should be long, complicated, random numbers that are impossible to guess.
• Change Session IDs frequently during a session to reduce how long a session ID is valid. One should also change Session IDs when switching to SSL, authenticating or other major transitions.

Browser caching:

• Never submit authentication and session data as part of a GET. Always use POST method.
• Always mark authentication pages with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser and backup to the login page and resubmit the previously typed in credentials.

Also, refer to these examples of broken authentication and session management: Bad 2FA activation flow, Coursera application loophole.

3. Cross-site scripting

This happens when a browser unknowingly executes scripts to hijack sessions or redirect to a rogue site.

Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application uses unvalidated or unencoded user input within the output it generates.

By leveraging XSS, an attacker does not target a victim directly. Instead, he exploits a vulnerability within a website or web application that the victim would visit; essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser. There are basically two types of XSS:

1. Stored XSS
2. Reflected XSS

Stored XSS

• A Stored Cross-site Scripting vulnerability occurs when the malicious user can store an attack which will be called at a later time upon some other unknown user. 
• The storage of a method could involve a database, or a wiki, or blog. The attack executes when the unknowing user encounters the attacker’s malicious stored program. The stored method not only has the problem of incorrect checking for input validation, but also for output validation. If you’re sanitizing data during input, you should also check it for output processes. By checking and validating the output data, you can also uncover unknown issues during the input validation process.

Reflected XSS

• The malicious user, once discovering a field within a website or web application holding XSS vulnerability, crafts a way to execute something malicious to some unknown user. This gives a chance to Reflected XSS vulnerabilities. Here, an unknown user is directed to a XSS vulnerable web application executing the attack.
• The attacker crafts the attack using  a series of url parameters that are sent via a url. The malicious user then sends his/her malicious url with the url parameters to unknowing users. This is typically sent by email, instant messages, blogs or forums, or any other possible methods.

How to test for XSS injection vulnerabilities?

You can determine if a web-based application is vulnerable to XSS attacks very easily. Take a current parameter that is sent in the HTTP GET request and modify it. Take for example the following request in the browser address URL bar. This url will take a name parameter that you enter in a textbox and print something on the page. Like “Hello George, thank you for coming to my site” http://www.yoursite.com/index.html?name=george 

Now, modify it so as to add an additional information to the parameter. For example try entering something similar to the following request in the browser address URL bar.

http://www.yoursite.com/index.html?name=<script>alert(‘You just found a XSS vulnerability’)</script> 

If this pops up an alert message box stating “You just found a XSS vulnerability”, then you know this parameter is vulnerable to XSS attacks. I.e. you’ve not validated the parameter name and it is allowing anything to be processed as a name, including a malicious script that is injected into the parameter passed in. 

Basically what is occurring is normally where the name George would be entered on the page the </script></script> message is instead being written to the dynamic page.

More on XSS vulnerability and examples — hackersonlineclub.com

You can use Zaproxy, a freeware tool for web application security testing. Also, you can use Burp Suite and Beef for XSS vulnerability testing.

4. Indirect object security reference

An attacker can access a reference to a file or directory and manipulate that reference to gain unauthorized access to other objects (unless an access control check is in place).

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. 

Vulnerability to insecure direct object references

1. For direct references to restricted resources, does the application fail to verify that the user is authorized to access the exact requested resource?
2. If the reference is an indirect reference, does the mapping to the direct reference fail to limit the values to those authorized for the current user?

How to test insecure direct object references?

For this category of web application security testing, a Tester first needs to map out all locations in the application where user input is used to reference objects directly (e.g. database rows, files, application pages, etc.). Next, the tester should modify the parameter value for reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.

The best way to test insecure direct object references is — take at least two users to cover different owned objects and functions. For example, take two users with each having access to different objects (such as purchase information, private messages, etc.), and (if relevant) users with different privileges (for example administrator users). Now see whether there are direct references to application functionality. By having multiple users the tester can save valuable testing time in guessing different object names as he can attempt to access objects that belong to the other user.

Examples of insecure direct object references

The value of a parameter directly retrieves a database record. 

Sample request: http://foo.bar/somepage?invoice=12345

• In this case, the value of the invoice parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
• Since the value of invoice goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. 
• To test for this case the tester should obtain the identifier of an invoice belonging to a di