6 ms·

You can use the HttpOnly flag with a cookie to prevent JavaScript being able to access it. Here's a good summary: http://www.owasp.org/index.php/HttpOnly http:

You can use the HttpOnly flag with a cookie to prevent JavaScript being able to access it. Here's a good summary: http://www.owasp.org/index.php/HttpOnly http://www.owasp.org/index.php/HttpOnly If you are serving a cookie, and JavaScript doesn't need to be able to access it, you should set it to be HttpOnly to try and reduce the effects of an XSS.

tptacek 16y ago
It doesn't seem like Michal is sold on HttpOnly and I definitely am not either; most everything you can do with a stolen cookie, you can also do quickly and silently using a captive browser during an XSS attack.
- mike-cardwell 16y ago
  True. Still, given the option of having it turned on or off, I'll turn it on. If only it makes an attack a little more difficult it's worth using.
- jacquesm 16y ago
  No cost, potential benefit. I've had to make harder decisions.
  - tptacek 16y ago
    The cost is "false sense of security", and believe me, from field work, that is a real cost. A majority of programmer applicants can't solve FizzBuzz, so you're deluded if you think that a good chunk of webdevs don't think "HttpOnly fixes XSS". The potential benefit is... what, exactly?
    - 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.

tptacek 16y ago

It doesn't seem like Michal is sold on HttpOnly and I definitely am not either; most everything you can do with a stolen cookie, you can also do quickly and silently using a captive browser during an XSS attack.

mike-cardwell 16y ago
True. Still, given the option of having it turned on or off, I'll turn it on. If only it makes an attack a little more difficult it's worth using.
jacquesm 16y ago
No cost, potential benefit. I've had to make harder decisions.
- tptacek 16y ago
  The cost is "false sense of security", and believe me, from field work, that is a real cost. A majority of programmer applicants can't solve FizzBuzz, so you're deluded if you think that a good chunk of webdevs don't think "HttpOnly fixes XSS". The potential benefit is... what, exactly?
  - 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.