Cross-site Scripting (XSS)

OWASP Top 10 - A3



What is Cross-site Scripting (XSS)?

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

owasp.org

Example of a Cross-site Scripting Attack

The most common example of XSS is a basic coded search engine for a website. The site search script is in this format:

http://www.vulnerablewebsite.com/search/query?q=Hdiv%20XSS

Once something has been searched for, the script displays on the webpage something along the lines of:

"Results for Hdiv XSS here"

Simply displaying the search string straight onto the webpage without performing any validation checks. An attacker could insert a script and if no sanitation checks are being performed, this will just be displayed straight onto the webpage. This could be used to display anything the attacker wants.

http://www.vulnerablewebsite.com/search/query?q=<script>alert("Hdiv XSS");</script>


How to prevent Cross-site Scripting (XSS)

The source of the problem of XSS risk is based on writes that use untrusted data without using escaped functions.


How do I prevent Cross-site Scripting attacks?

HTML Escape

XSS can be prevented sanitizing any user input before it is processed and/or rendered back to the browser. For example, in JSP by using JSTL <c:out> tag or fn:escapeXml() EL function when (re)displaying user-controlled input. This includes request headers, cookies, URL, body, parameters, etc, the whole request. Also the user-controlled input which is stored in a database needs to be escaped during redisplaying.

Examples:

JSTL Tag: <c:out value="${bean.userControlledValue}"/>
 Spring Form Tags: <form:hidden path="${bean.userControlledValue}" htmlEscape="true" />
Spring Eval: <spring:eval expression="bean.userControlledValue" htmlEscape="true"/>
Struts 1: <bean:write name="bean" property="userControlledValue" filter="true"/>
Struts 2: <s:property value="#request.bean.userControlledValue" escapeHtml='true'/>

Input validation

Custom validation

Validate all input data to the application using whitelist (what is allowed) for type, format, length, range, reject if invalid.

Use Hdiv's validation

It is important to note that both preventions are necessary, HTML Escape and Input Validation. To reinforce Input Validation, Hdiv eliminates to a large extent the risk originated by attacks of type Cross-site scripting (XSS) and SQL Injection using generic validations applied at application level.

In addition, Hdiv gets the required information directly from memory in real time, thanks to the integration points with web frameworks. After this analysis and thanks to the understanding of the semantics of each piece of data, Hdiv differentiates automatically between two types of data:

  • Data generated on the server side (read-only data).
    90-95% of the information managed by a web application is read-only data offered by the server, which is presented by the application to be read/selected by the end user. This is the case of static information (text, images), and other components such as lists, buttons, links, etc.
  • Data generated on the client side (editable data).
    Only 5-10% of the information managed by a web application corresponds to data that is generated on the client side by the user, through text boxes (such as a search fields) or file input fields.

Hdiv makes an automatic security validation of the read-only data received by a web application that gives 100% trust. This means that it is impossible to carry out any kind of attack based on read-only data validated by Hdiv.

The validation carried out by Hdiv is done through a technique which compares the read-only data received by the web application (in a request generated in a client), with the read-only data that is offered in the screens offered by the web application server, to check that the server is not receiving any modified or additional data. This simple and powerful mechanism is based on one of the security foundations (input data integrity validation) and offers total guaranties. Furthermore, this validation algorithm needs no updating and is not affected by the evolution of technology or attacks, providing a 100% effective long-term solution.