[Owasp-topten] OWASP Top 10 - 2017 Release Candidate Feedback

Daniel Christensen Daniel.Christensen at microfocus.com
Thu May 11 20:55:29 UTC 2017


A1 - I'm surprised to see XXE lumped in with injection. Most of the XXE attacks that I've seen would not qualify as traditional injection attack where an attacker controls a part of the data that is inserted into a command that is evaluated by an interpreter. In XXE attacks that I have seen the attacker is typically able to control the entire XML document body including the DTD and because of a misconfiguration of the XML parser is able to access files or make remote connections that were not intended. I see this as completely different than a SQL, OS, LDAP or XPath injection. In training that I've prepared internally for my own organization, I usually put XXE into it's own category.



?? - I was disappointed not to see deserialization attacks make the list in any form. Over the last several years, I've seen an increase in attacks against built-in deserialization API's specifically in Java and Python. In app sec training that I have administered, I recommend that any binary or base64 data in a web request/response be flagged as suspicious and investigated for exploit potential.



A2 - I'm surprised to see this still featured so high on the list. I guess if the list is ordered by impact it would make sense to put this near the top of the list. However, in terms of prevalence, I just don't see these sorts of mistakes very commonly anymore.



A5/A9 - I feel like A9 (Using known vulnerable components) could/should be combined with A5. A5 already makes mention of keeping software up to date. Also, I believe that the issue of using insecure components deserves to share the prominence of the A5 position.



A7 - I have mixed feeling about this. I definitely think that good logging is important for an application. I also feel that rate limiting can be important in certain aspects of an application (particularly in preventing brute force login attempts). However, every time that I've seen runtime attempts to mitigate an attack in some way other than addressing the root cause (i.e. detecting and filtering things that _look_ like XSS instead of properly escaping user input when reflected in HTML) it almost always leads to scenarios that make it harder to test an application's security without actually improving the security of the application.



A10 - This feels entirely redundant to me. An API (well, particularly a ReST or SOAP api) really IS a web application. As such A1-A9 (maybe with the exception of A3) applies directly to apis. I don't see the point in calling this out separately.



-Dan





Daniel L. Christensen

Distinguished Engineer

Micro Focus

http://www.microfocus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170511/aa357af1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Daniel Christensen.vcf
Type: text/x-vcard
Size: 2849 bytes
Desc: not available
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170511/aa357af1/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4508 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170511/aa357af1/attachment.bin>


More information about the Owasp-topten mailing list