Could this XSS protection with HttpOnly Cookies work?

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 mus开发者_StackOverflow中文版t 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

---

Based on your post (title a bit misleading) I assume you understand that Httponly attribute prevents access to cookie via document.cookie and does nothing else to protect against the other nasty things that XSS allows including impersonating user (i.e., don't need to steal cookies and can use retrieved CSRF token), checking for vulnerable plugins on browser to install malware, installing javascript key logger, scanning your internal network, etc, rewriting the page, etc.

As you say whitelisting tags and attributes for each tag is not enough. You have to apply stricter validation on attribute values probably via whitelist regex.

An incomplete list of other things to consider a couple of which are not directly related to XSS or CSRF:

• How do you deal with incomplete html such as missing closing tags?
• How do you handle single quote, double quote, and backslash in user input?
• How do you handle user input that is output in different contexts - such as in url links, attribute values, etc.?
• Do you check that input actually matches input charset encoding?
• Do you explicitly set Content-Type in response header and in meta tag?
• For moderately sensitive user pages served over HTTP if any do you set appropriate Cache-Control header?
• How do you ensure user input is sandboxed? Specifically, if you allow CSS, how do you ensure style is applied only to restricted region and cannot alter other regions?
• Do you have 3rd party javascript including ads on the site?
• Is the session cookie protected against tampering if it should be?
• Do you sanitize all input including HTTP headers that can be modified by user?
• Is the CSRF token truly random - if yes, how do you generate random token? If not, how do you construct it?
• Do you use prepared statements and bind parameters?
• Can users upload files?
• Do you serve user uploaded content such as images, etc? If yes how do you validate file content (GIFAR flaw) and is the file served from same domain?
• Do you provide API access and if yes is it hosted on same domain? What crossdomain restriction do you have?

---

HttpOnly Cookies is a good security 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 security 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."'>");

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.