[Owasp-topten] OWASP Top 1- 2017 RC1

Aaron Weaver aaron.weaver2 at gmail.com
Sun Apr 16 12:40:35 UTC 2017

Hi Dex - The data is in the github repo -

+1 on A10

On Sun, Apr 16, 2017 at 7:51 AM, dex black <dexblack254 at gmail.com> wrote:

> Greetings All.
> I read this update with some dismay; specifically in regards to the two
> new items.
> A7 Insufficient Attack Protection
> It seems a little odd to call a lack of attack detection code a
> vulnerability.
> The demonstrable need for such code varies wildly with the type of web
> site and therefore doesn't pass the test of general applicability.
> Perhaps when/if such code becomes more common place and turns out to have
> security flaws of its own we might return to this category of
> vulnerability. In all likelihood site administrators may become vulnerable
> to hubris around the efficacy of their COTS/homegrown attack detection
> solution(s); or worse yet some attack detection solution itself becomes an
> attack vector.
> A10 Underprotected APIs
> Cognisant of the fact that web APIs are a burgeoning area of development
> does not mean that the API itself, as a whole, is a vulnerability.
> When looking closely at the details of this item we see the same issues as
> always.
> 1. Ensure that you have secured communications between the client and your
> APIs.
> == A5 – Security Misconfiguration
> 2. Ensure that you have a strong authentication scheme for your APIs, and
> that all credentials, keys, and tokens have been secured.
> == A2 – Broken Authentication and Session Management
> 3. Ensure that whatever data format your requests use, that the parser
> configuration is hardened against attack.
> == A9 – Using Components with Known Vulnerabilities
> 4. Implement an access control scheme that protects APIs from being
> improperly invoked, including unauthorized function and data references.
> == A4 – Broken Access Control
> 5. Protect against injection of all forms, as these attacks are just as
> viable through APIs as they are for normal apps
> == A1 Injection
> What is the justification for repackaging or reclassifying these as a
> single unit?
> It seems to obfuscate the clarity of the existing list more than anything
> else.
> Bundling A4 and A7 together to make room for A10 probably isn't worth the
> cost in terms of altering training materials, certification assessment
> criteria, tooling and reporting.
> It might make a little sense due to ongoing confusion about the specific
> classifications.
> IMHO that still doesn't justify the proposed A10 Underprotected APIs.
> I also second a previous posting regarding transparency around the
> decision process.
> May we see the data?
> Has the threat and vulnerability landscape really changed much within the
> scope of web based technologies?
> Regard
> David 'dex' Schwartz
> _______________________________________________
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-topten

Aaron Weaver
Philadelphia OWASP Chapter Lead
OWASP AppSec Pipeline Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170416/c0ad8800/attachment.html>

More information about the Owasp-topten mailing list