Hello! Let's continue our exploration of authorization flaws.
In the last lesson, we focused on Insecure Direct Object References (IDORs), where we exploited parameters that were direct identifiers for data objects, like a user ID or a file ID. We learned to change id=123 to id=124 to access data that wasn't ours.
Today, we will broaden that attack surface. We'll move beyond just object IDs and learn how to manipulate any request parameter that influences authorization logic. This could be a hidden form field, a value within a session token, or even the way parameters are structured in a request. The goal remains the same: bypass authorization checks to access functionality or data you shouldn't have and, in many cases, impersonate other users.
This lesson covers the learning outcome: Manipulate request parameters to bypass authorization checks and impersonate other users. We will investigate several key techniques:
- Directly tampering with parameters that define roles or permissions.
- Exploiting Mass Assignment to inject privileged parameters.
- Using HTTP Parameter Pollution (HPP) to confuse an application's backend.
- Modifying claims within JSON Web Tokens (JWTs) to escalate privileges.
1. From IDOR to Broader Parameter Tampering
While IDORs are a specific type of horizontal privilege escalation (accessing another user's data at the same privilege level), parameter tampering can also lead to vertical privilege escalation (gaining admin-level access).
The key insight is that many applications trust client-side parameters not just for identifying what you want to access, but also for defining who you are and what you're allowed to do.
Broken Access Control | Complete Guide
To understand the fundamentals of authorization bypass, let's watch selections from the "Broken Access Control | Complete Guide" video by security researcher Rana Khalil. This will clearly differentiate between horizontal and vertical privilege escalation and show how simple parameter changes can lead to both.
Watch the following segments: Types of Broken Access Control (10:03 - 13:30): Pay attention to the distinction between horizontal privilege escalation (like the IDORs we saw last lesson) and vertical privilege escalation, where a regular user gains admin functionality. The video shows a clear example of changing a parameter like admin=false to admin=true. Modifying Parameters (17:01 - 17:24): This short clip reinforces the key point that these vulnerable parameters can be visible in the URL or hidden in the request body, which you'll find using Burp Suite.
The simplest form of this attack is finding a parameter like role=user or isAdmin=false in a hidden form field, a cookie, or the request body, and simply changing its value to role=admin or isAdmin=true. This might seem too simple to work, but it's a surprisingly common finding in web applications.
2. Mass Assignment: Injecting Unseen Parameters
What if the application doesn't send a parameter like isAdmin in the request? You might still be able to exploit it. Mass Assignment vulnerabilities occur when a web framework automatically binds multiple request parameters to variables or object properties. If the framework doesn't distinguish between parameters that are supposed to be user-editable and those that aren't, an attacker can sometimes "assign" values to internal, privileged properties.
Broken Access Control Tutorial: Hacking Feedback Forms
The video 'Broken Access Control Tutorial: Hacking Feedback Forms' by Medusa provides an excellent, practical demonstration of finding and exploiting a mass assignment vulnerability.
Watch these sections to see how a tester discovers and exploits this vulnerability: Discovering the Clue (01:39 - 02:23): The key discovery is seeing a user_id field in the server's response, even though it wasn't in the original request. This is a strong indicator that the backend object has this property. The Exploit (02:23 - 04:55): The video demonstrates creating two accounts and then, from the attacker's account, injecting the user_id parameter into the request body with the victim's ID. This allows the attacker to submit feedback on behalf of the victim. Real-World Example (04:55 - 07:16): This part discusses a real HackerOne report where a similar vulnerability allowed an attacker to change the hacker_username parameter in a feedback form, leading to an IDOR. This shows the direct relevance to bug bounty hunting.
The methodology for finding mass assignment is:
- Map the application and identify all API endpoints that create or update data (e.g., user registration, profile updates, submitting content).
- Carefully examine the server's responses for any interesting properties or fields that weren't in your request.
- Hypothesize that you can set these properties by adding them to your next request.
- Craft a new request, injecting the new parameter (e.g.,
"isAdmin": true,"role": "admin","account_credit": 9999) and observe the outcome.
3. HTTP Parameter Pollution (HPP): Confusing the Backend
What happens if you send the same parameter twice in a single request?https://example.com/transfer?amount=1&to=victim&from=attacker&to=attacker
The answer depends entirely on the backend technology. Some frameworks will use the first instance (to=victim), some will use the last (to=attacker), and others will concatenate them (to=victim,attacker). This ambiguity creates an attack vector known as HTTP Parameter Pollution (HPP).
Testing for HTTP Parameter Pollution
Let's turn to the OWASP Web Security Testing Guide for a formal explanation of HPP and how to test for it.
Read the following sections from the article: Summary: This introduces the core concept of HPP. Expected Behavior by Application Server: This table is critical. It shows how different technologies (ASP.NET, PHP, Tomcat/JSP) handle duplicate parameters. Your Computer Science background will help you appreciate that this vulnerability is rooted in implementation differences between frameworks. Authentication Bypass: Read this subsection for a powerful real-world example of how HPP was used to take over a Blogger blog by providing the victim's ID first (for the security check) and the attacker's ID second (for the ownership change action). How to Test: Briefly review the server-side testing methodology. It provides a structured way to probe for HPP vulnerabilities.
HPP is powerful because it can bypass security controls that are split from the business logic. For example, a Web Application Firewall (WAF) or a security middleware might inspect the first instance of a parameter for malicious input, while the application's business logic uses the last instance to perform its action. By putting a benign value in the first parameter and a malicious payload in the second, you can sometimes bypass the filter.
Test your understanding!
You are testing a money transfer function. The request is POST /transfer with a body of to=bob&amount=10. The backend is running on PHP/Apache. You suspect a WAF is blocking requests where the to parameter is admin.
How could you use HPP to potentially bypass this WAF and send money to the admin account?
Show answer
Based on the OWASP table, PHP/Apache uses the last occurrence of a parameter. A WAF might only inspect the first. You could craft a request like:
to=bob&amount=10&to=admin
The WAF might inspect to=bob, see that it's a valid username, and allow the request. The PHP backend, however, would only see the last instance, to=admin, and process the transfer to the admin account.
4. Manipulating JSON Web Tokens (JWTs)
Many modern applications use JSON Web Tokens (JWTs) for session management. A JWT is a self-contained token that can hold user information, including authorization claims. Since these tokens are sent with every authenticated request, manipulating their contents is a primary goal for an attacker.
To understand how to attack JWTs, we first need to understand how they work. The PortSwigger Web Security Academy provides the definitive guide.
This is a dense but critical topic. Read the following sections: What are JWTs?: Understand the three parts of a JWT: header, payload, and signature. Pay close attention to the payload, as this is where claims like "sub":"carlos" and "role":"blog_author" are stored. Exploiting flawed JWT signature verification: This covers two classic attacks. The first is when a developer accidentally uses decode() instead of verify(), allowing you to change the payload freely. The second is the alg:none attack, where you tell the server there is no signature to check. Brute-forcing secret keys: If a weak secret key is used (e.g., 'secret123'), you can use a tool like hashcat to find it. Once you have the key, you can forge tokens with any payload you want, such as "username":"admin". JWT header parameter injections: This covers advanced attacks where you manipulate header parameters like jwk, jku, or kid to trick the server into using a key that you control to verify the signature. This gives you complete control over the payload.
Exploiting JWTs is a direct form of parameter manipulation. The entire token is a parameter, and the claims within its payload are sub-parameters. By modifying claims like sub (subject/username) or custom fields like role or isAdmin, you can directly impersonate other users or escalate your privileges. The security of the entire system rests on the server's ability to validate the token's signature. If you can bypass that validation or get the secret key, you can create any valid token you want.
Conclusion
In this lesson, we expanded our view of authorization bypass beyond simple IDORs. We've seen that any piece of data sent from the client that influences a security decision is a potential vulnerability.
Key Takeaways:
- Vertical Privilege Escalation: Look for hidden parameters, cookies, or JWT claims that define a user's role (e.g.,
isAdmin,role) and try to change them. - Mass Assignment: Be suspicious of properties that appear in server responses but not in your requests. Try to inject them into write operations (
POST,PUT) to set internal, privileged attributes. - HTTP Parameter Pollution (HPP): Understand how your target's backend framework handles duplicate parameters. Use this knowledge to bypass input validation or confuse application logic.
- JWT Manipulation: Always analyze JWTs. If the signature validation is weak, nonexistent, or uses a crackable secret key, you can forge tokens to impersonate any user and claim any role.
Next Lesson Preview:
So far, we have focused on manipulating parameters sent to known endpoints. But what if the most sensitive functionality isn't linked from anywhere in the application? In our next lesson, "Use forced browsing techniques to access unauthenticated administrative or sensitive endpoints," we will learn how to discover and access hidden pages and directories that developers thought were unreachable.