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.
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
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:
The source file specified by the SRC attribute inherits Internet Explorer’s security settings for the Restricted Sites zone.
All hyperlinks render in a new browser window, regardless of the TARGET attribute in the hyperlink element.
Use of JavaScript, VBScript, and the About protocol is restricted.
All nested frames inherit the same restrictions.
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:
Initiate a stock trade
Forge a post to a Web forum
Purchase an item using stored credit card information
Send an e-mail from a Web-based mail account
Authenticate to a secure Web site
Access resources on a private intranet site
Change a user’s password for an online account
Gather information about the user or the user’s environment
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:
Require POST on forms This does not completely eliminate the threat, but it does make it more difficult to execute the attack.
Require multi-step transactions Do not allow a user to complete a sensitive transaction in a single step. For example, require a second page to confirm the transaction and maybe even use a CAPTCHA to verify that it is a human user.
Verify referer headers Check HTTP referer headers to make sure form POSTs come in your own form. Although referer headers are not always reliable, it would be more difficult to forge these through a CSRF attack.
Do not allow users to automatically log in to your application with credentials saved in a cookie.
Do not allow users to post IMG tags to your application, such as to a forum or guestbook. Also use caution allowing users to post hyperlinks or URLs.
Security Policy
Always encode any HTML output based on dynamic input.
Enforce a specific character set in the web.config file or on a per-page basis.
Use caution with the DHTML innerHTML property, insertAdjacentElement method, insertAdjacentHTML method TEXTAREA element and TextArea object. Use innerText rather than innerHTML whenever possible.
Set security restrictions on frame and iframe elements with the Security attribute.
Use POST on forms whenever possible.
Require multi-step transactions with user confirmation.
Verify referer headers on form POSTs.
Do not allow users to save credentials in cookies.
Use caution when allowing users to enter HTML such as IMG tags or hyperlinks.
Use HTML syntax checking tools to verify that you have valid and properly-structured HTML content.
Boobalan.