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. :)

Everything new is well forgotten old thing.

Ok, thanks for clearing that up.
I understand what you are saying better now..
Great post as always! =]

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.

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?)

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.

“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.

Apart from that, nothing to add or criticize.