RockByte Security's Top 10 Web Application Vulnerabilities

Mehul Panchal

These are the top 10 vulnerabilities that I look for when I pentest a Web Application. I will be dumping all that I have learned about these vulnerabilities and their fixes in this and subsequent posts.

Here's the list of all those vulnerabilities, so that you won't have to scroll down to know them all:

  1. Broken Access Control
  2. JSON Web Token (JWT)
  3. NoSQL injection
  4. File Upload
  5. SSRF
  6. XXE
  7. Broken Autentication
  8. XSS
  9. Sensitive Data Exposure
  10. Business Logic Failure

1. Broken Access Control

Role-Based Access Control comes into play where there's a hierarchy in an application. Just like any organisation's hierarchy, applications have their own set of roles. These roles allow users to have privileges.

Each role has its own set of privileges in an application. There's two types of Broken Access Control: Horizontal and Vertical.

To perform Horizontal BAC, you need to perform actions that another user, of same role as your user, can perform.

To perform Vertical BAC, you need to perform actions that another user, of a higher role than your user, can perform.

That's the simplest BAC explanation I could ever give. Here's few pages that you can to go down deeper into BAC:

https://owasp.org/Top10/A01_2021-Broken_Access_Control/

https://owasp.org/www-community/Broken_Access_Control

https://hackerone.com/reports/1323406

https://hackerone.com/reports/493324

2. JSON Web Token (JWT)

JSON Web tokens can be used in a wide range of functionality where integrity is a main requirement. Most common use is in Authorization of a user. Authorizing a user into an application is a task that requires rigid parameters, so that the user can only perform the tasks that it's supposed to.

JWT tokens have below structure:

[Signature information].[DATA].[Signature]

Signature information: It defines the algorithm that has been used to generate the Signature.

DATA: This part of JWT has the data that contains information about the user and the session.

The Signature is always created with the algorithm specified in the Signature information and a secret key which is stored on the server. The server verifies the Signature of the JWT token by using this secret key into the reverse algorithm and ensures the integrity of data.

There are a lot of attacks which could be performed to misuse JWT tokens. All the type of attacks and their recipes are mentioned in this page: https://book.hacktricks.xyz/pentesting-web/hacking-jwt-json-web-tokens

Have fun ripping apart the tokens.

3. NoSQL injection

There are various types of NoSQL databases. Most commonly used is MongoDB. But the techniques to attack these databases is almost similar.

Unlike regular SQL queries, NoSQL queries are constructed using JSON objects:

{
    object: String, 
    q: Expression, 
    fields: Array of String, 
    groupBy: Array of String, 
    aggregation: Object mapping fields to aggregate functions 
}

This simple query retrieves the name and salary of all employees in position of "Sales Manager":

{ 
    "object": "employees",
    "q": { 
        "position" : "Sales Manager"  
    },
    "fields": ["name", "salary"] 
}

Queries can also be used to compare an object's fields to constant values using common comparison operators. For example, to retrieve all fields for all employees under the age of 25, you can use the following query:

{ 
    "object": "employees",
    "q": {
        "age": { "$lt" : 25 } 
    }  
}

In an application, normal authentication would look like:

{
    "username": "admin",
    "password": "password"
}

An example of successful exploitation of that authentication would be:

{
    "username": {"$in": ["admin", "administrator", "superadmin"]},
    "password": {"$ne": ""}
}

All possible attack scenarios are explained by below references:

https://book.hacktricks.xyz/pentesting-web/nosql-injection

https://portswigger.net/web-security/nosql-injection

4. File Upload

File upload functionlities are most likely to be vulnerable in a Web Application, due to a lot of factors involved such as file name, extension, content, etc...

The first thing I do when I see a file upload functionality is that I check for what file names, extensions and contents are allowed. The best way to deal with this is to always use a wordlist to fuzz parameters of the endpoint.

After fuzzing, you should be able to figure out what is allowed and what is not. And according to that, it's good to conclude whether there's a way in which you could somehow upload a file with malicious content.

Now the malicious uploaded file doesn't have to be executing at the moment, because this very file could be used as a backdoor and can be used successfully to further exploit the application server.

Here's few pages that you can refer to:

https://portswigger.net/web-security/file-upload

https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload

5. SSRF

Backend's of modern applications usually communicate with third-party API's to exchange data, to fulfill the requirements of the application's functionality as a whole.

If this type of communication is somehow exposed by the backend to the frontend of the application, then it could be possible to manipulate the connection and make the backend to connect to attacker's server instead of the supposed connection to third-party API.

This connection to attacker's server could be used by the attacker to maliciously use the third-party service to exchange data or possibly perform remote code execution on the backend. This could compromise the whole application.

Here's the few pages for references:

https://portswigger.net/web-security/ssrf

https://owasp.org/www-community/attacks/Server_Side_Request_Forgery

6. XXE

When an XML document containing malicious External Entity gets parsed through XML parser, it executes according to attacker's intent, then it's called XML External Entity vulnerability.

This attack could lead to several types of impacts including Server Side Request Forgery (SSRF) and Remote Code Execution (RCE).

Below is an example of non-malicious XML:

<?xml  version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE note>
<note>
<to>John</to>
<from>Doe</from>
<heading>TODO</heading>
<body>Send an email to Donald</body>
</note>

Below is an example of malicious XML:

<?xml  version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM  "file:///dev/random" >]>
<foo>&xxe;</foo>

An XML document with correct syntax is called "Well Formed". An XML document validated against a DTD (Document Type Definition) is both "Well Formed" and "Valid". The DTD should be defined to the parser by the application developer. If not properly defined, then it could lead to XXE attack.

Here's few pages for reference:

https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing

https://www.hackerone.com/knowledge-center/xxe-complete-guide-impact-examples-and-prevention

 

7. Broken Authentication

Entrypoints of most applications is an authentication mechanism which let's legitimate users use session of the application after using their credentials.

But when this mechanism is not properly implemented, then the application is vulnerable to a lot of authentication attacks including use Default Credentials, broken MFA and Brute-force attacks.

The impact of this vulnerability depends on the domain of the application, as this may allow money laundering, social security fraud, and identity theft, or disclose legally protected highly sensitive information.

Here's few pages for reference:

https://portswigger.net/web-security/authentication

https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication

8. XSS

Cross-site Scripting (XSS) attack involves executing arbitrary Javascript code on victim's browser. This could help attacker to steal victim's account information or to perform actions on behalf of victim in an application.

There are 3 types of XSS:

  • Reflected Cross-site Scripting
  • Stored Cross-site Scripting
  • DOM-based Cross-site Scripting
Reflected XSS

Attacker crafts and sends an exploit URL to the victim using social engineering. This exploit URL contains malicious characters with arbitrary javascript code in the parameter's value. Now this arbitrary javascript code get's executed when victim clicks that URL.

Stored XSS

The attacker crafts an exploit similar to Reflected XSS but instead of sending exploit URL to victim, the attacker inserts it into an information storing function in the application or third-party application which is retrievable through another function of the application. When victim uses the retrieve function, the malicious Javascript executes.

DOM-based XSS

DOM stands for Document Object Model of browsers. DOM has a source and a sink. A DOM source serves function of retrieving data from user's input and DOM sink serves the function of processing the retrieved data. Javascript takes data from sources and passes it to the sink. This attack happens when an attacker inserts malicious characters and arbitrary Javascript code into DOM source, and this code is later processed by DOM sink and the arbitrary Javascript code is executed.

Here's few pages for reference:

https://portswigger.net/web-security/cross-site-scripting

https://owasp.org/www-community/attacks/xss/

9. Sensitive Data Exposure

Everyone has to do their own research about where to look for this bug class, because every web application is made for a specific business logic.

All it takes to figure out where to look, is understanding the business logic. But some of the places are generally usable for every type of web application:

- Social Media

- Search engines: https://github.com/T43cr0wl3r/OSINT-RECON/blob/master/Dorking.md

- Quick Hits: https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/quickhits.txt

- Github - Employee's/Contractor's property (Social Media, Portfolio etc...)

- Other OSINT methods

- Web App Errors

- AI dumps: (i.e. ChatGPT share leaks)

- WayBack Machine

10. Business Logic Failure

Business Logic Flaws are simply failure of the application to follow the rules of business. This bug class is diverse and huge enough to understand without an example.

So, here's an example:

An e-commerce bookstore web application is designed to handle discount code. For example, there's a discount run by the company for 20% discount. An attacker tries to use the same discount code twice on total cart value of $1000, on the first try, the discount code works as expected and gives the final price to be $800.

Then, the attacker applies the discount code again and the application gives discount of 20% again, so the final price becomes $640. In this example, the application fails to check whether the discount code has been already used on the cart.

Here's few pages for reference:

https://portswigger.net/web-security/logic-flaws

https://owasp.org/www-community/vulnerabilities/Business_logic_vulnerability

Conclusion

These vulnerabilities are a huge challenge for any organization looking forward to make their web applications secure. Hopefully, this post by me provided you an insight on Top 10 vulnerabilities in this era of web applications. Thank you for reading and stay tuned on my 𝕏 for more posts and content like this.