Secure Cookies: The HttpOnly Flag
Cross Site Scripting (XSS) vulnerabilities can be pretty dangerous. On web applications, they can lead to everything from breaches in privacy to complete account compromisation. One of the many ways that attackers can take advantage of XSS holes is by reading the information stored in the browser cookies and using it to impersonate a legitimate user. To the vulnerable site, there is usually no difference between the credentials provided by the real user and those provided by an attacker– so everything looks peachy on the surface.
If only there was a way to better protect cookies from such an attack…
Ah, but there is: the ‘secure cookie’ flag.
A secure cookie is just like a regular cookie… except for one small difference; secure cookies contain a special ‘HttpOnly’ flag included in the HTTP cookie header that instructs the browser to restrict access to cookie data from scripts within the web browser. Ideally, this will have the net affect of limiting the potential damage many XSS attacks can cause– specifically, the attacks that target cookie data.
The ‘HttpOnly’ flag was first used in Internet Explorer back in 2002, but is now at least partially supported by most major web browsers (with varying degrees of protection). In fact, at the time of this writing, Firefox is the only mainstream browser that effectively prevents both read AND write cookie operations. Although other browsers prevent access via the document object model (DOM), they may unintentionally reveal cookie data when viewing the headers of an XMLHttp response.
In addition, some web server scripting languages mishandle cookie data and can unintentionally undermine the purpose of the ‘HttpOnly’ flag. Certain versions of PHP, for example, strip off special bytes that are included at the end of cookie names, allowing browser-set cookies to overwrite secure cookies when read by the server-side script. (Hint: ‘document.cookie = ‘MyCookie%00=oh snaps;’).
However, one the biggest reasons that the ‘HttpOnly’ flag isn’t as effective as it could be is the lack of knowledge that it even exists. Many developers are completely unaware that they can cripple potential XSS attacks by simply adding a flag in a header.
Clearly, secure cookies aren’t a perfect solution– but they do offer an extra layer of protection and are very easy to implement. In the future, maybe all browsers, web scripting interfaces, and application developers will fully support this effort (or a better one) to proactively limit the wide breadth of the cross-site scripting family of attacks.
Each Tuesday, Security Musings features a topic to help educate our readers about security. For more information about Gemini Security Solutions’ security education capabilities, contact us!