Cross-site Scripting

What is Cross-site Scripting?

Cross Site Scripting attack (XSS) is a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. 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

Cross site Scripting Example

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

HTML Escape

XSS can be prevented by 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

Risk Covered

Hdiv flow control minimizes vulnerable parts and for the remaining parts protection is applied (only) if a vulnerability is present

It is important to note that both HTML Escape and Input Validation are necessary. To reinforce Input Validation, Hdiv eliminates to a large extent the risk originated by Cross-site scripting (XSS) and SQL Injection attacks by 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 due to its understanding of the semantics of each piece of data, Hdiv differentiates automatically between two types of data:

  • Data generated on the server side (non-editable data).
    90-95% of the information managed by a web application is non-editable data offered by the server which is presented by the application to be read/selected by the end user. This is the case with 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 field) or file input fields.

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

The validation carried out by Hdiv is done through a technique which compares the non-editable data received by the web application (in a request generated by a client), with the non-editable data that is offered in the screens 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.