3 ms·
There are lots of good reasons why application developers sometimes don't write secure code. For example, security can be an afterthought if the logic is so com
by brianpgordon 8y ago
There are lots of good reasons why application developers sometimes don't write secure code. For example, security can be an afterthought if the logic is so complex that you can barely get it working in the first place. Another example is that it's not necessarily clear when you write a component that it will be exposed to potentially malicious inputs. And there's always pressure to ship a working product so, without a clear mandate from the organization, security can fall by the wayside as a priority.
One thing that's not a valid reason is the one that the author gave. "Hur dur I develop web apps and I've never heard of XSS" isn't excusable. You have to know about this stuff, even if it's not your expertise.
- tptacek 8y agoWhere do you draw the line? They need to know about XSS. Presumably you think they need to know about SSRF, too. What about clickjacking? Cache poisoning? What percentage of web developers in the industry do you think understand cache poisoning attacks?
- cthor 8y agoI think drawing the line at the OWASP top 10 is reasonable.
- tptacek 8y agoOk, but if you're drawing the line at the vulnerabilities that have gotten the most promotion and documentation and not the ones that have the most impact or prevalence, isn't your standard cosmetic? For instance: you've let developers off the hook for SSRF.
- brianpgordon 8y agoThere's rarely a bright line for competence in anything. But I'd say that, at least, everyone should know about something as basic as XSS. I'd throw in SQL injection and CSRF as well. As you get more obscure, you still expect most people to know about it, but it gets less astonishing if a given person doesn't. Also there's a legitimate case for vulns that exist so far outside of your stack that you never run into them. It would be surprising, but not actually dangerous, if a pure Java developer wasn't familiar with buffer overflows, heap spraying, ASLR, etc. Same for most application-level developers and hardware-level issues like Spectre. But I maintain that the author's example of XSS for a web developer is way unreasonable.
- goliatone 8y agoThe answer for that would ideally be all? We, as developers should be aware and ready to learn and build the experience around security , but a different thing are focus and ownership. You still want experts to drive specialized fields. I run all my architecture reviews by the security team and ask them to comment- internal RFCs. Very similar approach as with infrastructure/devops. Except the gap between dev and security is wither than between dev and ops. I recognize that is very dependent on both organizations and individuals but I shy away from hiring people that at don’t have at the very minimum the interest or awareness in security. I also shy away from business that see security as an afterthought
- tptacek 8y agoI just want the standard to be coherent. If it's "you have to know everything", then fine, let's say that. But saying things like "at least they should know the OWASP Top 10" doesn't make much sense to me.
- Alex3917 8y agoAren't most (non-insider) data breaches the result of OWASP top 10 things though? If the goal of security is to make sure the costs of stealing an asset exceed the value of that asset, then ensuring that the least-expensive-to-exploit vulnerabilities have been mitigated first seems like a good place to start. The fact that there may be other vulnerabilities that are just as dangerous doesn't mean it's equally bad to have vulnerabilities like that, if they require more time and sophistication to exploit. E.g. you shouldn't have string comparison timing vulnerabilities in your code, but having them is less bad than a SQL injection attack even if they can both lead to the same result.
- tptacek 8y agoNo, I don't think there's much science to the OWASP Top 10.