High Risk: OWASP A3: Stat Report Rank 3
Description
Cross-site scripting (sometimes referred to as "XSS") vulnerabilities occur when an attacker embeds malicious client-side script or HTML in a form or query variables submitted to a site via a web interface, sending the malicious content to an end-user. If this content is submitted by one user (the attacker), stored in the database, and subsequently rendered to a different user (the victim), a Persisted Cross Site Scripting Attack occurs. A variation of this attack, known as Reflected Cross Site Scripting, occurs when an attacker entices a victim into submitting the tainted data themselves, via an email or a link on an attacker-controlled website.
An attacker can use XSS to send malicious script or other content to an unsuspecting user. Neither the end user nor their browser knows that the content was not actually generated by the trusted website. The malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used by the site. These scripts can even rewrite the content of the HTML page. This can result in phishing attacks, identity theft, website defacement, denial-of-service, and other attacks.
Solution
The most reliable means of thwarting most types of XSS attacks is to HTML-encode or URL-encode all output data, regardless of the data’s source. This ensures that tainted data can’t affect the output from any source, including user input and information shared with other applications or originating from third-party sources. Consistently encoding all output data also makes the application much easier to audit, since it eliminates the need to perform time consuming (and expensive) data flow analysis. It is important to note that there are different output contexts which encoding functionality must handle, including HTML, HTML attributes, URLs, CSS, and JavaScript. A single encoding approach will not necessarily mitigate XSS in every context.
If output encoding isn’t practicable, the next most effective approach is to carefully filter all input data against a white-list of allowed characters. This approach does have the advantage that it can be performed externally without modifying application source code. Data retrieved from third-parties or shared with other applications should be filtered along with user input data. The white-list should only include characters which may be a legitimate part of user input. The following characters are especially useful for conducting XSS attacks and should be considered in any encoding or filtering scheme: < > “ ‘ ; & ?
One or more of these characters, such as the single quote, may be required by the application. If it is impracticable to remove one or more dangerous characters as part of an input filtering scheme, they must be carefully handled. Such characters could, for example, be encoded on input, and stored encoded in the database. Ideally, the application should perform careful input validation and use output encoding to guard against XSS and other injection attacks.
Additional Resources
http://www.owasp.org/index.php/Cross_Site_Scripting https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet