<div dir="ltr"><span style="font-size:12.8px">There have been numerous questions in various places around the rationale for adding A7 and A10 to the 2017 RC. Fair questions, and we’re really glad that there’s interest and passion about appsec. Here's some background on how a new T10 is produced:</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">First off, the data call is only one source of input to an update of the Top 10. It helps us understand if anything significant is happening in the prevalence of the existing Top 10 risks plus of course are there any new issues that are rising in prevalence. We are particularly interested in any type of new issue we aren't well aware of. Most of the newer issues are already in the "Additional Risks to Consider" list at the bottom of the 2nd to last page of the T10 and its frequently one of those that moves up into a new T10. Other sources of input are the answers to the questions asked of the data providers, the experience of the Top 10 team, and our interactions with the OWASP community and the AppSec community at large.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Based on this input, we develop what we feel are the Top 10 Risks to Web Applications that application owners currently face today. Over the years, we have frequently introduced new Top 10 items that deserved to be in the Top 10, even though the vulnerability prevalence data didn't agree. For example, CSRF was added to the 2007 Top 10 even though the data reported its prevalence as 32. Three years later, CSRF was indeed a Top 10 most prevalent issue, partially we believe because of the attention to this risk that the T10 generated (which is a good thing!). Similarly, in the 2013 update, the Top 10 added "Using Components with Known Vulnerabilities", and the 2017 data call shows that this issue too is now being reported as a Top 10 risk (by prevalence).</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">So why did we add A7 and A10?</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">A7 started with the data that Insufficient Anti-automation was being reported more frequently. We don't think that this issue is particularly new, nor is the fact that its being reported more indicate this risk is more prevalent. We think its indicative that people should and do care about this risk more, so organizations are willing to spend time looking for and reporting such issues; and putting defenses in place. There are also both old and new OWASP projects on this topic such as OWASP AppSensor and the new (and fantastic) Automated Threats to Web Applications project: <a href="https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications" target="_blank">https://www.owasp.<wbr>org/index.php/OWASP_Automated_<wbr>Threats_to_Web_Applications</a>. However, the project felt that the risk was beyond Insufficient Anti-automation, but rather insufficient defenses against attacks in general, which is why we generalized the name of this risk to: "Insufficient Attack Protection". We think this category should cover: Insufficient attack detection, insufficient attack response, insufficient defense against automated threats, and insufficient ability to patch quickly.  We were actually concerned that people would solely focus on Insufficient Anti-Automation so we dialed back our focus on that in the writeup to such a degree that, to some people, it appears to be completely missing from this category, which was not our intent and we need to fix that.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">A10 was added to raise awareness that the use of APIs is exploding, and deserves special attention to protect them properly. We understand that this new category overlaps with all the other items in the T10 and that's OK. The whole purpose of the T10 is to raise awareness of the Top risks to web applications today and the project feels that this topic deserves some sunshine and focus on this new trend in web development.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div style="font-size:12.8px">Philosophically, we’re not trying to create a strict taxonomy or make sure that the Top <span style="font-size:12.8px">10</span> don’t overlap. Risks often overlap with each other and that’s okay.  As an awareness document, we’re trying to focus on attention to issues that affect large numbers of companies.  We don’t choose the names of the Top <span style="font-size:12.8px">10</span> based on a formula or to keep them parallel. Instead, we try to choose terms that are easy for organizations to latch onto and investigate in their program. That said, we’re very open to new ideas about naming these new additions to make them easier to understand and use.</div><div style="font-size:12.8px"> </div><div style="font-size:12.8px">We recognize that these new items aren’t exactly in line with what’s been in the Top <span style="font-size:12.8px">10</span> previously.  But issuing yet another version of exactly the same thing isn’t very interesting or provocative.  So we’re trying to expand the scope of the T10 to reach beyond just development, and look at some operational aspects of appsec.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">-Dave</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 17, 2017 at 1:02 PM, Colin Watson <span dir="ltr"><<a href="mailto:colin.watson@owasp.org" target="_blank">colin.watson@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+1 too regarding A10</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 16 April 2017 at 13:40, Aaron Weaver <span dir="ltr"><<a href="mailto:aaron.weaver2@gmail.com" target="_blank">aaron.weaver2@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Dex - The data is in the github repo - <a href="https://github.com/OWASP/Top10/tree/master/2017/datacall" target="_blank">https://github.com/OWASP/Top<wbr>10/tree/master/2017/datacall</a><div><br></div><div>+1 on A10</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-5194125549729293937h5">On Sun, Apr 16, 2017 at 7:51 AM, dex black <span dir="ltr"><<a href="mailto:dexblack254@gmail.com" target="_blank">dexblack254@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-5194125549729293937h5"><div dir="ltr"><div style="font-size:12.8px">Greetings All.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><span style="font-size:12.8px">I read this update with some dismay; specifically in regards to the two new items.</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">A7 <span style="background-color:rgb(242,245,247);color:rgb(54,43,54);font-family:sans-serif;font-size:14px">Insufficient Attack Protection</span><span style="background-color:rgb(242,245,247);color:rgb(54,43,54);font-family:sans-serif;font-size:14px"> </span></div><div style="font-size:12.8px">It seems a little odd to call a lack of attack detection code a vulnerability.</div><div style="font-size:12.8px">The demonstrable need for such code varies wildly with the type of web site and therefore doesn't pass the test of general applicability.</div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div>A10 <span style="background-color:rgb(242,245,247);color:rgb(54,43,54);font-family:sans-serif;font-size:14px">Underprotected APIs</span></div>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.</div><div style="font-size:12.8px">When looking closely at the details of this item we see the same issues as always.</div><div style="font-size:12.8px"><br><div>1. Ensure that you have secured communications between the client and your APIs.</div><div>== A5 – Security Misconfiguration</div><div><br></div><div>2. Ensure that you have a strong authentication scheme for your APIs, and that all credentials, keys, and tokens have been secured.</div><div>== A2 – Broken Authentication and Session Management</div><div><br></div><div>3. Ensure that whatever data format your requests use, that the parser configuration is hardened against attack.</div><div>== A9 – Using Components with Known Vulnerabilities</div><div><br></div><div>4. Implement an access control scheme that protects APIs from being improperly invoked, including unauthorized function and data references.</div><div>== A4 – Broken Access Control</div><div><br></div><div>5. Protect against injection of all forms, as these attacks are just as viable through APIs as they are for normal apps</div><div>== A1 Injection</div><div><br></div></div><div style="font-size:12.8px">What is the justification for repackaging or reclassifying these as a single unit?</div><div style="font-size:12.8px">It seems to obfuscate the clarity of the existing list more than anything else.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px">It might make a little sense due to ongoing confusion about the specific classifications.</div><div style="font-size:12.8px">IMHO that still doesn't justify the proposed A10 Underprotected APIs.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I also second a previous posting regarding transparency around the decision process.</div><div style="font-size:12.8px">May we see the data?<br>Has the threat and vulnerability landscape really changed much within the scope of web based technologies?</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Regard</div><div style="font-size:12.8px">David 'dex' Schwartz</div></div>
<br></div></div>______________________________<wbr>_________________<br>
Owasp-topten mailing list<br>
<a href="mailto:Owasp-topten@lists.owasp.org" target="_blank">Owasp-topten@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-topten" rel="noreferrer" target="_blank">https://lists.owasp.org/mailma<wbr>n/listinfo/owasp-topten</a><br>
<br></blockquote></div><span class="m_-5194125549729293937HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-5194125549729293937m_3492927661838494188gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:12.8px">Aaron Weaver</span></div><div>Philadelphia OWASP Chapter Lead</div><span style="font-size:12.8px">OWASP AppSec Pipeline Lead</span><br style="font-size:12.8px"><a href="https://www.owasp.org/index.php/OWASP_AppSec_Pipeline" style="color:rgb(17,85,204);font-size:12.8px" target="_blank">https://www.owasp.org/index.ph<wbr>p/OWASP_AppSec_Pipeline</a><span style="font-size:12.8px"> </span><br style="font-size:12.8px"><br></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Owasp-topten mailing list<br>
<a href="mailto:Owasp-topten@lists.owasp.org" target="_blank">Owasp-topten@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-topten" rel="noreferrer" target="_blank">https://lists.owasp.org/mailma<wbr>n/listinfo/owasp-topten</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Owasp-topten mailing list<br>
<a href="mailto:Owasp-topten@lists.owasp.org">Owasp-topten@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-topten" rel="noreferrer" target="_blank">https://lists.owasp.org/<wbr>mailman/listinfo/owasp-topten</a><br>
<br></blockquote></div><br></div>