Preventing Cross-Site Scripting Attacks in ASP.NET

Post date: Jul 18, 2011 3:40:30 AM

we covered cross site scripting attacks in the earlier hacking articles. Here we will find the way to prevent that cross site scripting from your sites.

1.Filter input:

This is the way we normally write our code to welcome the user. is it?

[C#] Response.Write("Welcome " + Request.QueryString["Username"]);  [VB.NET] Response.Write("Welcome " & Request("UserName"))

In this example, the code directly outputs the contents of the UserName variable without validating or filtering its contents. This is a common, but definitely not a safe, practice. A better solution is to filter the input before acting on the data, as shown here:

[C#] string userNameSafe=FilterInput(Request.QueryString["UserName"]); Response.Write("Welcome " + userNameSafe); [VB.NET] userNameSafe=FilterInput(Request("UserName")) Response.Write("Welcome " & userNameSafe)

In this example, the code calls a custom function FilterInput that you create to perform whatever filtering is necessary for the type of data.

The input filtering to prevent cross-site scripting attacks. But cross-site scripting doesn’t occur until you actually write the output to the browser. Because it is easy to overlook all the different character sets and encoding methods that ASP.NET or the client browser supports, you cannot completely rely on the input filtering to prevent cross-site scripting attacks

2.HTML Encoding

One solution, as mentioned is to always HTML-encode any data you send to the browser. In addition to this, you should also specify a character encoding set for your Web pages. Enforcing a specific character set limits which characters are valid for your site and eliminates the ambiguity that hackers might exploit by using other character sets.

You can specify the character set for your entire application in the web.config file:

<configuration>   <system.web>     <globalization       requestEncoding="ISO-8859-1"       responseEncoding="ISO-8859-1"/>   </system.web> </configuration>

You can also specify the character set on a per-page basis with the following meta-tag:

<meta http-equiv="Content Type" content="text/html; charset=ISO-8859-1" />

If you use DHTML, another technique to limit cross-site scripting attacks is to not use the InnerHTML property to set or read values between HTML elements. Instead, always use the InnerText property. If you do use InnerHTML, always be careful to filter input and encode output. Also use similar caution with insertAdjacentElement and insertAdjacentHTML methods as well as with TEXTAREA elements and TextArea objects.

Another method to limit the scope of cross-site scripting attacks is to set security restrictions on a frame or iframe element. You can restrict security with the Security attribute this way:

<IFRAME SECURITY='restricted' SRC='message.htm'>

Setting this property has the following effects:

Related to cross-site scripting is an attack called Cross-Site Request Forgery (CSRF). Cross site request forgery is when an attacker causes a user to make a request, on the user’s behalf, to another Web site. The attack works by getting the user to visit a URL, for instance by specifying an external URL in an IMG tag. Then when the client’s browser requests the image from the external URL, it does so in the context of the user, including any session tokens, cookies, or saved authentication credentials of that user.

Here’s an example: suppose an attacker wants to trick the user into performing some transaction, such as making a funds transfer from one account to another. The attacker somehow gets the user to view an HTML page, perhaps through an HTML-formatted e-mail. In the HTML, the attacker includes an IMG tag that contains the URL and any parameters required to make the transfer. The hypothetical URL might look something like this:

https://www.example.org/banking/transfer.aspx?from=123467&to=987655&amt=1000

Now suppose that this Web site doesn’t follow best security practices and lets users automatically sign in based on a saved cookie. When the user views the e-mail, it will try to request the image. In doing so, it will submit the transaction and complete the transfer. The return from the server obviously will not be a single image so it will show up as a broken link in the HTML document.

This particular example is obviously oversimplified, but it certainly is feasible with many Web sites. Consider some things an attacker could accomplish with this type of attack:

As you can see, this can be a very serious threat to both users and Web site operators. You cannot prevent these attacks with input filtering and they do not require client-side scripting to be enabled. The critical issue here is that CSRF attacks compromise your ability to enforce non-repudiation. If you have a Web page vulnerable to a CSRF attack, a user could argue that they did not perform a transaction, even if it originated from their own computer using their own login credentials.

Nevertheless, you can limit your exposure to CSRF attacks. Here are some tips:

Security Policy

Boobalan.