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 1Cross-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:
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) _
lblMessage.Text = Server.HtmlEncode(txtName.Text)
|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:
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)