The Cross-site scripting (XSS) attack is quite popular these days. This attack is mainly used to steal user data like cookies, viewstate etc.
A simple example of XSS attack is shown below which display alert message.
http://testsite.com/default.aspx?id=2&"< Script>alert ('Hello Sunilee');"
XSS attack result can lead to following.
1. Data integrity can be compromised.
2. Cookies can be set and read.
3. User input can be intercepted.
4. Malicious scripts can be executed by the client in the context of the trusted source.
1. Using secure code
Encode HTML Output
Use the HttpUtility.HtmlEncode method to encode output if it contains input from the user or from other sources such as databases. HtmlEncode replaces characters that have special meaning in HTML-to-HTML variables that represent those characters. For example, < is replaced with < and " is replaced with ". Encoded data does not cause the browser to execute code. Instead, the data is rendered as harmless HTML.Consider following example.
Private void Page_Load(Object Src, EventArgs e)
The output of above code will be <html>
Encode URL Output
If you return URL strings that contain input to the client, use the HttpUtility.UrlEncode method to encode these URL strings as shown in the following code example.
Use the innerText Property Instead of innerHTML
If you use the innerHTML property to build a page and the HTML is based on potentially untrusted input, you must use HtmlEncode to make it safe. To avoid having to remember to do this, use innerText instead. The innerText property renders content safe and ensures that scripts are not executed.
2. Using Microsoft Cross Site Scripting Libraries
Check weather request validation(ValidateRequest="true") properly is enabled on asp.net page or not. By default this property is enabled and when you try to inject html injection it will give error page displaying error as "A potentially dangerous Request.QueryString value was detected from the client" .
You can set this property in web.config as shown below.
< pages buffer="true" ValidateRequest="true" />
Also request validation property can also be set at page level as..
< %@ Page Language="C#" ValidateRequest="true" %>
Use the frame Security Attribute
Internet Explorer 6 and later support a new security attribute for the and elements. You can use the security attribute to apply the user's Restricted Sites Internet Explorer security zone settings to an individual frame or iframe. By default, the Restricted Sites zone does not support script execution.
If you use the security attribute, it must be set to "restricted" as shown in the following.
frame security="restricted" src="http://www.yourdomain.com/testpage.htm">
Protecting Data with HTTP-only Cookies
To mitigate the risk of information disclosure with a cross-site scripting attack, a new attribute is introduced to cookies for Internet Explorer 6 SP1. This attribute specifies that a cookie is not accessible through script. By using HTTP-only cookies, a Web site eliminates the possibility that sensitive information contained in the cookie can be sent to a hacker's computer or Web site with script.
A cookie is set on the client with an HTTP response header. The following example shows the syntax used in this header
Set-Cookie: =[; =]
[; expires=][; domain=]
[; path=][; secure][; HttpOnly]
More Info about HTTP Only Cookies
Dangerous HTML Tags
Following are commonly used HTML tags that could allow a malicious user to inject script code.
1. < applet>
2. < body>
3. < embed>
4. < frame>
5. < script>
6. < frameset>
7. < html>
8. < iframe>
9. < img>
10. < style>
11. < layer>
12. < link>
13. < ilayer>
14. < meta>
15. < object>
The scenario is more complex in case of persistent type of XSS attack wherein server saves all the malicious data submitted by an attacker and renders data (malicious script) on some or all pages. Me and my team leader TAS came across the a similar incident in one of forensics project where the application was vulnerable to SQL injection. Using this vulnerability the and attacker has inject links in to the database such that when the web page renders the records where the malicious links were injected would redirect to a malicious domain, which was already marked as Unsafe by Google as "Reported Web Forgery!" by the browser.