[Owasp-topten] My points on the Top Ten RC1

Steven van der Baan steven.van.der.baan at owasp.org
Sun Feb 17 15:31:03 UTC 2013


The top ten's number one hit should be developers, but isn't. Not even
by a long shot. It's predominantly used within the pentesting and
management world (PCI). The top ten is still seen as the web application
risk top ten. If you steer away from this main viewpoint you will loose
this user base. And from experience, it is more important that managers
know about security ( and have the capability of enforcing the
implementation of it), than of enthusiastic developers who will be
stopped because of lack of resources (time and/or money).

On 17/02/2013 14:25, Abbas Naderi wrote:
> Hi all,
> I strongly believe that A9 is the right choice for 2013 and it must've
> been around. Top Ten's number one hit are developers. It's not how to
> pen test a system, or how to assess security. Its top 10 flaws in
> software, and why they are there. A9 is good.
> I have reposted my comments on other issues, feedback is welcome:
>> A few comments on RC 2013, which is my own opinion as well as opinion
>> of countless people who have contacted me as OWASP official of my region:
>> One of the worst things about top ten - which countless people
>> contact me about everyday - are complex titles. Why not replace
>> Missing Function Level Access Control with Insufficient Access
>> Control? Everybody knows what access control and insufficient means,
>> but without reading the description nobody will know what function
>> level in the context is supposed to mean.
>> I don't see a clear distinction between A4 (which has a very
>> mysterious title and has held it for 10 years now) and A7. They are
>> basically the same thing, and I assume the correct position is indeed
>> A4. What current A4 has (and have had) only boggles the minds of
>> developers who haven't experienced it before. I think the correct way
>> would be to just name it insufficient access control. Everyday apps
>> require access control on every single task.
>> I also suggest changing the following from A2 Authentication:
>> 1.
>>     Are credentials always protected when stored using hashing or
>>     encryption? See A6. 
>>  to
>> 1. Are credentials stored using cryptographically secure hashing and
>> encryption? 
>> What I see is most people tend to store passwords as MD5 hashes, at
>> least 10 times more than people who store them in cleartext. They
>> both are essential flaws but a person employing MD5 would think it is
>> secure by reading this.
>> The defense for Insecure Direct Object Reference is something you can
>> never expect developers to do, unless they realize why. The more
>> logical approach is to ask them to enforce access control on
>> everything, and then to indirectly reference sensitive data. The
>> trade-off is just not logical.
>> Again, A7 states three scenarios which are basically the same. It has
>> like 80% common ground with A4, and separating them is just caused by
>> long years of Top Ten existence, not reality. I need other peoples
>> opinion on this.
>> I think it is worth mentioning that defense against CSRF is not that
>> simple and requires some effort.
>> I suggest renaming A9 to "Using Vulnerable 3rd Party" or "Using
>> Vulnerable Tools", because we mean 3rd party tools not developed
>> components of the local company. 
>> Thats all, I'd really appreciate some feedback on this.
>> Thanks
>> -Abbas
> Thanks
> -Abbas
> On ۲۹ بهمن ۱۳۹۱, at ۱۶:۳۷, Steven van der Baan
> <steven.van.der.baan at owasp.org <mailto:steven.van.der.baan at owasp.org>>
> wrote:
>> Hi All,
>> first of all I want to say thank you to all for drafting this new top
>> ten. I can see that a lot of work went into it and I want to thank
>> everybody involved.
>> I only have one issue with the newly proposed top ten, and that is with
>> risk item A9. My company is regularly hired to perform a penetration
>> test based on PCI requirements. And that's where - I believe - this is
>> where we're going to make the mistake, cause it is a catch all/nothing
>> risk. From a pentest point of view, we don't usually see if outdated
>> components are used, we do see the result of those components. Those are
>> usually caught by other risks already in the top ten. Outdated framework
>> components are usually caught by code review, but that's not how I see
>> the top ten being used.
>> I believe that - though it is a valid point in security that outdated
>> components should not be used - this risk doesn't add value to the
>> top ten.
>> Just expressing my thoughts.
>> Kind regards,
>> Steven.
>> _______________________________________________
>> Owasp-topten mailing list
>> Owasp-topten at lists.owasp.org <mailto: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/20130217/d2642902/attachment.html>

More information about the Owasp-topten mailing list