4.5 Authorization Testing

Authorization Testing

4.5.1 Testing Directory Traversal File Include

• Identify injection points that pertain to path traversal, such as HTTP GET and POST parameters that receive a path or a filename as input.

  • Obtain all the links from Burp and look for injecting variables.

  # GET
  cat sitemap_urls.txt | uro |grep -Eo 'https?://[^ ]+\?[^ ]+'
  # POST
  Filter by Method POST & PARAMS (On Burpsuite Order by "Params")

  • Are there unusual file extensions?

• Is it possible to identify cookies used by the web application for the dynamic generation of pages or templates?

• Assess bypassing techniques and identify the extent of path traversal.

  • Is it also possible to include files and scripts located on external website

  • If protocols are accepted as arguments, is it also possible to probe the local filesystem this way ?file=file:///etc/passwd?

(?:\?|&)(\w+)=([^&]*\.(?:jpg|jpeg|png|gif|pdf|doc|docx|xls|xlsx|ppt|pptx|txt|zip|rar|mp3|mp4|wav|mov|avi|json|xml|csv|exe|bin|dll|tar|gz|html|css|js|php))\b

• Try to perform Path Traversal on the server's URL PATH

Evidence:

​

4.5.2 Testing for Bypassing Authorization Schema

• Asses the vertical privileges

  1. Register or generate two users with a higher and a lower privileges.

  2. Establish and maintain two different sessions based on the two different roles.

  3. For every request, change the session identifier from the original to another role’s session identifier and evaluate the responses for each. (Usage of Autorize)

  4. An application will be considered vulnerable if the weaker privileged session contains the same data, or indicate successful operations on higher privileged functions.

• Asses the horizontal privileges.

  1. Register or generate two users with identical privileges.

  2. Establish and keep two different sessions active (one for each user).

  3. For every request, change the relevant parameters and the session identifier from token one to token two and diagnose the responses for each token. (Usage of Autorize)

  4. An application will be considered vulnerable if the responses are the same, contain same private data or indicate successful operation on other users’ resource or data.

• Testing for Special Request Header Handling

  1. Try to test if theres is support of the headers X-Original-URL: /donotexist1 and X-Rewrite-URL: /donotexist2. If they are try use them in order to bypass URLs that might not be blocked for being accessed from the Internet.

  2. Try different headers and values (Burp's Cluster Bomb attack)

• Attempt to switch, change, or access another role: Use tools like Multi-Account container (Firefox Add-on) and Authorize (Burp Suite)

Headers:

X-Forwarded-For: 
X-Forwarded-IP: 
X-Client-IP: 
X-Remote-IP: 
X-Originating-IP: 
X-Host: 
X-Client: 

Values: https://nip.io/

127.0.1
127.1
0.0.0.0
0
0x7f000001
2130706433
3232235521a
3232235777
017700000001
[::]
::
[0:0:0:0:0:ffff:127.0.0.1]
0:0:0:0:0:ffff:127.0.0.1
<COLLABORATOR>

Evidence:

​

4.5.3 Testing for Privilege Escalation

• Identify injection points related to privilege manipulation.

• Fuzz or otherwise attempt to bypass security measures.

Evidence:

​

4.5.4 Testing for Insecure Direct Object References

• Identify points where object references may occur. Look for requests that contain parameters with values such as IDs, function names or files.

Look for ID numbers:

(?:\?|&)(\w+)=\w*\d+\w*\b

• Assess the access control measures and if they’re vulnerable to IDOR. Check if certain users that should not have access to those resources can access them. (Autorize)

• If UUID are used check its version. Because version 1 is based on time stamps you can perform a sandwich attack.

Look for IDs:

(\w+)=[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}

Evidence:

​