Similar to authentication, there are various types of attacks you can launch to take advantage of a web app's authorization weaknesses. One type of attack is called parameter pollution. In parameter pollution, you supply multiple instances of the same parameter name in an HTTP request. Web apps that do not properly handle these duplicate parameters may enable you to modify values or trigger errors in the application.
For example, assume that there is a search functionality submitted through a GET request, typically in the format:
http://site.example/?search=treadmill
You can add a second instance of the search parameter to the request:
http://site.example/?search=treadmill&search
The web app's validation routines, if configured poorly, may only test the last occurrence of a parameter. Since the last parameter's value is empty, it throws that parameter out, but keeps the first parameter. The result might simply be results for "treadmill" or the page might return an error.
While the preceding example doesn't reveal a direct vulnerability, applying parameter pollution to authorization mechanisms does. For example, assume the app accepts a security token in a POST request in order for users to sign in to the app's management portal. The format might be something like this:
http://site.example/?token=<user token>&portalID=<victim portal ID>
In parameter pollution, the attacker would try to append a second instance of portalID with their own malicious portal, and replace the token value with their own token ID:
http://site.example/?token=<attacker token>&portalID=<attacker portal ID>&portalID=<victim portal ID>
If the web app is vulnerable, it might only check the first instance of portalID and operate on the second using the attacker's token, logging them in to the portal.
Another attack that can leverage authorization weaknesses is insecure direct object references. A direct object reference is a reference to the actual name of a system object that the application uses. If you manipulate a parameter that directly references an object, you can craft that parameter to grant yourself access to other objects you're unauthorized to access. For example, a call to an SQL database may request account information by directly referencing the acctname parameter. You can replace the acctname value with a different account name or number, which could grant you access to that account if the object reference is insecure.
