In this session, I will discuss how to do testing on Authorization Testing that refers to OWASP.
There are 4 checklists for testing
1. Testing Directory Traversal File Include
Summary
Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read or write files that are not intended to be accessible. In particular situations, it could be possible to execute arbitrary code or system commands.
Traditionally, web servers and web applications implement authentication mechanisms to control access to files and resources. Web servers try to confine users’ files inside a “root directory” or “web document root”, which represents a physical directory on the file system. Users have to consider this directory as the base directory into the hierarchical structure of the web application.
- Identify injection points that pertain to path traversal.
- Assess bypassing techniques and identify the extent of path traversal.
How to Test ?
Access this lab if you want to try your hand at Path Traversal
Try clicking on view details on Products Images and will be redirected to the following view
Now, Try looking at the Request on Burpsuite
you can try changing the url from /image?filename=26.jpg to /image?filename=../../../etc/passwd
Note: Don’t forget to send to Repeater
and Boom, you getting Root…
2. Testing for Bypassing Authorization Schema
Summary
This kind of test focuses on verifying how the authorization schema has been implemented for each role or privilege to get access to reserved functions and resources.
For every specific role the tester holds during the assessment and for every function and request that the application executes during the post-authentication phase, it is necessary to verify:
- Is it possible to access that resource even if the user is not authenticated?
- Is it possible to access that resource after the log-out?
- Is it possible to access functions and resources that should be accessible to a user that holds a different role or privilege?
Try to access the application as an administrative user and track all the administrative functions.
- Is it possible to access administrative functions if the tester is logged in as a non-admin user?
- Is it possible to use these administrative functions as a user with a different role and for whom that action should be denied?
How to Test ?
In this example we will demonstrate a technique to bypass the authentication of a vulnerable login page using SQL injection.
This tutorial uses an exercise from the “Mutillidae” training tool taken from OWASP’s Broken Web Application Project. Find out how to download, install and use this project.
And Open Login Form
I tried using ‘ on the login form and tried to access the login, see what happens
Enter some appropriate syntax to modify the SQL query into the “Name” input. In this example we used ‘ or 1=1 — . This causes the application to perform the query.
SELECT * FROM users WHERE username = ‘ ‘ OR 1=1 — ‘ AND password = ‘foo’ Because the comment sequence ( — ) causes the remainder of the query to be ignored, this is equivalent to:
SELECT * FROM users WHERE username = ‘ ‘ OR 1=1
and Now, you getting Root (admin)
3. Testing for Privilege Escalation
Summary
This section describes the issue of escalating privileges from one stage to another. During this phase, the tester should verify that it is not possible for a user to modify their privileges or roles inside the application in ways that could allow privilege escalation attacks.
Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation or changes should have been prevented by the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than those intended by the developer or system administrator.
- Identify injection points related to privilege manipulation.
- Fuzz or otherwise attempt to bypass security measures.
How to Test ?
Click on User Info to geeting Information about it
This information about your account
You can edit uid=24 to uid=1, and see the difference
this uid is information about Admin profile
4. Testing for Insecure Direct Object References
Summary
Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
- Identify points where object references may occur.
- Assess the access control measures and if they’re vulnerable to IDOR.
How to Test ?
Click on User Info to geeting Information about it
Try to change parameter ID from UID=24 to UID=20
and gain access to others’ property