OFFENSIVE | DEFENSIVE | WIKI | ABOUT

<<



GENERAL INFO
::: BYPASS HIGH PERMISSIONS FUNCTIONS

1. Inspect the source code of the application. [manual review] devs normally forget to add access controls.
2. Perform directory enumeration. Try administrator/admin endpoints. 
3. Check for robots.txt to check what other options/sites you are allowed to access.
4. Check if exist posts, messages by users, etc. Those users can be used to enumerate or attempt for different behavior.

NOTES:
	
1. Use dev-tools to modify parameters like cookies, URL's, etc. in order to check results via WEB. Same results as burpsuite, 
it can change behavior. 
2. Analyze responses, really important to use the application with and without authentication to log the requests/responses to 
analyze the data. IMPORTANT!



IDOR | INSECURE DIRECT OBJECT REFERENCES
DESCRIPTION: Arises when an application uses user-supplied input to access objects directly. 

FFUF or Burpsuite can be used. (community edition can be hard)

SAMPLE: https://machetevault/machete?_number=1234
	
NOTE:  "1234" can be changed manually and possible it will be different results. SNIPER or CLUSTERBOMB ATTACKS!
Using FFUF, you just need to change the _number value as the parameter to FUZZ. 

SAMPLE: https://machetevault/machete?_number=FUZZ	



PARAMETERS PROVIDING ACCESS
DESCRIPTION:  Some tokens, parameters could change the behavior of the application regarding what can be accessed. 

0. Manual inspection is needed. [burpsuite / dev-tools]	
1. Check if exist any cookie, token, etc. that is providing autorization/access ? TRUE / FALSE

SAMPLE: Cookie: session=4Jpqa8iPxAB5ckq5lP2A4zP4oswZFuZM ; Admin=True

2. Test session tokens, cookies, etc. is the control in place by roles ? Edit manually. [burpsuite / dev-tools]	
3. Change users, numbers, symbols... check if exist some horizontal privilege escalation that can be accomplished. 
4. If comments section available, enumerate users, post a comment and check how it behaves. 

SAMPLE: GET /my-account?id=carlos 
	


URL-BASED [X-Original-Url] HEADER
NOTES:

1. Inspect requests using burpsuite.
2. Check if activity is client or server-side ? [dev-tools browser]
	
How to test if backend is using the X-Original-URL header as part of the action ?

SAMPLE REQUEST:

REQUEST	
	
GET /vuln_endpoint HTTP/2
Host: machetevault.com
Cookie: session=I9glIXHonYMJpBHmvZFelIaiS

RESPONSE
	
HTTP/2 403 Forbidden
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 15

"Access denied"

Previous sample can help to understand how to test it, two steps:

1. Change request URL to only "/".
2. C1. Add header X-Original-Url: /null
3. URL and header can merge data. However, X-Original-Url header does not accept parameters.

.C1. 
	
RESPONSE
	
HTTP/2 404 Not Found
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 11

"Not Found"

First response, we got "Access denied" meaning the vuln_endpoint was not allowed. However, after adding the header "X-Original-Url" 
you can manually set the endpoint/URL to try, it will overwrite the URL to use. Second response, we got "Not Found". So, it means 
that possible the backend is processing the URL using this header as it is changing behavior/response.

Enumerate possible endpoints and try it.
	


PROTOCOL HTTP BROKEN ACCESS [circumvented]
It is when the HTTP method can be altered to get expected results as it is the parameter acting for access control, for example, you 
change the HTTP method from POST to POSTX or GET, etc. 

NOTE: Important to check,

1. Exist any parameter to test for broken access control ?
2. Exist some cookies to test ? SESSIONID ?
3. Exist any authorized function that you can access ?
4. What is the HTTP method used ? POST/GET/POSTX ?

EXPLOITATION STEPS:

Most using [burpsuite > repeater]
	
1. Need to find an authenticated valid function.
2. Need to test if the parameters are vulnerable.
3. Need to change the cookie between authenticated and non-authenticated to check differences.
4. Need to change between HTTP methods. [GET/POST/POSTX/PUT]



MULTI-STEP BROKEN ACCESS
SAMPLE: action=create&confirmed=true&username=USER

Sometimes the authentication forms has some kind of multi-step validation, but, is that doing something ?

1. Test if the validation is doing something when changing value, TRUE/FALSE.
2. Test if the validation is actually validating or if it can by by-passed changing other values.

NOTE: Same techniques can be used, the big difference is to test if the validation mechanism present actually works.



REFERER BROKEN ACCESS CONTROL
All previous techniques can be attempted, it is basically missing the referer header. 

1. Header can be added.
2. Change referer parameters options. 
	
	

GO BACK