Attacker purchasing something from e-store when attempting to tamper with requests and change the transaction amount value. What type of attack is this? How to prevent this kind of attack as the bank and merchants?

3 Answers 3


This is a Parameter Tampering attack. Emphasis mine:

The Web Parameter Tampering attack is based on the manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc. Usually, this information is stored in cookies, hidden form fields, or URL Query Strings, and is used to increase application functionality and control.

You can prevent this type of attack by not storing sensitive information client side. For example, you could calculate the price server side each time it is displayed or used. Any attempt at altering quantities would result in the new price calculation remaining accurate.

If you want to validate quantity too, for example if you are limiting the number of products a user can buy, then you should also validate this server side.


This is an attack on the integrity of your information, depending on how it's orchestrated it might be considered a man-in-the-middle attack or request tampering.

Some common techniques to ensure integrity:

Server side validation

For example, if it's an online checkout then pass the list of products and calculate the total server side rather than sending just a total. In the case of a client side payment, make a server side request to the payment processor to verify the total.

Signing the data

Basically you encrypt your data using a secret key and send the cipher-text along with the message, you can then decrypt the data on the other end using your secret key and if they match then the message can't have been changed. If you're implementing a scheme like this from scratch there's some nuances you need to be aware of such as techniques to prevent a replay attack. I recommend using an established implementation rather than creating something yourself, for example some web frameworks have signed cookies or signed form data functionality.


If the threat is from a man-in-the-middle rather than the user themselves (eg. the man-in-the-middle changing the shipping address) then TLS addresses this issue pretty effectively.

  • I think that part about signing the data text is a bit confusing. Generally you encrypt the hash, not the entire message. If you're encrypting the entire message you really don't need to send the unencrypted message as anyone who could change the encrypted could easily change the clear-text. Commented Apr 22, 2015 at 3:29
  • I was trying to explain it at a low level in simple terms. Obviously it's usually more pragmatic to either only send the cypher-text or to sign the hash, but you don't inherently have to use a hash. I updated my answer to use a higher level explanation any way.
    – thexacre
    Commented Apr 22, 2015 at 3:37
  • And almost every known "checksum/hash" implementation in use by third party payment gateways have been flawed for years... They usually rely on a short shared secret that can be brute forced :(
    – wireghoul
    Commented Jan 11, 2017 at 23:30

Usually referred to as payment bypass. A checksum based approach is often used where request details are hashed alongside a secret value on the merchant side and then validated on the payment processor side. Unfortunately a large number of these systems that I have observed in production do this incorrectly. I did a presentation on this at BH Asia last year the video is on YouTube and the code is on my github, just google for solutum cumulus mediocris.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .