the-web-application-hackers-handbook

154 Chapter 5 n Bypassing Client-Side Controls
Handling Client-Side Data Securely
As you have seen, the core security problem with web applications arises because
client-side components and user input are outside the server’s direct control.
The client, and all the data received from it, is inherently untrustworthy.
Transmitting Data Via the Client
Many applications leave themselves exposed because they transmit critical data
such as product prices and discount rates via the client in an unsafe manner.
If possible, applications should avoid transmitting this kind of data via the
client. In virtually any conceivable scenario, it is possible to hold such data on
the server and reference it directly from server-side logic when needed. For
example, an application that receives users’ orders for various products should
allow users to submit a product code and quantity and look up the price of each
requested product in a server-side database. There is no need for users to submit
the prices of items back to the server. Even where an application offers different
prices or discounts to different users, there is no need to depart from this model.
Prices can be held within the database on a per-user basis, and discount rates
can be stored in user profiles or even session objects. The application already
possesses, server-side, all the information it needs to calculate the price of a
specific product for a specific user. It must. Otherwise, it would be unable, on
the insecure model, to store this price in a hidden form field.
If developers decide they have no alternative but to transmit critical data via
the client, the data should be signed and/or encrypted to prevent user tampering.
If this course of action is taken, there are two important pitfalls to avoid:
n Some ways of using signed or encrypted data may be vulnerable to
replay attacks. For example, if the product price is encrypted before
being stored in a hidden field, it may be possible to copy the encrypted
price of a cheaper product and submit it in place of the original price.
To prevent this attack, the application needs to include sufficient context
within the encrypted data to prevent it from being replayed in a different
context. For example, the application could concatenate the product
code and price, encrypt the result as a single item, and then validate
that the encrypted string submitted with an order actually matches the
product being ordered.
n If users know and/or control the plaintext value of encrypted strings that
are sent to them, they may be able to mount various cryptographic attacks
to discover the encryption key the server is using. Having done this, they
can encrypt arbitrary values and fully circumvent the protection offered
by the solution.