First Line of Defense for Web Applications – Part 3

  • Makale

Precaution: Are you consuming Unexpected Input

Technology is developing fast and web programming languages are coming up with features or ways to ease the job of our developers. Although it brings a smile on developers face, there is a flip side to this. Attackers are exploiting these shortcuts to pass unexpected input in the applications and exploiting the applications. Let’s look at Request () Object which retrieves the values that the client browser passed to the server during an HTTP request.

Interestingly, all variables can be accessed directly by calling Request(variable) without the collection name. In this case, the Web server searches the collections in the following order:

· QueryString

· Form

· Cookies

· ClientCertificate

· ServerVariables

Now this is where it gets dangerous. If a variable with the same name exists in more than one collection, the Request object returns the first instance that the object encounters.

For example, a web application may implement the following authorization checks:

If Request(“Admin”) =”True” Then

Do administrative work

Else

Normal User Work

If the developer of the application sets a variable in the cookie, such as Admin=Yes, then the application will check for the value of this Request object whenever the application has to process admin functionality.

The code should look something like Request.Cookies(“Admin”).  However, if the developer loosely codes the thing, and uses a shortcut like Request(“Admin”) then now as stated earlier, the Request object will search for a match in QueryString, Form, Cookies, ClientCertificate and ServerVariables, in that order. The first match found dictates the value.

From an attacker perspective, a simple payload would bypass this and exploit the application.

https://www.vulnerablecom/abc.aspx?URL=Admin

Here Value from Querystring overrides or takes precedence over cookies object.

Input Validation Strategies

Before we start building a defence against the bad guys, we need to clearly understand some basic concepts of security design and architecture. Security requires some measure of paranoia—we must assume all foreign data entering an application is malicious.  Therefore, all foreign data should be validated before consuming and should be encoded when echoing back to the user.  This paranoia is a key part of developing secure applications.

There are two basic strategies for validating input.  Either we can look for known values in the input we are expecting to receive from the user (white list) or we can look for unknown list of values which we are not expecting to receive from the user (black list). These strategies are applicable to other security domains in addition to web applications. For example, when configuring a firewall you can either accept traffic only on specific ports & specific IP address OR you can write many rejection rules which will reject traffic on all unwanted ports and IP addresses.

Black List Approach a.k.a Exclusions list

In this approach, the developer tries to imagine all the bad input that may find its way to her application, and then rejects all these specific inputs.  All other data is accepted.  These are just a few of the inputs she will need to look out for:

User Input Expected: First Name

Regular Expression: (<|<|%3C)(%20|\s)*(script|applet|embed|))

The black list strategy is a weak protection mechanism because you cannot brain storm all the bad characters attackers will use for a particular attack. We all know security is an ever changing landscape. Black list comes heavily dependent on attacker’s next moves and therefore has to be continuously updated and changed.  As new attack techniques come out, this list becomes outdated and requires constant monitoring.

White List Approach aka Inclusions list

The white list strategy compares foreign user input to specific input that will be treated as acceptable. For example:

User Input Expected: First Name

Regular Expression: [a-z A-Z-]

The above is a White list of all known good inputs, e.g Only Caps A to Z and small a- z will be allowed.  All other input is discarded as evil.

White list filtering gives more control to the programmer as it is a restrictive kind of filtering mechanism. Only characters defined in the list will be entertained and nothing else. All other characters are considered malicious and are rejected. White list offers much better protection in your application against attacks when the programmer has a good idea of the type of input expected for the application.

Unfortunately, there can be times when application developer has no clear idea about what data is expected. For example, sometimes user can enter free HTML as an input. In this kind of scenario, implementing inclusions list validation becomes difficult.

Cheers,

Anmol Malhotra

Sr. Security Consultant  - Microsoft ACE Services

Comments

  • Anonymous
    October 30, 2007
    PingBack from http://updates.thegeekyblog.com/?p=14052

  • Anonymous
    November 13, 2007
    There are lots of security principles which one should be aware of while developing software but at the

  • Anonymous
    January 13, 2008
    Hello folks, I just completed my blog series on Input Validation Strategies on our hackers blog - http://blogs.msdn.com/hackers

  • Anonymous
    January 13, 2008
    Hello folks, I just completed my blog series on Input Validation Strategies on our hackers blog - http