This looks like a great candidate for stack overflow documentation.
A practical security guide for web developers
21–30 of 71 posts
Re: A practical security guide for web developers
#22One thing I totally disagree with:
"Set secure, httpOnly cookies."
That is just security theater. It's worse than useless because it makes you think you're more secure, when you haven't prevented attacks are all.
Re: A practical security guide for web developers
#23One thing I totally disagree with: "Set secure, httpOnly cookies." That is just security theater. It's worse than useless because it makes you think you're more secure, when you haven't prevented attacks are all.
This is not security theatre.
Secure => Attacker can't simply inject an img to a non-https version of the site and then intercept the cookie sent by the browser, therefore stealing the session.
HTTP-only => An XSS attack can't steal the session cookie. You're still in big shit, but it's much harder to persist the attack beyond the user closing the browser window.
Re: A practical security guide for web developers
#24One thing I totally disagree with: "Set secure, httpOnly cookies." That is just security theater. It's worse than useless because it makes you think you're more secure, when you haven't prevented attacks are all.
This is not security theatre. Secure => Attacker can't simply inject an img to a non-https version of the site and then intercept the cookie sent by the browser, therefore stealing the session. HTTP-only => An XSS attack can't steal the session cookie. You're still in big shit, but it's much harder to persist the attack beyond the user closing the browser window.
It is security theater. Real attackers don't sit there waiting for a cookie to arrive so they can start to craft their malicious authenticated requests. If they can write a script to steal your cookie, they can also write a script to execute the actual requests right there in your session. And httpOnly cookies do not prevent that at all. Security theater is worse than nothing because you think you're secure from XSS, when you should know better.
Re: A practical security guide for web developers
#25Earlier quoted context omitted.
This is not security theatre. Secure => Attacker can't simply inject an img to a non-https version of the site and then intercept the cookie sent by the browser, therefore stealing the session. HTTP-only => An XSS attack can't steal the session cookie. You're still in big shit, but it's much harder to persist the attack beyond the user closing the browser window.
It is security theater. Real attackers don't sit there waiting for a cookie to arrive so they can start to craft their malicious authenticated requests. If they can write a script to steal your cookie, they can also write a script to execute the actual requests right there in your session. And httpOnly cookies do not prevent that at all. Security theater is worse than nothing because you think you're secure from XSS,…
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 " rel="nofollow">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.
Re: A practical security guide for web developers
#26Had this SO link saved since probably soon after it was asked 7 years ago. Still relevant and still being updated. http://stackoverflow.com/questions/549/the-definitive-guide-... Includes: - How to log in - How to remain logged in - Managing cookies (including recommended settings) - SSL/HTTPS encryption - How to store passwords - Using secret questions - Forgotten username/password functionality - Use of nonces to p…
The quote at the beginning of the SO question you linked to, one of the top-25 questions of all time, is so ironic given the current state of SO:
> We believe that Stack Overflow should not just be a resource for very specific technical questions, but also for general guidelines on how to solve variations on common problems.
SO is a great website, but I wonder how much more it could've been if this sort of a page was allowed now.
Re: A practical security guide for web developers
#27Earlier quoted context omitted.
It is security theater. Real attackers don't sit there waiting for a cookie to arrive so they can start to craft their malicious authenticated requests. If they can write a script to steal your cookie, they can also write a script to execute the actual requests right there in your session. And httpOnly cookies do not prevent that at all. Security theater is worse than nothing because you think you're secure from XSS,…
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 " rel="nofollow">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…
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.
Re: A practical security guide for web developers
#28Use static source code analysis and dynamic web app scanners.
They are easy to integrate into your SDLC, they are not going to replace manual testing or secure development practices but they'll help a lot. They'll pick up tons of stuff for free, they'll remind you best practices.
I have a startup (at least it still feels like a startup!) and we are developing a web application security scanner called Netsparker [0]. It found over 100 zero days in open source applications while testing it [1], including very popular vulnerabilities in applications such as Wordpress and Joomla. I guess that by itself proves how good scanning can be.
If you want to try it on your websites and see it for yourself drop an email / message to contact@netsparker.com with a mention of HN and I'll get you a fully functional trial that you can use on your own websites.
[0] Netsparker Cloud https://www.netsparker.com/online-web-application-security-s... - Netsparker Desktop https://www.netsparker.com/web-vulnerability-scanner/
Re: A practical security guide for web developers
#29Use static source code analysis and dynamic web app scanners. They are easy to integrate into your SDLC, they are not going to replace manual testing or secure development practices but they'll help a lot. They'll pick up tons of stuff for free, they'll remind you best practices. I have a startup (at least it still feels like a startup!) and we are developing a web application security scanner called Netsparker [0].…
Hey I wanted to let you know I thought your slogan on your website was a bit confusing at first "False Positive Free Web Application Security Scanner" I grokked it as "False Positive, free web application security scanner"
Re: A practical security guide for web developers
#30There's a whole section on input sanitization but nothing on escaping output.
If you're on the hook to sanitize all inputs, doesn't that mean you're not escaping output?
The biggest security mistake I've made so far in production was that one time I used an HTML templating library that didn't escape output by default.