UPDATE:
OWASP just updated the Top 10 list.
Check out this in-depth post to learn everything about the new OWASP Top 10 2021.
Discover OWASP Top 10 2021
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.
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>
The source of the problem of XSS risk is based on writes that use untrusted data without using escaped functions.
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'/>
Validate all input data to the application using whitelist (what is allowed) for type, format, length, range, reject if invalid.
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:
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.
Risk Covered
The validation carried out by Hdiv is based on one of the security foundations (input data integrity validation), offering total guarantees. 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.