T H E E P I C C O D E

PVA COMMUNITY

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into 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.

Early on, two primary types of XSS were identified, Stored XSS and Reflected XSS. In 2005, Amit Klein defined a third type of XSS, which Amit coined DOM Based XSS. These 3 types of XSS are defined as follows:

Stored XSS (AKA Persistent or Type I)

Stored XSS occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser. With the advent of HTML5, and other browser technologies, we can envision the attack payload being permanently stored in the victim’s browser, such as an HTML5 database, and never being sent to the server at all.

Reflected XSS (AKA Non-Persistent or Type II)

Reflected XSS occurs when user input is immediately returned by a web application in an error message, search result, or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data. In some cases, the user provided data may never even leave the browser (see DOM Based XSS next).

DOM Based XSS (AKA Type-0)

As defined by Amit Klein, who published the first article about this issue [1], DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write).”

Preventing Cross-site Scripting (XSS) vulnerabilities in all languages requires two main considerations: the type of sanitization performed on the input, and the location in which that input is inserted. It is important to remember that no matter how well input is filtered; there is no single sanitization method that can prevent all Cross-site Scripting (XSS). The filtering required is highly dependent on the context in which the data is inserted. Preventing XSS with data inserted between HTML elements is very straightforward. On the other hand, preventing XSS with data inserted directly into JavaScript code is considerably more difficult and sometimes impossible.

INPUT SANITIZATION

For the majority of PHP applications, htmlspecialchars() will be your best friend. htmlspecialchars() supplied with no arguments will convert special characters to HTML entities, below shows the conversions performed:

'&' (ampersand) becomes '&'
'"' (double quote) becomes '"'
'<' (less than) becomes '&lt;'
'>' (greater than) becomes '&gt;'

Eagle eyed readers may notice this does not include single quotes. For this reason we recommend that htmlspecialchars() is always used with the ‘ENT_QUOTES’ to ensure single quotes will be encoded. Below shows the singe quote entity conversion:

"'" (single quote) becomes '&#039;' (or &apos;)  

HTMLSPECIALCHARS() VS HTMLENTITIES()

Another function exists which is almost identical to htmlspecialchars(). htmlenities() performs the same functional sanitization on dangerous characters, however, encodes all character entities when one is available. This may lead to excessive encoding and cause some content to display incorrectly if character sets change.

STRIP_TAGS()

strip_tags() should NOT be used exclusively for sanitizing data. strip_tags() removes content between HTML tags and cannot prevent XSS instances that exist within HTML entity attributes. strip_tags() also does not filter or encode non-paired closing angle brackets. An attacker may be able to combine this with other weaknesses to inject fully functional JavaScript on the page. We recommended that strip_tags() only be used for its intended functional purpose: to remove HTML tags or content. In these situations, input should be passed through htmlspecialchars() after strip_tags() is used.

ADDSLASHES()

addslashes() is often used to escape input when inserted into JavaScript variables. An example is shown below:

http://www.example.com/view.php?name=te"st
[...]
<script>
 var = "te\"st ";   // addslashes()
 displayname(var);
</script>

As we can see, addslashes() adds a slash in attempt to prevent an attacker from terminating the variable assignment and appending executable code. This works, sort of, but has a critical flaw. Most JavaScript engines will construct code segments from open and closed <script> tags before it parses the code within them. This is done before the browser even cares about the data that resides between the two quotes. So to exploit this, we don’t actually need to “bypass” addslashes(), but simply terminate the script tag.

<script>
 var = "test1</script><script>alert(document.cookie);</script>";
 displayname(var);
</script>

As far as the browser is concerned, the code injected is an entire new code segment and contains valid JavaScript.

WHERE ENTITY ENCODING FAILS

We talked before about considerations for the location of data, and will go over some examples where entity encoding with htmlspecialchars() is not enough. One of the most common examples of this is when data is inserted within the actual tag or attribute of an element.

HTML Event Attributes: HTML has a number of elements with attributes that allow for JavaScript to be called after a particular event. For example, the onload attribute can execute JavaScript when an HTML object is loaded.

<body onload=alert(document.cookie);>

This is just one of many somewhat rare situations where extremely strict filtering is required. For an in-depth look at many injections, take a look at the OWASP XSS Prevention Cheat Sheet.

THIRD PARTY PHP LIBRARIES

Virtue Security makes no recommendation or provides any warranty for third party products or software; however, we are aware that several third party PHP libraries are commonly used to assist in XSS prevention. Below are projects that may assist developers building suitable whitelists:

HTML Purifier – http://htmlpurifier.org/
PHP Anti-XSS – https://code.google.com/p/php-antixss/
htmLawed – http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

OTHER THINGS TO REMEMBER

Not to insert user-controlled data unless it’s explicitly needed for the application to function. It’s often surprising to see Crosssite Scripting XSS vulnerabilities exist because parameters are inserted into HTML or JavaScript comments. Not only does this serve no functional purpose to the application, but it can introduce serious security vulnerabilities.

Related Post

Leave a Comment