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

Abbas Naderi abbas.naderi at owasp.org
Sun Feb 17 14:25:27 UTC 2013


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:
> 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> 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
> 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/01b31b2d/attachment-0001.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/20130217/01b31b2d/attachment-0001.bin>


More information about the Owasp-topten mailing list