Cross-site Scripting (XSS)

December 2, 2014 / Featured, Security / 0 Comments /
cross-site scripting

What is an XSS attack?

Cross-site Scripting (XSS) flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

Am I Vulnerable to XSS?

You are vulnerable if you do not ensure that all user supplied input is properly escaped, or you do not verify it to be safe via input validation, before including that input in the output page. Without proper output escaping or validation, such input will be treated as active content in the browser. If Ajax is being used to dynamically update the page, are you using safe JavaScript APIs? For unsafe JavaScript APIs, encoding or validation must also be used. Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, making automated detection difficult. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches. Web 2.0 technologies, such as Ajax, make XSS much more difficult to detect via automated tools.

Example Attack Scenario

It is also called „HTML Injection“ by some but it actually is more like „HTML Injection + Scripting“. It usually happens when untrusted user input is printed on the web page, let us take a short example (no scripting):
– Vulnerable code : echo „Your name is: „ . $name ;
– User input:          „Jack <a href=”“evilsite.com“”>Safe link</a>“
– User sees:          Your name is: Jack Safe site
– User may be tricked!

Do not get fooled by the simplicity of the example.This is the most widespread attack currently although its not as severe as SQL Injection it can be pretty harmful depending on the case.

Stored vs. Reflected XSS

Stored XSS is the procedure where you attack once and it results always, for example the Script injection is saved on a comment and every users loads the malicious script while Reflected XSS is the procedure where you attack once and it results once.

How Do I Prevent XSS?

Preventing XSS requires separation of untrusted data from active browser content.

  1. The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. See the OWASP XSS Prevention Cheat Sheet for details on the required data escaping techniques.
  2. Positive or “whitelist” input validation is also recommended as it helps protect against XSS, but is not a complete defense as many applications require special characters in their input. Such validation should, as much as possible, validate the length, characters, format, and business rules on that data before accepting the input.
  3. For rich content, consider auto-sanitization libraries like OWASP’s AntiSamy or the Java HTML Sanitizer Project.
  4. Consider Content Security Policy (CSP) to defend against XSS across your entire site.
  5. Consider using some tools like XSS-Me and as a more serious tool consider using Xenotix XSS Framework

Main Sources