Hack Proof Your Asp.Net Application Part 2 (Cross Site Scripting-XSS)
Introduction -
This is part -2 of my series Secure your Asp.Net Applications. In this article, I will describe what exactly Cross site scripting (XSS) is and how hacker exploit it and how we can prevent from XSS attack.
Background:
For part-1 of this series you can check from HERE which is Secure your asp.net application from SQL Injection.
Cross-Site Scripting -
Cross-Site Scripting is kind of security exploit in which attacker inserts malicious code of his choice(Mostly script) into web page or in database, without user's knowledge .XSS in itself is a threat which is brought by the internet security weaknesses of client-side scripting languages, with HTML and JavaScript (others being VBScript, ActiveX, HTML, or Flash) as the prime culprits for this exploit.
- Reflected -(When malicious code goes from user browser to server and comes back from server)
- Persistent - (When code remains stored somewhere ,example - code stored in database and executes on client browser over and over , which makes it more dangerous).
- Dom Based XSS Attack - (Both reflected and persistent can fall in this category, Attacker can manipulate DOM elements can use DOM data )
What can these attacks do -
- Create and access DOM elements
- Send Information to attacker site
- Hijack Cookies , Click events , Credentials
How is it Exploited -
Following are the ways , how attacker tries XSS on a web application :
- It can be done from server side code(Example-Asp.net code)
- It can be done from client side code (JavaScript/Jquery code)
- Attacker can inject script into user's experience
1. Reflected Cross Site Scripting Attack - In this kind of attack , Attacker Generally tries to send the script or html input to server and let it comes back to the browser and run . they achieved it by using Query string . Although all the latest browsers applied the XSS filters . but still HTML elements can be inserted using this attack .Also to test you can enable XSS filter in browsers ,for IE - Tools > Internet option > Security Tab > Custom level > Enable XSS filter. Lets see how to do it , so things will be more clear -
In above example we are passing HTML element and script in our label ,which gets assigned as it is and becomes legal script & element for a page are getting reflected in our page and showing the effects .This is just the basic example how attacker tries Reflected XSS ,scripts and their use can be too harmful.
2.Persisted Cross Site Scripting Attack -
In persisted attack user injected script to the database and every time user visits that page he faced the consequences of that script .Example -
Script Injected in the comment Section -
hiii this is text <link rel="stylesheet" href="http://code.jquery.com/ui/1.10.3/themes/smoothness/jquery-ui.css" />
//these scripts are innocent (Just opening the pop up), that's the developer cause who developed vulnerable web applications .
<script src="http://code.jquery.com/jquery-1.9.1.js"></script>
<script src="http://code.jquery.com/ui/1.10.3/jquery-ui.js"></script>
<script>
$(function() {
$( "#dialog" ).dialog();
});
</script>
<div id="dialog" title="Session Out please login again">
<input type="Text" placeholder="login"/><br/>
<input type="Text" placeholder="login"/><br/>
<button>
3. DOM based Cross Site Scripting -
Both Persistent and reflected can fall in this category , but some other variance of attacks makes it different.
Some developer do think JSON is safe and some use Jquery unsafe methods.how they use it -
Some developer do think JSON is safe and some use Jquery unsafe methods.how they use it -
//Encoded String using Microsoft.Security.Application.Encoder.JavaScriptEncode
var json = jQuery.parseJSON('{"name":"sarvesh","girlfriendname":"\x3cscript\x3ealert\x28\x27hehaha\x27\x29\x3c\x2fscript\x3e"}');
var createelement = document.createElement('div');
document.body.appendChild(createelement);
//we should not use this html , we can use text instead of this
$(createelement).html(json.girlfriendname);
//it will show the alert
As attacker is not inserting direct script ,he is inserting encoded string which contains script . so these are new ways attacker find to Exploit XSS . or we can use direct encoded string , i just use json to show ,this is also not safe way .
Another way of attack come under this category i.e using HTML elements and kind of java script code without script tag . developer try to find script tag or <> these character and replace them to avoid XSS but that is not a full proof way .following example shows that -
sometime we need to show the dynamic alert -
So for Encoding we can use AntiXss sanitizier's GetSafeHtml() and GetSafeHtmlFragment() .To download AntiXss , go to MS Visual Studio's Tools > Library Package manager > Package manager console > Install-Package AntiXss .
its better to use these method if we really don't encoding the data .
2. Specify page encoding in the web.config . because attacker can change the encoding to UTF-7 which has different standard to write the lines and can make tough to filter out the script code in the page .
3. Apply content security policies to allow the script of your own host , or to allow the script of any host like Google and Microsoft .we can add header to stop scripting from attacker site or we can say third party site.
although its not full proof because IE does not support this , but still we can use this as an additional thing to stop XSS .Add following code to allow script just from your host .
4. Do not use filter approach to find the script tag an replace that , there are many cheat-seat available on the internet for XSS . Simple example attacker can use onload=alert('anything') .
5. Data validation , you can trust the user input , just make sure data is exactly what , your application expects .
6. Don't Set ValidateRequest attribute false . when it is true it might throw the error like this , to prevent this error make sure you data is proper encoded before sending to the server .
7. Be concerned where DOM elements are being created and modified .use function such as setAttribute and document.createElement('div') rather than document.writein and $('div').html() .
8. Force user to update the IE6 which is very much vulnerable to XSS . IE6update.com is better solution for that .
9.Audit every palace where data is assigned .Know your control behavior as label can't post the values and text-box do .so better to encode text-boxes first . you can use third party control to check the vulnerability .
for firefox use XSS-ME and for chrome can use DOM-SNITCH .
10.Keep update your self on regular base check new ways of same attack .Attacker invents new ways to do same attack in their spare time .OWASP have very good cheat sheet and defense for XSS .OWASP have regular updates about these attacks .
11. Know Asp.Net Encoding ways and use proper config statements to make changes .
all above mention prevention are usefull to prevent XSS . Download the sample code for the XSS .
var jencoded = "\x3cscript\x3ealert\x28\x27hehaha\x27\x29\x3c\x2fscript\x3e"; //this will give the same result
Another way of attack come under this category i.e using HTML elements and kind of java script code without script tag . developer try to find script tag or <> these character and replace them to avoid XSS but that is not a full proof way .following example shows that -
sometime we need to show the dynamic alert -
<img onmouseover=alert(user input) />user input can give the input in sql injection manner like this -
<img onmouseover=alert(1) onmouseout=alert(document.cookie) >Now he can see the cookies you are saving , that might be user credentials or any important data .
How to prevent XSS -
1.Your code output should be HTML Encoded but make sure while storing the data , it should not be Encoded .Encoding and storing can lead to double encoding .
< => < => < => &lt;
Sanitizer.GetSafeHtmlFragment(YourString)
its better to use these method if we really don't encoding the data .
2. Specify page encoding in the web.config . because attacker can change the encoding to UTF-7 which has different standard to write the lines and can make tough to filter out the script code in the page .
<configuration>
<system .web="">
<globalization culture="en-US" fileencoding="utf-8" requestencoding="utf-8" responseencoding="utf-8" uiculture="de-DE">
</globalization></system>
</configuration>
3. Apply content security policies to allow the script of your own host , or to allow the script of any host like Google and Microsoft .we can add header to stop scripting from attacker site or we can say third party site.
although its not full proof because IE does not support this , but still we can use this as an additional thing to stop XSS .Add following code to allow script just from your host .
Response.AddHeader("X-WebKit-CSP", "default-src 'self'"); // experimental header introduced into Google Chrome and other WebKit based browsers (Safari) in 2011
Response.AddHeader("X-Content-Security-Policy", "default-src 'self'"); //experimental header introduced in Gecko 2 based browsers (Firefox 4 to Firefox 22, Thunderbird 3.3, SeaMonkey 2.1).
4. Do not use filter approach to find the script tag an replace that , there are many cheat-seat available on the internet for XSS . Simple example attacker can use onload=alert('anything') .
5. Data validation , you can trust the user input , just make sure data is exactly what , your application expects .
6. Don't Set ValidateRequest attribute false . when it is true it might throw the error like this , to prevent this error make sure you data is proper encoded before sending to the server .
7. Be concerned where DOM elements are being created and modified .use function such as setAttribute and document.createElement('div') rather than document.writein and $('div').html() .
8. Force user to update the IE6 which is very much vulnerable to XSS . IE6update.com is better solution for that .
9.Audit every palace where data is assigned .Know your control behavior as label can't post the values and text-box do .so better to encode text-boxes first . you can use third party control to check the vulnerability .
for firefox use XSS-ME and for chrome can use DOM-SNITCH .
10.Keep update your self on regular base check new ways of same attack .Attacker invents new ways to do same attack in their spare time .OWASP have very good cheat sheet and defense for XSS .OWASP have regular updates about these attacks .
11. Know Asp.Net Encoding ways and use proper config statements to make changes .
all above mention prevention are usefull to prevent XSS . Download the sample code for the XSS .
I might want to thank you for the endeavors you have made in composing this article
ReplyDeleteapplication security
Great Article
ReplyDeleteCyber Security Projects for CSE Students
JavaScript Training in Chennai
Project Centers in Chennai
JavaScript Training in Chennai