[Owasp-topten] OWASP Top 1- 2017 RC1
colin.watson at owasp.org
Mon Apr 17 17:02:58 UTC 2017
+1 too regarding A10
On 16 April 2017 at 13:40, Aaron Weaver <aaron.weaver2 at gmail.com> wrote:
> Hi Dex - The data is in the github repo - https://github.com/OWASP/
> +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
>> 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
>> 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
>> 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?
>> David 'dex' Schwartz
>> Owasp-topten mailing list
>> Owasp-topten at lists.owasp.org
> Aaron Weaver
> Philadelphia OWASP Chapter Lead
> OWASP AppSec Pipeline Lead
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-topten