I'm a product security engineer. I reference these all of the time during my own work to make sure I didn't miss something stupid, but I also hand links out to them to engineers when we do find bugs in their code. Most of the time I think they're ignored.
If most engineers just took a second to read the ones that were directly pertinent to their projects and tried to be cognisant of some mitigations, I'd find substantially less low-hanging-fruit vulnerabilities in the first review pass. Doing so actually makes my job significantly more difficult, and forces me to dig deeper - which is a good thing. Instead of writing up for the 100th time some input validation spiel, I can spend time searching for more complex bugs, writing protocol fuzzers, and doing real analysis in the time I have for the review.
I've been on both sides of this game - worked as a developer and also worked as a penetration tester. I've seen pen testers laugh at the stupid vulns that developers introduce and I've laughed at a few myself. But I've also seen the deadlines as a developer, bugs that are bringing the whole system down and costing the company lots of money, legacy code that is extremely hard to understand and difficult to even get your feature working.
Those on the security side often only think "its really not that difficult to make it secure, just follow these guidelines and you'll be fine", but they don't realise the myriad of other issues that the developers are dealing with.
EDIT: Security needs to be encouraged from the top down. If management is onboard with follow secure practices then they need to also understand that that means things might take a little longer to complete.
When programmers feel frustrating repetition they automate.
The way to reach people is not with scolding but with scanners that are easy to use, helpful, and don't have lots of false positives.
The thing that I find difficult with OWASP: there doesn't always seem to be comprehensive examples provided for what these attack surfaces could be used for. That makes it difficult to both understand the impact of a particular issue, and test for it.
rarecoil|6 years ago
If most engineers just took a second to read the ones that were directly pertinent to their projects and tried to be cognisant of some mitigations, I'd find substantially less low-hanging-fruit vulnerabilities in the first review pass. Doing so actually makes my job significantly more difficult, and forces me to dig deeper - which is a good thing. Instead of writing up for the 100th time some input validation spiel, I can spend time searching for more complex bugs, writing protocol fuzzers, and doing real analysis in the time I have for the review.
theworld572|6 years ago
Those on the security side often only think "its really not that difficult to make it secure, just follow these guidelines and you'll be fine", but they don't realise the myriad of other issues that the developers are dealing with.
EDIT: Security needs to be encouraged from the top down. If management is onboard with follow secure practices then they need to also understand that that means things might take a little longer to complete.
drewcoo|6 years ago
bluepnume|6 years ago
As an example: https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security...
I'm fascinated to know how this could actually be exploited. But there's no hint or reference to that. It's just "don't do this".
brennebeck|6 years ago
bashwizard|6 years ago
[deleted]