Handling Client-Side Data Securely
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 altogether. 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 different 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 of the information it needs to calculate the price of a specific product for a specific user — it must, otherwise it would not be able, 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, then the data should be signed and/or encrypted to prevent tampering by the user. If this course of action is taken, then there are two important pitfalls to avoid:
■ 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 this 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.
■ If users know and/or control the plaintext value of encrypted strings that are sent to them, then they may be able to mount various cryptographic attacks to discover the encryption key being used by the server. Having done this, they can encrypt arbitrary values and fully circumvent the protection offered by the solution.
In applications running on the ASP.NET platform, it is advisable to never store any customized data within the ViewState, and certainly never anything sensitive that you would not want to be displayed on-screen to users. The option to enable the ViewState MAC should always be activated.
Validating Client-Generated Data
Data generated on the client and transmitted to the server cannot in principle be validated securely on the client:
■Lightweight client-side controls like HTML form fields and JavaScript can be very trivially circumvented, and provide zero assurance about the input received by the server.
■ Controls implemented in thick-client components are sometimes more difficult to circumvent, but this may merely slow down an attacker for a short period.
■ Using heavily obfuscated or packed client-side code provides additional obstacles; however, a determined attacker will always be able to overcome these. (A point of comparison in other areas is the use of DRM technologies to prevent users from copying digital media files. Many companies have invested very heavily in these client-side controls, and each new solution is usually broken within a short interval.)
The only secure way to validate client-generated data is on the server side of the application. Every item of data received from the client should be regarded as tainted and potentially malicious.
Logging and Alerting
When mechanisms such as length limits and JavaScript-based validation are employed by an application to enhance performance and usability, these should be integrated with server-side intrusion detection defenses. The server-side logic which performs validation of client-submitted data should be aware of the validation that has already occurred on the client side. If data that would have been blocked by client-side validation is received, the application may infer that a user is actively circumventing this validation, and so is likely to be malicious. Anomalies should be logged and, if appropriate, application administrators should be alerted in real time so that they can monitor any attempted attack and take suitable action as required. The application may also actively defend itself by terminating the user’s session or even suspending his account.
NEXT is..Attacking Authentication………,,.,.,.
