Why HttpOnly Won't Protect You

Thu, 12 Apr 2007 08:27:07 GMT
by pdp

Before going in depth criticizing the HttpOnly session protection mechanism I better explain what it is and why it is useful.

HttpOnly is a session protection mechanism, as we established from the previous paragraph, which is used in situations where the session cookie is not required to be available inside the application DOM. Session identifiers are responsible for keeping the state between the browser and the remote server. They are needed only for this reason. In situations where the client or the server is vulnerable to XSS (Cross-site Scripting), attackers can easily retrieve the session identifier by querying the document.cookie object. The retrieved information can be sent to a remote collection point which is controlled by the attacker. Once the session identifier is collected, the attacker will be able to hijack the user session.

HttpOnly is a an option which specifies that the cookie (session identifiers included) should not be accessed from the application DOM. In that case the attacker cannot hijack the session because document.cookie will not return anything useful.

IMHO, HttpOnly create a false sense of security. HttpOnly does not solve any problem at all. For more information about HttpOnly, you can read the MSND article. The article is entitled "Mitigating Cross-site Scripting With HTTP-only Cookies" which I think is quite wrongly put. Here is a typical example of how to declare a HttpOnly session identifier:

Set-Cookie: SESSIONID=[token]; HttpOnly

The HttpOnly protection mechanism is useful only in case where the attacker is not skillful enough to undertake other means for attacking the remote application and subsequently the user. Although, session hijacking is still considered the only thing you can do when having XSS, this is for from what is actually possible. The truth is that session hijacking is probably one of the least things the attacker will do for a number of reasons. The most obvious reason is that XSS attacks, although could be targeted, are not instant, like traditional buffer overflow attacks where the attacker point the exploit to a remote location and gain access right away. For an XSS attack to be successful, sometimes it is required a certain period of time to pass until the victim opens a link or do something else. It is highly unlikely that the attacker will wait all the time just to get a session which could be invalidated a couple of moments later when the user clicks on the logout button. Remember, session hijacking is possible because concurrent sessions are possible.

The only and most effective way to attack when having a XSS hole is to launch an attack right on place when the payload is evaluated. If the attacker needs to transfer funds or obtain sensitive information, she most probably will use the XMLHttpRequest object in the background, to automate the entire process. Once the operation is completed, the attacker could leave the user to continue with their normal work or maybe even gain full control of the account my resetting the password and destroying the session by performing a logout operation.

HttpOnly does not protect against all that and it never will. If you plan to use this technology keep in mind that you are still required to make sure that your site/application is XSS free.

If implementing the HttpOnly protection mechanism introduces other problems, you may safely ignore it for the time being. Concentrate on the user input and make sure that nothing is rendered without being carefully sanitized.

Archived Comments

.mario.mario
I totally agree - if a site is XSSable already HTTPOnly cookies fix nothing. When not including a library like jQuery or Prototype it's way easier to create and event-submit a new form that foging a XHR.
christ1anchrist1an
Thanks for this nice writeup, I also think that (unfortunately) a lot of people have a totally wrong understanding of HttpOnly cookies. For those I hope this page comes up first on Google when searching for HttpOnly ;) Apart from that, nothing to add or criticize.
reznrezn
This is a nice description, however I want to point out a small (perhaps semantic) error which I often find people actually believe: "Remember, session hijacking is possible because concurrent sessions are possible." Many people seem to believe this, and thus also believe that if they structure their applications so as to prevent a single user from having multiple concurrent sessions that they are safe from XSS. Using someone's cookies does -not- create a new session - the attacker is sharing a single session with the target. From the application's point of view, this looks like 1 session, not 2 concurrent sessions. While this is obvious to attackers, it is not always obvious to developers, so I think its important not to propagate the misunderstanding.
pdppdp
rezn, I see what you mean. However, the simplest probably check you can do is to verify whether the IP of the user changes. Although in some cases, that could be a problem, since a lot of user could use the same proxy server, it still can improve the situation. You are saying:
Many people seem to believe this, and thus also believe that if they structure their applications so as to prevent a single user from having multiple concurrent sessions that they are safe from XSS.
I don't think that this is the case, although I see how this could tern out to be a problem when the developer does not have good understanding on what is XSS and what damage it can cause.
santa claussanta claus
I want to see if i have this straight. You say that HTTPOnly is completely useless because an attacker doesn't care about cookie information or hijacking sessions, he only cares about CSRFing you into doing something evil. Well, what if the only important thing to the attacker is getting the cookie information? (say, super-duper top secret information is stored there). Then what does the attacker do? I thought you were going to explain an easy way to bypass httponly and get the data stored in cookies. I still think if all you care about is protecting the cookie info from being stolen then httponly is a decent defense. Please correct me. (The only way i know of bypassing httponly is through the TRACE method that jeremiah wrote a whitepaper about. Are there other ways?)
pdppdp
santa claus, you are saying:
You say that HTTPOnly is completely useless because an attacker doesn’t care about cookie information or hijacking sessions, he only cares about CSRFing you into doing something evil.
no.. this is not what I am saying. All I am saying is that you shouldn't relay on HttpOnly cookies to protect against XSS attacks because session hijacking is one of the many things an attacker can do. In fact, most of the times you are not going to perform session hijacking simply because it takes time to get the victim at the right state. If super-duper top secret information is stored there (the cookies) well then you cannot do much unless you use some sort of browser exploit. However, if super-duper top secret information is stored there then the client side won't be able to access it either. What's the point of having info there if you cannot use it. Your server side can access the cookie but again, why do you want to store sensitive information in a cookie? What is the purpose? If someone stores sensitive information in cookies, they are basically asking for trouble.
santa claussanta claus
pdp, Ok, thanks for clearing that up. I understand what you are saying better now.. Great post as always! =]
AcidusAcidus
pdp, You are my hero. Well, my hero after Samy of course.
pdppdp
Acidus, no no, You are my hero.
RSnakeRSnake
This is really old news. This was covered in an email by Thor Larholm 4 years ago: http://www.securityfocus.com/archive/1/307778
pdppdp
RSnake, yup... it is old news. Keep in mind though, that everything new is well forgotten old thing. For example, XSS used to be consider quite lame attack, although it is still quite easy to exploit, until the point some people forgot about it. However, today, XSS is considered as one of the most dangerous Web Application threads. Maybe my example is very clear but, again, keep in mind the following:
Everything new is well forgotten old thing.
Bipin 3~ UpadhyayBipin 3~ Upadhyay
Everything new is well forgotten old thing.
Agreed completely. :) BTW, although HttpOnly doesn't do *much*, yet we cannot deny that it does *something*. Adding another layer to the "Onion Model" is (most of the times) a welcome, IMHO. @PDP: I like the way you write. Most of the times, providing an overview of (or pointers to) basics for noobs. :)
pdppdp
I am glad to hear that.
RoyRoy
I agree it will not (fully) protect you but I strongly recommend having HttpOnly turned on as it improves security by hiding your session id.