3 ms·

It lessens your potential attack surface and comes at no cost. And as security-ignorant devs are concerned (which we all are from time to time) it doesn't magic

by Udo 16y ago

It lessens your potential attack surface and comes at no cost. And as security-ignorant devs are concerned (which we all are from time to time) it doesn't magically fix vulnerabilities, but it can alleviate the magnitude of exploits. It's a good idea.

tptacek 16y ago
Try to articulate how it lessens the attack surface. It means you can't bank up session tokens; instead, you're only able to do everything that a session token would do for you anyhow. Remember in your explanation that session tokens already expire anyways.
- Udo 16y ago
  By sending the HttpOnly flag as a server application, I indicate to the browser that it should prevent client-side scripts from obtaining the actual value of the cookie. Hence, it is more difficult for a malicious little piece of smuggled-in XSS code to steal my session id and ship it off to some Nigerian server. Is it circumventable? Yes. Are different browser implementations subverting this scheme? Yes. But is the intention behind it worthwhile? ...I think so. Of course, that kind of protection is superficial, but please try to remember in your rebuttal there are actual attacks still happening that could have been prevented by setting this simple flag. An insistence on always making secure code that won't have this problem anyway is honorable but not realistic. By the way, it happens on high profile sites, too. It shouldn't, and it makes us web devs uncomfortable even observing it from a distance, but it still happens. Even disregarding this argument, for me HttpOnly is the way cookies should have been conceived by default. I believe accessing cookie values by JavaScript is pathological. The behavior HttpOnly attempts to trigger on the client seems like good practice to me, and given (again) the point that it comes at no cost to the reasonable developer, turning it on is really a no-brainer. In fact, browsers should turn it on whether the flag is set or not. It means you can't bank up session tokens; instead, you're only able to do everything that a session token would do for you anyhow. Oh, you can still use other exploits to bank up tokens, but yes this particular avenue is blocked. You're absolutely right, having the current session to work with is pretty destructive. But I think shipping off session IDs to a hostile server is worse than issuing false requests on behalf of the user in an already open browser window. That's because siphoning session IDs is silent and can lead to problems many days later when you're _not_ online. Try to articulate [...] Remember in your explanation that session tokens already expire anyways. Alright, I'll try not to drool and babble more than necessary: for the sake of convenience we are used to very long-lasting session tokens. So when you say they expire, yes, it limits the amount of damage somewhat, but not in any meaningful way considering the typical cookie-based account identifier lasts well beyond a week. Certainly for the purpose of completing my answer I can now say "I remembered" session expiration but it didn't really go anywhere.

by Udo 16y ago

tptacek 16y ago

Try to articulate how it lessens the attack surface. It means you can't bank up session tokens; instead, you're only able to do everything that a session token would do for you anyhow. Remember in your explanation that session tokens already expire anyways.

Udo 16y ago
By sending the HttpOnly flag as a server application, I indicate to the browser that it should prevent client-side scripts from obtaining the actual value of the cookie. Hence, it is more difficult for a malicious little piece of smuggled-in XSS code to steal my session id and ship it off to some Nigerian server. Is it circumventable? Yes. Are different browser implementations subverting this scheme? Yes. But is the intention behind it worthwhile? ...I think so. Of course, that kind of protection is superficial, but please try to remember in your rebuttal there are actual attacks still happening that could have been prevented by setting this simple flag. An insistence on always making secure code that won't have this problem anyway is honorable but not realistic. By the way, it happens on high profile sites, too. It shouldn't, and it makes us web devs uncomfortable even observing it from a distance, but it still happens. Even disregarding this argument, for me HttpOnly is the way cookies should have been conceived by default. I believe accessing cookie values by JavaScript is pathological. The behavior HttpOnly attempts to trigger on the client seems like good practice to me, and given (again) the point that it comes at no cost to the reasonable developer, turning it on is really a no-brainer. In fact, browsers should turn it on whether the flag is set or not. It means you can't bank up session tokens; instead, you're only able to do everything that a session token would do for you anyhow. Oh, you can still use other exploits to bank up tokens, but yes this particular avenue is blocked. You're absolutely right, having the current session to work with is pretty destructive. But I think shipping off session IDs to a hostile server is worse than issuing false requests on behalf of the user in an already open browser window. That's because siphoning session IDs is silent and can lead to problems many days later when you're _not_ online. Try to articulate [...] Remember in your explanation that session tokens already expire anyways. Alright, I'll try not to drool and babble more than necessary: for the sake of convenience we are used to very long-lasting session tokens. So when you say they expire, yes, it limits the amount of damage somewhat, but not in any meaningful way considering the typical cookie-based account identifier lasts well beyond a week. Certainly for the purpose of completing my answer I can now say "I remembered" session expiration but it didn't really go anywhere.