Mitigation Techniques

Solving URL manipulation problems takes planning. Different techniques can be used in different situations. The best solution is to avoid putting parameters into a query string (or hidden form field).

When parameters need to be sent from a client to a server, they should be accompanied by a valid session token. The session token may also be a parameter, or a cookie. Session tokens have their own special security considerations described previously. In the example above, the application should not make changes to the account without first checking if the user associated with the session has permission to edit the account specified by the parameter "accountnumber". The script that processes a credit to an account cannot assume that access control decisions were made on previous application pages. Parameters should never be operated on unless the application can independently validate they were bound for and are authorized to be acted on.

However, a second form of tampering is also evident in the example. Notice that the creditamount is increased from 1 to 999999999. Imagine that the user doesn't tamper with the accountnumber but only with the amount. He may be crediting his own account with a very large sum instead of $1. Clearly this is a parameter that should simply not be present in the URL.

There are two reasons why a parameter should not be a URL (or in a form as a hidden field). The above example illustrates one reason - the parameter is one the user should not be able to set the value of. The second is if a parameter is one the user should not be able to see the value of. Passwords are a good example of the latter. Users's should not even see their own passwords in a URL because someone may be standing behind them and because browsers record URL histories. See Browser History Attack.

If a sensitive parameter cannot be removed from a URL, it must be cryptographically protected. Cryptographic protection can be implemented in one of two ways. The better method is to encrypt an entire query string (or all hidden form field values). This technique both prevents a user from setting the value and from seeing the value.

A second form of cryptographic protection is to add an additional parameter whose value is an MD5 digest of the URL query string (or hidden form fields) More details of this technique are described above in the section "HTML Form Field Manipulation". This method does not prevent a user from seeing a value, but it does prevent him from changing the value. 

[[https://www.cobalt.io/blog/parameter-tampering-vulnerability-using-3-different-approaches|Parameter Tampering Vulnerability Using 3 Different Approaches]]

[[https://www.techtarget.com/searchsecurity/definition/parameter-tampering|parameter tampering ]]

[[https://www.imperva.com/learn/application-security/parameter-tampering/|Parameter Tampering]]

[[https://beaglesecurity.com/blog/vulnerability/parameter-tampering.html|Parameter Tampering]]

[[https://infosecwriteups.com/what-is-parameter-tampering-5b1beb12c5ba|What is Parameter Tampering]]

[[https://book.hacktricks.xyz/pentesting-web/parameter-pollution|Parameter Pollution]]

[[https://qualitrix.com/blog/testing-web-applications-for-security-vulnerabilities/| Web Applications Testing for Security Vulnerabilities ]]

[[https://www.acunetix.com/blog/whitepaper-http-parameter-pollution/|
How to Detect HTTP Parameter Pollution Attacks
]]

[[https://www.easytechjunkie.com/what-is-parameter-tampering.htm|
What is Parameter Tampering?
]]

[[https://blackbatsec.medium.com/bug-bounty-advanced-manual-penetration-testing-leading-to-price-manipulation-vulnerability-d935a3a5ddf6|Bug Bounty — Advanced Manual Penetration Testing Leading to Price Manipulation Vulnerability]]

[[https://www.cgisecurity.com/owasp/html/ch11s04.html|Parameter Manipulation. Preventing Common Problems ]]