SQL Injection – “Let’s dump the database”

  

What is access control?

Access control is a security technique that can be used to regulate who (or what) can perform attempted actions or access resources in a computing environment.

In context of web application security, it determines whether the user is allowed to carry out the action that they are attempting to perform.

Synonyms: Authorization

Basically, access control enforces a policy where users cannot act outside their intended permissions. It relies on authentication and session management.

Broken Access Control : 

Access controls are designed to regulate user privileges. Failures typically cause unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of user privilege, known as "Broken Access Control" or "Privilege Escalation".

 Broken Access Control ranks 5th in the 2020 OWASP Top 10.

Broken access control can usually be encountered in any application and these are often high-security vulnerabilities. It occurs when an adversary tries to perform certain actions outside his intended permission.

Access control issues are typically not detectable by dynamic vulnerability scanning and static source-code review tools as they require an understanding of how the application is dealing with data. Manual testing is the best way to detect missing or broken access controls. However, there are some Burp Extenders that can be used to detect authorization vulnerabilities.

 

Types of Privilege Escalation:

1)      Horizontal Privilege Escalation: This occurs when a user performs some action or access application's data on behalf of another user, who has the same level of privilege.

2)     Vertical Privilege Escalation: This happens when a user performs some action or gets access to the application's data that should only be available for the high privileged users. (such as Admin or Super Admin). At its most basic, vertical privilege escalation arises where an application does not enforce required protection over sensitive functionality.

Common Privilege escalation vulnerability includes:

1) Privilege Escalation: Insecure parameter in URL- 

When the application allows an attacker to bypass the access control mechanism by modifying the URL parameters,  

Parameter : user-supplied input to used to identify the user/resource in the database. Eg- userID, username

This is also called "Insecure direct object references".

Let’s suppose user "wiener" is logged in to a website. The website has a 'My Account' page which contains API key value, which is sensitive data and nobody else should see. On navigating to My Account page the URL looks something like this: 

https://acb31f3c1e4f81d680a41e9b00180022.web-security-academy.net/my-account?id=wiener

What if the user replaces the id with some other id?

If the application is vulnerable then it will expose account details associated with user "carlos" when navigating to the URL  https://acb31f3c1e4f81d680a41e9b00180022.web-security-academy.net/my-account?id=wiener 

Now if the application is using random numbers instead of predictable id then attack complexity will be high but it can't be considered a sufficient countermeasure. 

This is an example of ‘security by obscurity’.

2) Privilege Escalation: Insecure parameter in the request body – 

This is similar to Privilege Escalation: Insecure parameter in URL. The only difference is that in this case, the application sends identification parameters in the request body.

How to test :

(i) Login to the application and navigate to the vulnerable page.

(ii) Intercept the request and try to look out what parameter is sent in the request.

(iii) Replace ethe parameter value with some other value. 

(iv) If the vulnerability exists, the user will get access to data/resources outside his privilege.

3.)Privilege Escalation: Unauthenticated user -

When an unauthenticated user can access a certain page of the application just by navigating to the absolute URL directly into the browser.

4) Forced browsing-

Forced browsing occurs when the user tries to use resources that are not referenced by the application but are still available. 

For example, a web application can have an admin page, but there is no link to the admin page in any functionality of the website, so just by clicking around, a regular user never gets to the admin page. But if someone directly navigates to the URL, e.g. https://vulnerableweb.com/admin, they might access the admin page if the access control is broken. 

5) CORS misconfiguration - 

Allows unauthorized API access. This vulnerability can be leveraged to steal users' information or force the user to perform unintended actions.

6) Privilege Escalation: JWT manipulation -

JWT token is used for authentication. Tampering JSON Web Token (JWT) access control token may result to elevate privileges or abusing JWT invalidation.

How to prevent Broken Access Control :

Access control vulnerabilities can generally be prevented by applying the following principles:

1) Follow a defense-in-depth approach that uses layered defensive mechanisms to protect systems and data

2) Deny access to functionality by default unless a resource is intended to be publicly accessible.

3) Enforce application-wide mechanisms to implement access control.

4) Implement session tracking mechanism to prevent unauthorized and unauthorized access to sensitive pages/modules of the application.

5) At the code level, make it mandatory for developers to declare the access that is allowed for each resource, and deny access by default.

6) Use an access control list and role-based authentication mechanism. Don’t just hide the Admin function.

7) Disable directory listings, rate-limiting APIs, and authentication or authorization related pages.

8) Store all sensitive information such as userid and username, server-side.

Thanks for reading J 

Feel free to point out any mistakes or let me know if there is anything I should add J 

Keep Learning, Keep growing J