Post 2: Authentication Testing in Web Applications

Authentication is where users are supposed to prove who they are — but for pentesters, it’s also where web apps often fail the hardest. Broken authentication is one of the most common ways into a web application.

This guide walks you through everything you need to know: what to test, how to test it, tools, and real-world examples.

  1. Why Authentication Matters in Web Pentesting
  2. Common Authentication Mechanisms
  3. Testing for Login Bypasses
  4. Brute-Forcing Logins
  5. Password Reset and Recovery Testing
  6. Multi-Factor Authentication (MFA) Weaknesses
  7. Practical Tips and Tools

If you can log in as another user — especially an admin — you’ve effectively taken over the application. This can lead to:

  • Privilege escalation
  • Data exposure
  • Account takeovers
  • Full RCE (if admin panel allows file uploads or command execution)

You’ll commonly face:

  • Form-based login
    POSTs credentials to a server endpoint
    (e.g., /login, /authenticate.php)
  • Basic Auth
    Browser-level login using Authorization: Basic header
  • Token-Based Auth
    Usually JWT, stored in cookies or headers
  • Multi-step flows
    Login → OTP or CAPTCHA → Dashboard

Try injecting into the username or password fields:

' OR '1'='1
admin' --
admin" -- 

If the app isn’t properly sanitizing input, it may log you in without needing a valid password.

Test using Burp Repeater — inspect the request and inject into parameters.

Apps sometimes check only for certain conditions, like:

POST /login HTTP/1.1
username=admin&role=user&password=wrongpass

Try changing role=user to role=admin or manipulating hidden fields in the form.

admin@domain.com vs Admin@domain.com

Some apps incorrectly handle case comparison — test both variations.

Try adding duplicate parameters:

POST /login HTTP/1.1
username=admin&username=guest&password=pass123

Web servers may parse one and the app parses another — leading to bypass.

If there’s no account lockout or CAPTCHA, try brute-forcing.

hydra -l admin -P rockyou.txt http-post-form "/login:username=^USER^&password=^PASS^:Invalid login"
  • Replace the POST path and failure message with the actual values
  • Use Burp Suite to capture and test the request manually first
  1. Send request to Intruder
  2. Position username and/or password
  3. Use a wordlist (e.g., rockyou.txt)
  4. Look at response length or status code to find valid creds

This is often where the real magic happens.

  • Predictable tokens or codes
  • Email enumeration
  • IDOR (Insecure Direct Object Reference) in reset links
  • Missing password reset confirmation
  • Changing someone else’s password

Example attack:

GET /reset?token=abcdef12345

Try incrementing or guessing the token, or using tokens from another user.

Even if MFA is in place, test for:

  • Bypass via missing MFA check (e.g., switch to a different endpoint post-login)
  • Flawed backup code or SMS-based recovery
  • Forced re-login flows that forget to enforce MFA
  • Can you change request methods? (e.g., GET instead of POST)
  • Are tokens predictable?
  • Is rate-limiting present?
  • Are there any hidden fields in the login form?
  • Can you replay a valid login session?
ToolPurpose
Burp SuiteManual testing, token replay, brute-force
HydraAutomated brute-forcing
WfuzzParameter fuzzing
SecListsWordlists for brute-forcing
  1. Find a login page at /admin/login.php
  2. Try SQLi login bypass with ' OR 1=1--
  3. Try common creds: admin:admin, admin:password
  4. If failed, capture request in Burp → send to Intruder
  5. Run brute-force with rockyou.txt
  6. Use successful creds to explore the app further

Post 3: SQL Injection (Manual + Automated)
We’ll cover:

  • Manual SQLi testing
  • Extracting data without sqlmap
  • Using sqlmap for fast exploitation
  • Bypasses, WAF evasion, and real-world examples

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top