[Owasp-topten] A9, again

Abbas Naderi abbas.naderi at owasp.org
Wed Feb 20 06:43:24 UTC 2013


Well those are the changes I asked for in the first comment.

The title -> Using insecure third party libraries (instead of tools)

The description -> Libraries of old used in the application

On ۲ اسفند ۱۳۹۱, at ۱:۲۴, Neil Smithline <neil.smithline at owasp.org> wrote:

> Responses inline
> 
> 
> 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 tree.
> 
> 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 development. 
>  
> 
> 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.
>  
>  
> Thanks
> -Abbas
> 
> On ۱ اسفند ۱۳۹۱, at ۲۲:۱۷, Neil Smithline <neil.smithline at owasp.org> wrote:
> 
>> 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 mistake.
>> 
>> 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 dire.
>> 
>> 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 T10.
>> 
>> Neil
>> 
>> 
>> 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 easily. 
>> 
>> 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.
>> 
>> -Abbas
>> 
>> On ۱ اسفند ۱۳۹۱, at ۲۰:۴۸, Neil Smithline <neil.smithline at owasp.org> wrote:
>> 
>>> 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 risk. 
>>> 
>>> 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, that:
>>> 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.
>>> Neil
>>> _______________________________________________
>>> 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/20130220/efbccb50/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4889 bytes
Desc: not available
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20130220/efbccb50/attachment.bin>


More information about the Owasp-topten mailing list