[Owasp-topten] A9, again
neil.smithline at owasp.org
Tue Feb 19 21:54:41 UTC 2013
On Tue, Feb 19, 2013 at 2:00 PM, Abbas Naderi <abbas.naderi at owasp.org>wrote:
> I think you got the wrong idea about A9.
Maybe. If we are interpreting it differently, that may indicate the need
for some rewording.
The current A9 meant usage of insecure third party libraries and tools in
> your application, not like using insecure operating system.
Yes. A9 only refers to components. But I don't see why that is the case. A9
uses Apache as an example. Apache is a platform, albeit a smaller one than
Linux or Windows, but still a platform. I don't see a clear delineation of
"components" and "OS".
> It is indeed an issue in non-web systems, but is most bold when it comes
> to web.
Same is true for buffer overflow.
> It can be easily detected by manual review and also can be detected by
> automated tools, e.g search for PHPExcel version 2.0 and below in a project
Buffer overflow is harder to detect than old versions of components but
there still are automated tools that can discover them..
> It is also (IMHO) directed first towards developers, and second towards
> admins. I don't see what it has to do in post deployment.
Your components are most likely to be up to date at the time of deployment.
The "How Do I Prevent" box explicitly says:
- Monitor the security of these components in public databases, project
mailing lists, and security mailing lists, and keep them up-to-date.
One could argue that A9 only means prior to shipping but the real risk
seems to be post shipping as new problems are discovered. Consider the
recent rash of Mass Assignment issues. The majority of updates to safer
versions of the frameworks will occur on live systems rather than ones in
> I'm assuming that you have another description of A9 in mind, so would you
> please describe it as you see to us as well?
Hope I've done that.
> On ۱ اسفند ۱۳۹۱, at ۲۲:۱۷, Neil Smithline <neil.smithline at owasp.org>
> First, thanks Abbas for mentioning the A4/A7 merge topic. There have been
> several emails about that. All I did was a quick skim of the T10 emails and
> missed that topic.
> I don't think my feelings about A9 have to do with me being uncomfortable
> with the new flavor of it. I think that the change from 2010 to 2013 is the
> smallest incremental change between any two consecutive T10s. I was
> comfortable with all of the changes. Even the dropping of buffer overflow
> between the 2004 and 2007 T10s. Something I initially thought was a large
> The explanation for dropping buffer overflow in the 2007 T10 is:
> Remediation for [buffer overflow] issues is covered by the traditional
> non-web application security community, such as SANS, CERT, and programming
> language tool vendors
> That is one of the four reasons that I feel that A9 doesn't belong in the
> OWASP T10. The other three being that A9
> - Cannot be detected by manual or automated code reviews.
> - Cannot be managed by T10 target audiences. It is primarily not a
> developer, QA, CM, installation service, configuration, etc... concern.
> - *Is of greatest relevance after the product has been deployed*.
> If we are deciding that we will include non-web specific risks then I
> think that Buffer Overflow deserves serious consideration. While it may be
> less common than other risks, the ramifications of buffer overflow can be
> Please note that I like the T10's focus on web app sec. That's one of the
> reasons I think that A9, like buffer overflow, doesn't belong in the OWASP
> On Tue, Feb 19, 2013 at 12:27 PM, Abbas Naderi <abbas.naderi at owasp.org>wrote:
>> From what I have seen, there were as same emails about merging A4 and A7.
>> Also keep in mind that A9 is a change, and many can't accept change
>> In contrary, I believe that A9 belongs there as we are listing Top Ten
>> Web Application Security Flaws (or Vulnerabilities) and it is really one of
>> them (by definition). I know that it's not like the other 9, but that
>> doesn't mean it should not be there.
>> On ۱ اسفند ۱۳۹۱, at ۲۰:۴۸, Neil Smithline <neil.smithline at owasp.org>
>> Based on the highly non-scientific results of quickly scanning through my
>> T10 emails, I think that the most discussed issue is A9. Furthermore, I
>> think it is the only one that people have suggested fundamental changes to.
>> Regarding the T9 comments:
>> - Over half of them have suggested a name change.
>> - Several have suggested renaming
>> - Several have suggested expanding it to include platform level entities
>> such as OSs and programming languages,
>> - At least two, Steven van der Baan's and mine, have suggested that A9
>> doesn't belong in the T10 at all.
>> The problem is that everyone seems to agrees that A9 is a substantial
>> I wonder if there is a halfway point between A9 being in the T10 and not
>> being in the T10. Perhaps the Additional Risks section could be promoted to
>> a page of its own that adds more detail for several of the additional
>> risks. A9 could then be moved to there. This would knock it out of the T10
>> while keeping it in the T10 document.
>> This would also allow expanded discussion of some of the other additional
>> risks that may not be worthy of being in the T10 but worthy of being in the
>> document. For example, discussing mitigation for DOS and DDOS seems
>> particularly important with the recent rise of hactivists. There is no way
>> that DDOS belongs in the T10 but it seems worthy of more than a single link
>> at the bottom of some page in the back of the T10 document.
>> To reiterate my objections to A9, I believe that it is unique because it
>> is a weakness that it is the only 2013 T10 and, perhaps, the only T10 ever,
>> - Cannot be detected by manual or automated code reviews.
>> - Is a generic programming problem and not a web-specific problem. If
>> I recall correctly, this litmus test caused risks such as Buffer Overflow
>> to be left to the CWE-25.
>> - Cannot be managed by T10 target audiences. It is primarily not a
>> developer, QA, CM, installation service, configuration, etc... concern.
>> - *Is of greatest relevance after the product has been deployed*.
>> Owasp-topten mailing list
>> Owasp-topten at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-topten