Could this XSS protection with HttpOnly Cookies work?

Question

I have done some research on HttpOnly cookies and the problem that exist with the possibility to use an XHR request in combination with the TRACE method to get the cookie value echoed back from the server.

For a secure webapplication I currently have the following setup:

• Session cookie is sent at login with secure and httpOnly properties set
• The TRACE http method is disabled for the complete domain (returning "405 Method not allowed")

To avoid cross site request forgery I have added a random key in a hidden field to the forms. This key is must be returned in each POST request for the request to be accepted.

Apart from this all HTML is escaped by default using whitelisting to select tags and attributes that are allowed, but to illustrate why this is not enough: We previously allowed the style-attribute on span to be used (to color text for example), which could be used to pass javascript in Internet Explorer in the following way:

<span style="width: expression(alert('Example'));"> </span>

And then to the final question: Could anybody point out any flaws or suggestions to possible flaws in this setup? Or are you using the same or completely different approaches?

Known problems:

• Not all browsers support httpOnly
• Filtering css JS-expressions is not enough, @import(external-style-sheet) could also work

Answer 1

HttpOnly Cookies is a good secuirty measure, but it is not designed to stop XSS, just make it more difficult for attackers to exploit xss vulnerabilities. Let me elaborate.

A token based xsrf secuirty system can be bypassed using XSS, thus the attacker doesn't need to know the cookie to exploit the xss vulnerability.

To avoid cross site request forgery I have added a random key in a hidden field to the forms. This key is must be returned in each POST request for the request to be accepted.

For instance, using XSS an attacker can execute JavaScript which can read any page on the domain using xmlhttprequest. Thus by using xmlhttprequest an attacker can read the XSRF token and then use it to forge the POST request. This is because one property of XSS is that it allows for a break in the Same Origin Policy. As an example, Here is a real world exploit that I wrote which does what i just explained.

The best way to prevent XSS is to convert nastily characters like <> into their corresponding html entities. In PHP I recommend:

$var=htmlspeicalchars($var,ENT_QUOTES);

This will fix single quotes and double quotes so it can stop most xss. Even if the resulting sting is in a html tag. For instance an attacker can't use this exploit if you replace quote marks. This is because the attacker has to break out of quotes in order to execute an "onload=".

$var="' onload='alert(document.cookie)'";

into this html:

print("<img src='http://HOST/img.php?=".$var."'&gt;");

HOWEVER, the specific case that you listed using a <span> tag is still potentially a problem because the attacker doesn't need quote marks! Your also going to have a xss vulnerability if you put inside a <script> tag. Just be safe about where user input is being placed, there isn't a "catch all" or "silver bullet" for all vulnerabilities.

The "XST" attack which leverages the HTTP "TRACE" method is not a realistic attack in practice. The reason why is that it is impossible for an attacker to force a web browser into making a "TRACE" http request. Attackers can force the "GET" and "POST" methods using javascript or an <img> tag in the case of "GET", but the rest of the HTTP header is off limits. Keep in mind that TRACE is enabled by default in nearly all Apache systems, if it was really hazardous it would be removed all together. Many security testing tools like Nessus will throw an error if Apache supports TRACE, it can also be disabled easily.