[Owasp-topten] OWASP Top 1- 2017 RC1

Tony Turner tony.turner at owasp.org
Sun Apr 16 14:35:41 UTC 2017


I keep seeing data linked but the analysis doesn't make any sense with regards to updates for 2017. 

Sent from my iPhone

> On Apr 16, 2017, at 8:40 AM, 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/20170416/88e28394/attachment.html>


More information about the Owasp-topten mailing list