First Line of Defense for Web Applications – Part 2
Hello everyone, as promised I am back with the next post on input validation series for web applications. Knowledge is power right :). So knowing what all things to validate when you start your web project can save you a lot of headache down the road. So here are some of most important aspects on input validation every developer should be aware of.
What should you validate?
All user controlled input should be treated malicious unless proven otherwise. There are three major categories you must validate to protect your web application.
1. Request object
This is the biggest and most important category of things to validate. When an HTTP request is made, the Request object retrieves all the values from the client browser. These are passed to the server. All of the following collections should be validated by the application on server side before consuming the information. Members of these collections are 100% user controlled.
| Request.Cookies | The values of cookies sent in the HTTP request |
| Request.Form | The values of form elements in the HTTP request body |
| Request.QueryString | The values of variables in the HTTP query string |
The members of Request.ServerVariables are not completely user controlled, but some items in this collection take user input. This collection retrieves the values of predetermined environment variables and request header information. These are the variables which take in some degree of user input, presenting potential vulnerabilities:
| Request.ServerVariables | The values of predetermined environment variables |
|
· HTTP_<HeaderName> · SERVER_NAME · URL · REMOTE_ADDR · REMOTE_HOST · REMOTE_USER |
For example,Request.ServerVariables ("HTTP_REFERER")is used many times by attackers for spoofing. Applications consuming this variable without validation may fall into a trap and process a malicious request that appears to originate from a trusted URL.
2. Registry entries
Many applications use the registry to store configuration and sensitive application data. Registry contents should always be treated as untrusted, user-modifiable data; the contents should always be validated before use. In fact, an application should perform input validation whenever data is being read or written to the registry.
3. Assemblies
Consider this simple scenario: One assembly, A, references and calls another assembly, B.
How can you ensure that, at run time, assembly A calls the original assembly B and not a malicious Trojan horse assembly named as “B” by an attacker? You need a way to verify the assemblies that are called within the application. The answer to this problem is “Strong Naming”. If you assign a public key to your assembly, it is considered "strongly named." Other assemblies that reference yours will use the “stronger” four-part name of your assembly. The strong name for assembly B would look like this:
<%@assembly name='B, Version=1.0.0.0, Culture=neutral,PublicKeyToken=2d7adc3047e7238d'%>
You should refer to assemblies using a "public key token," not the full public key. This token is like a thumbprint of the public key.
At load time, besides the normal signature checks designed to watch for unauthorized modification of the assembly's binaries, the loader will ensure that the public key in B.DLL matches the one recorded in A.DLL. This protects the links between the assemblies to ensure that B is B. An attacker now needs to discover the private key part of the RSA key pair that the original author used to sign the assemblies.
In the next post, I will talk about a very interesting way of exploiting a weakly coded web application and also we will explore different input validation strategies from a development perspective.
So stay tuned………
Cheers,
Anmol Malhotra
Security Consultant, ACE Services
https://blogs.msdn.com/anmolm
Comments
Anonymous
October 22, 2007
PingBack from http://internet.blogfeedsworld.com/?p=19933Anonymous
November 13, 2007
There are lots of security principles which one should be aware of while developing software but at the