[Owasp-topten] Comments on Released: OWASP Top 10 – 2017 Release Candidate
olivier.arteau at owasp.org
Tue Apr 11 23:56:01 UTC 2017
A7 - Insufficient Attack Protection
- WAF and other blocking detection mechanism will never fully protect
against unknown vulnerability. The thing is that they either break your
application through aggressive blocking or have bypass when they aren't
aggressive. Those products have always been crutches for applications that
had poor security or couldn't be updated. Saying that you are vulnerable
because you don't have one in place is really misguided.
- Incident response is operational concerns. It's not an application
security concern. Unless the OWASP Top 10 guide wants to enlarge its scope
to more than just application security, this is simply not at the right
place. The ASVS guide is probably a better place to introduce this.
- Patching software is already covered by A5 and A9. The point #1 of "Am I
vulnerable to Attack?" of A5 is exactly about that : "Is any of your
software out of date?". Perhaps this point should be expanded in A5 or A9
- The OWASP Top 10 is a general document for application security. It
should be about things that apply to almost every web application. I
wouldn't recommend that every web application should to lock account
automatically. This kind of security measure is a trade-off between
usability, security and introducing other security issues (denial of
service for example). OWASP Top 10 may recommend evaluating this choice,
but I don't think it should pick a side especially since it can have
security impact like denial of service (ex.: locking all user account).
- This category addition really feels like it's been lobbied by the WAF
industry as a way to sell more of their product. One of the core values of
the OWASP organization is that it shouldn't be a platform for vendors to
sell their products. Adding categories that favourably affects some vendor
should be weighted more carefully.
A8 - CSRF
- One of the common errors that I see in CSRF implementation is that
tokens are generated, but they are not validated server-side. As stupid as
this may seem, it's surprisingly common. I would propose that the "Am I
Vulnerable to CSRF?" mentions checking if invalid CSRF tokens are rejected
on top of checking if the CSRF tokens are present in the forms.
A10 - Underprocted APIs
- This category can be summarized to "Check the OWASP Top 10 for API
endpoints too". This isn't a category of vulnerability. This should be
integrated through all the other vulnerabilities by specifically mentioning
checking API endpoint too. It might also be better to add a section in the
document titled "What to test ? Where to look for vulnerability ?".
- I think the Top 10 should split the "Sensitive Data Exposure" into two
categories : "Sensitive Data Exposure" and "Incorrect Cryptography Usage".
The problem with cryptography is not just with whether you are using the
right or wrong algorithm (primitive), it's also about how you assemble the
whole thing. "Sensitive Data Exposure" focuses only on whether the
primitive you are using are good (ex.: don't use RC4, MD5, etc.). From
experience a lot of the issues with cryptography that I see come from the
misassembling of the cryptography primitive. They pick "AES" ... but with
the default mode ECB. They pick "AES/CBC" ... but they forget to use HMAC
too (that almost always leads to padding oracle). They use "AES/CBC + HMAC"
... but they MAC before they encrypt. They pick "AES/GCM" or "AES/CBC +
HMAC" ... but they individually encrypt different parameters (this leads to
parameters swapping attack). They pick "SHA256" ... for password storage.
Cryptography is a very hard field that has many caveats and every subtle
mistake can potentially break the whole thing. This is, in my opinion, a
lot more deserving than A7 and A10.
OSCP, B. Ing.
Email : olivier.arteau at owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-topten