Why HttpOnly Won't Protect You
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]; HttpOnlyThe 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
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.
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 therethen 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.
Everything new is well forgotten old thing.
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. :)
