RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


ASP.NET Security: 8 Ways to Avoid Attack

Adding security to Web apps may not be great fun but it doesn't have to hard. You can easily ensure your apps meet today's best practices by applying eight principles for secure Web development.

uilding ASP.NET Web applications has never been easier. Visual Studio.NET hides so many technical details behind the scenes that developers need only concentrate on the core business logic. However, hackers are on the lookout for any opportunity to hack into your application. Which means the pressure is on you to keep defense top of mind. If you don't, you'll quickly find your ASP.NET apps vulnerable to attack.

I've compiled a list of the eight most vital defenses, complete with the information you need to arm yourself against them.

Tip 1—Cross-site Scripting
Cross-site Scripting (XSS) is one of the most common attacks on Web applications today. Put simply, XSS happens when a hacker injects a script into your Web application (normally through user inputs) and your application accepts it without checking. When the data (containing the script) gets saved into your Web application, subsequent users may be affected as the script may inadvertently get loaded onto their Web browsers.

To better understand XSS, consider an example in which your Web application asks for a user’s name via a text box (see Figure 1). When the user clicks on the button, his name will be displayed in the label control.

However, instead of entering his name, the user might enter a line of script, such as “<script>alert("Hello there!");</script>” (see Figure 2).

Figure 1. What Say You? This form prompts the user to enter a string.
Figure 2. Not a String. Without proper precautions, a user can enter a script in a text box instead of string.

In this case, when the button is clicked, the script will be written to the Label control and the Web browser will execute the script rather than display it (see Figure 3).

Figure 3. Not the Plan. The script from Figure 2 executes on the client.
My example is benign, but if a malicious script is injected and gets stored into your application, it may then be sent to other users to cause more severe damage. For example, one type of script could read and display the current cookie values or redirect the user to another Web site.

Fortunately, ASP.NET 1.1 ships with built-in request protection to detect inputs that contain scripts. Figure 4 shows what would happen in ASP.NET 1.1 if a user tried to enter scripting code in an input control.

Figure 4. Throwing an Error. ASP.NET's built-in request validation kicks into action and warns you that a script has tried to execute.

Despite the built-in defense by ASP.NET, there were reports of loopholes. By inserting a null character (%00) into the <Script> element, it will bypass detection:

<%00SCRIPT>alert("Hello there!");</SCRIPT>
While this vulnerability has been hot-fixed, it is nevertheless important that you employ added precaution. One good method is to use the Server.HtmlEncode() method to encode all user inputs into HTML-encode strings:

    Private Sub Button1_Click(ByVal sender As System.Object, _
            ByVal e As System.EventArgs) _
            Handles Button1.Click
        lblMessage.Text = Server.HtmlEncode(txtName.Text)
    End Sub
Figure 5. Workaround. You can manually turn off page validation if built-in script protection is disabled.
If the user injects a script, the HTML-encoded input will then look like this:

<script>alert("Hello there!");</SCRIPT>
When this HTML-encoded string is displayed in a browser, it will be displayed as a string, and not executed as a client-side script.

If you need to turn off the built-in script protection in ASP.NET 1.1 for some reason, you can set the validateRequest attribute in your page to false (see Figure 5)

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date