[Owasp-topten] OWASP Top 1- 2017 RC1

Colin Watson 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/
> Top10/tree/master/2017/datacall
>
> +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
> https://www.owasp.org/index.php/OWASP_AppSec_Pipeline
>
>
> _______________________________________________
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-topten
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170417/3148e83a/attachment.html>


More information about the Owasp-topten mailing list