4 ms·

The "Secure" flag has nothing to do with protecting against XSS. It protects against anyone who can proxy your requests (i.e. when you connect to dodgy wifi) be

The "Secure" flag has nothing to do with protecting against XSS. It protects against anyone who can proxy your requests (i.e. when you connect to dodgy wifi) being able to steal your session simply by injecting <img src="http://yoursite.com"> http://yoursite.com"> into any non-secure web page your request. That is a massive security hole and not theatre in the slightest. The HTTP-only flag is less important but still useful. As I said, you're still in deep shit because of course they can make actual requests and if you think it's all you need to protect you then that's a problem. But there's still a difference between an attack that can be persisted, and one that gets interrupted as soon as the user navigates away from the page.

zkhalique 10y ago
I'm talking only about the httpOnly flag. It's worse than useless because it makes you think that you dodged some kind of bullet, when in fact that same class of attack can still happen: the attacker needs to craft a script to send the cookie to their server, so they might as well have that script execute the actual requests in the context of your authorized session, the same way that they'd do it if they had your cookie. They would write the script ahead of time. No real attacker would sit there at 3 AM making requests because their victim finally activated a script that sent them the cookie. Far more likely, that script is already pre-programmed to do what it needs to do. And if httpOnly cookies didn't exist, the people would care more about sanitizing their Javascript output to prevent XSS, which is the only correct way to prevent this attack.
- ubernostrum 10y ago
  For what it's worth, I agree with the criticisms of HttpOnly, but I still recommend people set it as one of several redundancy measures. The approach I take these days (for example: when I gave a three-hour tutorial on web app security at DjangoCon this week) is basically to provide combinations of basic mitigations and then more complex/advanced ones, and push people do at least some combination of them, even if they can't do all of them. So to take XSS/CSRF, for example: Django's template system autoescapes variable output by default, and there's a CSRF protection mechanism on by default. Those are the basic easy things, because the advice is just "they're on already, don't turn them off", and just those simple measures will deal with a lot of nastiness for you. From there I can talk about cookie options, or CSP, or that kinda-sorta-works header that turns on reflection detection in a few browsers, and the pros and cons of each, and recommend people use combinations of them. CSP is my gold-standard recommendation nowadays, and I downplay HttpOnly as not super great, but I'm not going to complain if somebody just watches my talk and does all the things mentioned.

zkhalique 10y ago

I'm talking only about the httpOnly flag. It's worse than useless because it makes you think that you dodged some kind of bullet, when in fact that same class of attack can still happen: the attacker needs to craft a script to send the cookie to their server, so they might as well have that script execute the actual requests in the context of your authorized session, the same way that they'd do it if they had your cookie. They would write the script ahead of time. No real attacker would sit there at 3 AM making requests because their victim finally activated a script that sent them the cookie. Far more likely, that script is already pre-programmed to do what it needs to do. And if httpOnly cookies didn't exist, the people would care more about sanitizing their Javascript output to prevent XSS, which is the only correct way to prevent this attack.

ubernostrum 10y ago
For what it's worth, I agree with the criticisms of HttpOnly, but I still recommend people set it as one of several redundancy measures. The approach I take these days (for example: when I gave a three-hour tutorial on web app security at DjangoCon this week) is basically to provide combinations of basic mitigations and then more complex/advanced ones, and push people do at least some combination of them, even if they can't do all of them. So to take XSS/CSRF, for example: Django's template system autoescapes variable output by default, and there's a CSRF protection mechanism on by default. Those are the basic easy things, because the advice is just "they're on already, don't turn them off", and just those simple measures will deal with a lot of nastiness for you. From there I can talk about cookie options, or CSP, or that kinda-sorta-works header that turns on reflection detection in a few browsers, and the pros and cons of each, and recommend people use combinations of them. CSP is my gold-standard recommendation nowadays, and I downplay HttpOnly as not super great, but I'm not going to complain if somebody just watches my talk and does all the things mentioned.