OWASP- Top 10 Vulnerabilities in web applications

Introduction

OWASP (Open web application security project) community helps organizations develop secure applications. They come up with standards, freeware tools and conferences that help organizations as well as researchers. OWASP top 10 is the list of top 10 application vulnerabilities along with the risk, impact, and countermeasures. The list is usually refreshed in every 3-4 years.

The same will be discussed along with a few examples which will help budding pentesters to help understand these vulnerabilities in applications and test the same. Let’s start!  

1. Injection

Introduction

“Injection attacks occur when the user is able to input untrusted data tricking the application/system to execute unintended commands.”

Injections can be – SQL queries, PHP queries, LDAP queries and OS commands. Before we jump to the examples: Let’s ponder on a few things:

Q: What to inject?

A: Queries, OS commands, codes and URL argument manipulations.

Q: Where to inject?

A: Wherever a user input is required or use can modify data. It can be a text box, username/password field, feedback fields, comment field, URL etc.

Q: Why to inject?

A: To check if the application is vulnerable.

Example

Below are 2 textboxes – first name and last name. Once the input has been entered and GO is clicked, the input is displayed on the screen.

Normal input

Now let us insert some HTML tags and see what happens.

The HTML tags are processed and we have the output displayed. This ensures that the user’s input has not been validated and just assumes to be trusted and processed. We have identified an HTML injection case now. Similarly PHP injection, OS command injection, iFrame injection, LDAP injection etc. can be tested for.

Countermeasure

• Input sanitization: Implement whitelisting approach at server side for what all can be accepted.
• Use of safe API’s and parametrized queries.

2. Broken Authentication

Introduction

“Broken authentication occurs when the application mismanages session related information such that the user’s identity gets compromised. The information can be in the form of session cookies, passwords, secret keys etc.”

The aim here is to either get into someone else’s session or use a session which has been ended by the user or steal session related information. Let’s check a few scenarios. 

Example

1. Press the back button after logout to see if you can get into the previous session.
2. Try to hit the URL directly after logging out to check if you are able to access that page.
3. Check for the presence of session-related information in the URLs. Try manipulating them to check if you are able to ride someone else’s session.
4. Try finding the credentials in the source code. Right click on the page and hit view source. Sometimes coders hardcode the credentials for easy access which sometimes remain there unidentified.

 Countermeasure

• Use of multifactor authentication
• Session isolation
• Idle session timeouts
• Using secured cookies

3. Sensitive data exposure

Introduction

“Attackers can sniff or modify the sensitive data if not handled securely by the application. A few examples include use if weak encryption keys, use of weak TLS.”

The goal is to identify sensitive data bits and exploit them.

Example

• Weak crypto algorithms are susceptible to attacks and give out sensitive data. In the below example the username and password are sent using base64 encoding. 

The request can be easily intercepted and decoded. The attacker can also launch SQL attacks by gaining such knowledge. Check the password in the below intercepted and decoded request. You can use BurpSuite for interception and decoding.

• Various banking applications have disabled the screenshot capability as it might contain sensitive data.

Countermeasure

• Encrypt all data in transit and at rest.
• Use secure protocols and algorithms.
• Disable caching of responses with sensitive data. Hackers might get the cached copies and steal the information from them.

4. XML External Entities (XXE)

Introduction

“An application is vulnerable to XXE attacks if it enabled users to upload a malicious XML which further exploits the vulnerable code and/or dependencies.”

This can be used to execute code, steal data and perform other malicious tasks. 

Example

The below webpage enabled the user to upload an XML file and that will be processed/parsed for the data and displayed below on the same page. The user submits world and that gets processed.

If the user submits something like the below-submitted XML, that gets processed by the parser and response will change.

Various websites which request large data from the user share EXCEL files with the fields. The user is asked to fill the excel sheet and run a macro to convert the file into an XML file which the user uploads. This technique was previously followed for filing the India tax return. In such cases, do check whether the uploaded XML is being sanitized or rejected before getting parsed.

Countermeasure

• Avoid serialization of sensitive data
• Implement whitelisting approach at server side to prevent malicious XML upload.
• Use of WAF to detect and block XXE.
• Code review 

5. Broken Access control

Introduction

“Broken access control occurs if a user is able to access unauthorized resources, this can be access to restricted pages, database, directories etc.”

Applications have various account types depending on the users: admins, operators and reporting groups etc. One common problem is that the developers restrict the privileges just on the UI side and not on the server side. If exploited, each user can have admin rights.

Example

Below are the examples of 2 users “Jsmith and admin user”. Jsmith does not have rights to edit the users but an admin has the rights for that. This can be verified by the privileges shown ion the left side for each user. 

The vulnerability is that the user jsmith can directly hit the edit users page’s URL and edit the users, even though he is not the admin. 

Countermeasure

• Invalidate tokens and cookies after logout.
• Forced login/logout after a password change.
• Server side resource restriction e.g. directories.
• Restrict access to all resources basis roles.

6. Security misconfigurations

Introduction

Developers and IT staff ensure functionality and not the security. The configurations are done on the application server, DB server, proxy, applications and other devices need to be in line with the security requirements. Most of the security requirements get missed unless identified by experts or hackers.

Examples of these security misconfigurations are weak passwords, default passwords, default scripts stored on the servers, default directories, default error messages etc. 

Example

• Directory listing available

• Default error messages by the server can attackers getting to fingerprint the server abd version and launch targeted attacks.

Countermeasure

• Have a hardening process in place for both hardware and applications. Do ensure that defaults are changed.
• Install only the required features from a framework.
• Review the security of the configurations at fixed intervals.

7. Cross Site Scripting (XSS)

Introduction

Cross-site scripting occurs when an attacker is able to insert untrusted data/scripts into a web page. The data/scripts inserted by the attackers get executed in the browser can steal users data, deface websites etc.

XSS is of 3 types:

• Reflected
• Stored
• DOM-based   

Example

• A page with search field: User enters a JavaScript as below and as soon as the search is pressed the input script gets processed and the pop up is displayed on the screen. The script can now be changed as per need to steal data and deface websites. This is the example of a reflected XSS.

• Below is the example of a stored XSS – The web page has a comment field and the user's comments are stored and displayed. A user can enter malicious scripts in the comments field and every time the page gets loaded the script will get executed.

Countermeasure

• Output encoding and escaping untrusted characters.
• Enabling Content-Security-policy (CSP)

8. Insecure Deserialization

Introduction

Some of the applications save data on the client side and they may be using object serialization. Applications which rely on the client to maintain state may allow tampering of serialized data. This is a new entry in the list and is difficult to exploit. 

Example

Altering the serialized objects in the cookies for privilege escalation.

X: x :{ z: z:”NAME”: r:”USER”} -->> Normal cookie

X: x :{ z: z:”NAME”: r:”ADMIN”} -->> Altered cookie object

Countermeasure

• Encryption of the serialized data.
• Deserializers to run with least privileges

9. Using Components with known vulnerabilities

Introduction

If any components with known vulnerabilities are used by the application, this may lead to security breaches or server takeover. The components can be coding frameworks, libraries, vulnerable functions, network frameworks etc.

Example

1. Use of vulnerable PHP version
2. Out-dated kernel version – Linux
3. Unpatched windows. 
4. Vulnerable jQuery version

Getting the jQuery version used

Reference: https://domstorm.skepticfx.com/modules?id=529bbe6e125fac0000000003

Countermeasure

• Frequent patching process.
• Subscribe to various forums which share the latest vulnerabilities along with the CVE numbers and mitigation techniques/fixes. Check if the vulnerability affects the devices/software in your inventory and fix them.

10. Insufficient logging and monitoring

Introduction

With all the countermeasures in place attacks still happen and that gets noticed only after an incident has happened. If undetected the attackers could have compromised the systems long back and gained persistence. 

To ensure the malicious intent of the attackers gets noticed beforehand, it is essential to log all the activity and monitor it for any suspicious behavior. 

Example

1. Too many failed login attempts from a particular source.
2. Too many requests from a particular source at an extremely fast/slow/fixed rate could be a DOS attempt. DO check and act.
3. Junk traffic
4. Spikes in traffic pattern when not expected.

Countermeasure

• 24x7 monitoring of application traffic and log analysis.
• Effective Security Incident and response procedures to be in place and practice. 

Conclusion

OWASP top 10 vulnerabilities serve as a benchmark as well as helps management identify the severity of the vulnerabilities in a more accurate way. These along with a few other checkpoints can be used to develop a benchmark for the application security testing for an organization. Few other checks can be:

• Clickjacking
• Buffer overflow
• Insecure API’s

Below is a comparison of top 10 vulnerabilities of 2013 vs 2017. Do check for all of them as some of them may have trickled down the list but still be present.

Reference: https://www.owasp.org/