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.

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:

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