Burp Suite can test authentication mechanisms by systematically sending crafted requests to identify vulnerabilities.
Let’s see Burp Suite in action. Imagine you’re testing a web application that uses a simple username and password form for login.
Here’s a typical login request intercepted by Burp:
POST /login HTTP/1.1
Host: vulnerable-app.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=alice&password=password123
Burp’s power comes from its ability to manipulate and repeat these requests in various ways. We’ll focus on a few key techniques.
Brute-Forcing Credentials
The most straightforward test is to try common or weak passwords against a known username.
Diagnosis: Use Burp’s "Intruder" tool. Load your intercepted login request. Mark the password parameter as the payload position. Select "Sniper" attack type.
Configuration: In the "Payloads" tab, choose "Simple list" and paste a list of common passwords like: password, 123456, qwerty, admin, Pa$$w0rd.
Execution: Start the attack. Intruder will send a request for each password in your list, substituting it into the password parameter.
Why it works: This enumerates potential credentials by systematically trying a predefined set of values. Look for responses that indicate a successful login (e.g., a redirect to a dashboard, a different status code, or a specific "Welcome" message in the response body) while other attempts fail.
Session Token Analysis
Many applications use session tokens (often in cookies) to maintain user state after login. If these tokens are predictable, weak, or not properly invalidated, an attacker can hijack sessions.
Diagnosis: After logging in as a legitimate user, examine the response for session-related cookies (e.g., JSESSIONID, PHPSESSID, session_token).
Configuration: Use Burp’s "Repeater" tool. Send your logged-in request to Repeater. Then, manually change the session cookie value. Try incrementing it, using common patterns, or generating random values.
Execution: Observe the application’s response. If changing the session token allows you to access another user’s session or bypass authentication, you’ve found a vulnerability.
Why it works: This tests the randomness and unpredictability of session token generation and the server’s validation logic. If the server doesn’t properly verify that the token belongs to the authenticated user, or if tokens can be guessed, it’s a flaw.
Parameter Tampering and Role Manipulation
Sometimes, authentication or authorization logic is flawed, allowing you to change parameters to gain elevated privileges or bypass checks.
Diagnosis: Look for parameters in requests that might indicate user roles, permissions, or access levels. Common places include URL parameters, form fields, or even HTTP headers.
Configuration: Use Burp’s "Repeater." After logging in, send the request to Repeater. Identify a parameter like role=user or isAdmin=0. Manually change it to role=admin or isAdmin=1.
Execution: Send the modified request. If the application grants you administrative access or bypasses a protected resource based on this change, it’s a vulnerability.
Why it works: This exploits the assumption that client-side or easily modifiable parameters accurately reflect server-side security decisions. If the server doesn’t re-validate these on the backend, it can lead to privilege escalation.
Rate Limiting Bypass
Applications often implement rate limiting to prevent brute-force attacks. Testing if these limits are effective is crucial.
Diagnosis: Use Burp’s "Intruder" with a large list of credentials, but this time, focus on the timing of the responses.
Configuration: In Intruder, set up a brute-force attack as described earlier. In the "Options" tab, under "Resource pool," you can configure the number of concurrent requests. To test rate limiting, you’d typically reduce the number of concurrent requests to a low value (e.g., 1 or 2). You might also enable "Grep - Match" to specifically look for "Rate limited" messages in the response.
Execution: Start the attack. Observe how quickly the application starts returning rate-limiting errors or if it continues to allow attempts indefinitely.
Why it works: This tests the robustness of the rate-limiting mechanism. If the application doesn’t correctly enforce limits per IP address or user, or if the limits are too high, brute-force attacks remain feasible.
Authentication Bypass via Parameter Manipulation
Sometimes, simply removing or changing authentication-related parameters can bypass login.
Diagnosis: Intercept a login request.
Configuration: Use Burp’s "Repeater." Send the login request. Then, try removing the username and password parameters entirely. Or, try setting them to null values (username=&password=).
Execution: Send the modified request. If you get a successful login response without providing valid credentials, you’ve found a bypass.
Why it works: This exploits lax input validation on the server. If the application doesn’t explicitly check for the presence and validity of credentials, it might fall back to a default state or an authenticated session.
By systematically applying these techniques, you can uncover a wide range of authentication vulnerabilities that might otherwise go unnoticed. The next challenge you’ll likely encounter is dealing with multi-factor authentication mechanisms.