10.4 Testing Authentication, Authorization & Session Management

10.4 Testing Authentication, Authorization & Session Management

Authentication, authorization, and session management form the core security controls governing user access in web applications. Flaws within these mechanisms represent high-impact findings during CREST CPSA assessments because they frequently lead to complete account takeover, sensitive data breaches, or horizontal and vertical privilege escalation. Penetration testers must methodically evaluate each stage of the user access lifecycle to verify that access controls are enforced authoritatively on the server.

---

Authentication Testing Methodologies

Authentication is the process of verifying the asserted identity of a user, process, or device. Security testing assesses login mechanisms, credential handling, and account recovery workflows.

+-----------------------------------------------------------------------------+
|                     AUTHENTICATION TESTING ATTACK SURFACE                   |
+-----------------------------------------------------------------------------+
| Vector                    | Observable Behavior / Flaw                      |
+---------------------------+-------------------------------------------------+
| Username Enumeration      | Differential errors, status codes, timing delays|
| Brute-Force & Stuffing    | Missing rate limits, weak lockout, header spoof |
| Password Reset Flows      | Predictable tokens, Referer leak, Host poison   |
| Multi-Factor Auth (MFA)   | Forced browsing, status code tampering, step skip|
+-----------------------------------------------------------------------------+

1. Username Enumeration Testing

Username enumeration allows remote attackers to determine whether a given username or email exists within the system. Testers search for discrepancies in server responses when valid versus invalid usernames are submitted:

• Differential Error Messages: The application returns explicit messages such as Username does not exist versus Incorrect password for user. Secure implementation: The application must return uniform error messages for all failed attempts, such as Invalid username or password.
• Differential HTTP Status Codes: Returning 404 Not Found for invalid users and 401 Unauthorized or 200 OK for valid users.
• Response Body Size & Redirects: Submitting a valid user returns a 200 OK with a form reload of 4,120 bytes, whereas an invalid user returns 3,850 bytes.
• Timing Side-Channel Discrepancies: Modern password hashing algorithms (such as bcrypt, Argon2, or PBKDF2) are intentionally computationally expensive, taking 250–500ms to compute. If an application first checks the database for username existence and terminates immediately when the user is not found, the response returns in ~15ms. Conversely, when a valid username is entered, the server performs the full password hash calculation, taking ~350ms. Attackers measure this timing difference across automated requests to build a verified user list.

[Attacker Request: user="nonexistent"] ---> Server checks DB (User not found) --------------------> Response in 12ms
[Attacker Request: user="admin"]       ---> Server checks DB (Found) -> Computes bcrypt(pwd) -----> Response in 380ms

2. Brute-Force & Credential Stuffing Testing

• Rate Limiting: Testers evaluate whether an endpoint restricts the number of failed login attempts over a given time window (e.g., maximum 5 attempts per minute per IP address or per account).
• Bypassing IP-Based Rate Limiting: Testers evaluate whether rate limits can be circumvented by injecting spoofed proxy headers:

  X-Forwarded-For: 127.0.0.1
  X-Real-IP: 10.0.0.1
  Client-IP: 192.168.1.100
  

• Account Lockout Auditing: Account lockout policies temporarily disable an account after consecutive failed attempts (e.g., 5 attempts lock the account for 30 minutes). While lockout mitigates brute-force attacks, aggressive policies introduce a Denial of Service (DoS) vulnerability, allowing an attacker to systematically lock out every user in the corporate directory. Recommended mitigation: progressive delays (tarpitting) or CAPTCHA challenges rather than permanent account lockouts.

3. Password Reset Mechanism Testing

Password recovery workflows are among the most vulnerable entry points in web applications:

+-----------------------------------------------------------------------------+
|                  HOST HEADER POISONING IN PASSWORD RESETS                   |
+-----------------------------------------------------------------------------+
| 1. Attacker submits reset request for victim@corp.lan:                      |
|    POST /forgot-password HTTP/1.1                                           |
|    Host: attacker-controlled.com                                            |
|    Content-Length: 26                                                       |
|                                                                             |
|    email=victim@corp.lan                                                    |
+-----------------------------------------------------------------------------+
                                      |
                                      v
| 2. Vulnerable server generates valid token 'xyz987' and builds URL:         |
|    link = "https://" + request.headers["Host"] + "/reset?token=" + token    |
+-----------------------------------------------------------------------------+
                                      |
                                      v
| 3. Server emails reset link to victim:                                      |
|    "Click here: https://attacker-controlled.com/reset?token=xyz987"        |
+-----------------------------------------------------------------------------+
                                      |
                                      v
| 4. Victim clicks link -> Attacker web server captures 'xyz987' in logs     |
| 5. Attacker visits https://corp.lan/reset?token=xyz987 and resets password  |
+-----------------------------------------------------------------------------+

• Token Predictability: Inspecting reset tokens to ensure they are not based on predictable algorithms (such as Unix epoch timestamps, MD5 of the email address, or incrementing sequential IDs).
• Token Leakage via Referer Header: If the password reset confirmation page contains external resources (e.g., third-party CSS, analytics scripts, social media links), the user's browser automatically transmits the full current URL—including ?token=secret123—in the Referer header to the third-party domain. Remediation: Enforce Referrer-Policy: no-referrer or store tokens in the body/fragment rather than the query string.
• Host Header Poisoning: When the server dynamically generates the reset URL using the client-supplied HTTP Host header, an attacker can submit a reset request for a victim's email while altering the Host header to an attacker-controlled server. The victim receives a genuine email containing a link pointing to the attacker's server, leaking the valid token upon clicking.

4. Multi-Factor Authentication (MFA) Bypass Testing

• Forced Browsing / Direct Navigation: Navigating directly to /dashboard or /account/profile in the browser immediately after supplying valid primary credentials, skipping the /mfa-verify prompt.
• Parameter Modification: Intercepting MFA validation requests and tampering with request parameters (e.g., changing step=2 to step=3, or adding mfa_completed=true).
• Response Tampering: Intercepting a failed MFA submission response and modifying the server response code and body from HTTP/1.1 401 Unauthorized ({"status": "error"}) to HTTP/1.1 200 OK ({"status": "success"}). If the client application relies on client-side JavaScript routing rather than server-side session checks, the UI unlocks.

---

Authorization Testing Methodologies

Authorization determines whether an authenticated subject possesses permission to access a specific object or perform a requested action. Authorization flaws violate the Principle of Least Privilege.

+-----------------------------------------------------------------------------+
|                        AUTHORIZATION VULNERABILITY MATRIX                   |
+-----------------------------------------------------------------------------+
| Category                   | Direction | Description                        |
+----------------------------+-----------+------------------------------------+
| Horizontal Escalation      | Lateral   | Accessing records belonging to a   |
| (BOLA / IDOR)              | (Peer)    | peer user at identical privilege   |
+----------------------------+-----------+------------------------------------+
| Vertical Escalation        | Upward    | Standard user executes admin       |
| (Privilege Escalation)     | (Role)    | functions or accesses admin APIs   |
+----------------------------+-----------+------------------------------------+
| Missing Function-Level     | Interface | Relying on hidden UI buttons while |
| Access Control             | / API     | leaving API endpoints unprotected  |
+-----------------------------------------------------------------------------+

1. Broken Object Level Authorization (BOLA / IDOR)

Insecure Direct Object References (IDOR), formalized in modern API testing as Broken Object Level Authorization (BOLA), occurs when an application exposes a reference to an internal database object (such as an integer ID, filename, or account number) in an API endpoint or request parameter without validating whether the requesting user owns or has permission to access that object.

# Requesting User 1001's profile (Legitimate)
GET /api/v1/users/1001/billing_records HTTP/1.1
Host: target.lan
Authorization: Bearer <User_1001_Token>

# BOLA Attack: User 1001 tampers parameter to view User 1002's records
GET /api/v1/users/1002/billing_records HTTP/1.1
Host: target.lan
Authorization: Bearer <User_1001_Token>

Testing Methodology for BOLA / IDOR:

1. Provision two distinct user accounts at the identical privilege level: User A and User B.
2. Log in as User B and identify direct object references in URLs, parameters, or JSON payloads (e.g., invoice_id=84920, doc_uuid=f47ac...).
3. Log in as User A and submit requests targeting User B's object identifiers.
4. If User A can view, update, or delete User B's resource, BOLA is confirmed.

2. Vertical Privilege Escalation

Vertical privilege escalation occurs when an unprivileged user gains access to administrative functionality.

• Direct Path Traversal to Administrative Portals: An unprivileged user navigates directly to administrative endpoints (e.g., /admin/users, /api/v1/system/backup, /management/metrics).
• Role Parameter Tampering: Applications that allow clients to define or alter user attributes during registration or profile updates: modifying {"user_id": 50, "role": "user"} to {"user_id": 50, "role": "admin"} or "isAdmin": true.
• HTTP Verb Tampering: Web application security constraints may be defined incorrectly at the web server level. For example, a rule restricts GET /admin/users to administrators, but fails to restrict POST, PUT, or HEAD requests to the same endpoint, allowing unprivileged users to execute actions by substituting the HTTP method.

3. Missing Function-Level Access Control

Occurs when developers hide administrative buttons, menus, or links within the front-end user interface for non-admin users, but fail to implement role checks on the backend API endpoints. If an unprivileged user discovers the URL (e.g., through JavaScript bundle inspection or forced browsing), the backend processes the request without verifying the user's role.

---

Session Management Testing Methodologies

1. Testing for Session Fixation

To audit an application for session fixation vulnerabilities:

+-----------------------------------------------------------------------------+
|                        SESSION FIXATION AUDIT PROCEDURE                     |
+-----------------------------------------------------------------------------+
| Step 1: Browse to login page without authenticating.                        |
|         Observe assigned cookie: Set-Cookie: SID=ALPHA_01                   |
|                                                                             |
| Step 2: Submit valid user credentials in login form.                        |
|         Intercept response in proxy.                                        |
|                                                                             |
| Step 3: Inspect Set-Cookie response header:                                 |
|         - SECURE: Server issues new cookie Set-Cookie: SID=BETA_02          |
|         - VULNERABLE: Server issues NO new cookie; retains SID=ALPHA_01     |
|                                                                             |
| Step 4: If no new cookie is issued, verify if SID=ALPHA_01 now accesses     |
|         protected member pages. If yes -> Session Fixation Confirmed.       |
+-----------------------------------------------------------------------------+

2. Session Invalidation & Termination Auditing

• Logout Invalidation Testing: Many applications implement logout by simply instructing the browser to delete the client-side cookie (e.g., Set-Cookie: session=; expires=Thu, 01 Jan 1970 00:00:00 GMT), but fail to destroy the session record on the server.
  • Audit Test: Capture an authenticated session token in Burp Suite. Click "Logout" in the browser. Using Burp Repeater, re-issue a protected request containing the captured session token. If the server responds with 200 OK and renders user data, the session was not invalidated on the server and remains vulnerable to replay attacks.
• Concurrent Session Enforcement: Auditing whether the application allows an account to maintain multiple concurrent active sessions from different geographic locations or IP addresses, which may indicate missing session controls.
• Idle & Absolute Timeout Verification: Testing whether sessions are terminated following periods of user inactivity (idle timeout) and whether an absolute maximum session duration is enforced regardless of continuous activity.