[Owasp-topten] RFI taken out

Boberski, Michael [USA] boberski_michael at bah.com
Wed Nov 18 08:44:42 EST 2009


You might want to be intentionally vague on Cloud, so that the Top 10 won't immediately be dismissed by people researching Cloud security issues who are busy reinventing the wheel. Although, you could perhaps generalize as: Cloud = Top 10 + 3, the three being: massive object reuse, reference mediation, and virtual machine provisioning management problems.
 
Mike B.

-----Original Message-----
From: owasp-topten-bounces at lists.owasp.org [mailto:owasp-topten-bounces at lists.owasp.org] On Behalf Of Dave Wichers
Sent: Wednesday, November 18, 2009 8:34 AM
To: Raul Siles
Cc: owasp-topten at lists.owasp.org
Subject: Re: [Owasp-topten] RFI taken out

I think this is a good idea. Not only for things that might have dropped out, but new and up and coming issues like Clickjacking as well. We also need to address Cloud computing and its affect (or non-affect) on the future of web security (at least our prediction any way).

-Dave

-----Original Message-----
From: Raul Siles [mailto:raul.siles at gmail.com]
Sent: Wednesday, November 18, 2009 5:34 AM
To: Dave Wichers
Cc: Steven M. Christey; Ty Miller; owasp-topten at lists.owasp.org
Subject: Re: [Owasp-topten] RFI taken out

Hi,
As the topic of adding missing vulnerabilities, or grouping them together, is appearing (has appeared in the past and will appear) on multiple OWASP Top 10 mailing-list threads, what about including a brief final section or appendix in the document with a list of the non-included issues? This will help the interested reader into researching about those other things that didn't get into the Top 10 but are the next set of important things to consider.

Of course, that suggested list could be endless, so I recommend to take the next 10 issues (rough number) and list them there. The idea is not to create a Top 20, 25, etc, and not to describe them in detail, but to provide a quick pointer for the Top 10 readers that, after reading the document, ask themselves... "what else should I consider next?".

Cheers,
--
Raul Siles
www.raulsiles.com



On Wed, Nov 18, 2009 at 1:28 AM, Dave Wichers <dave.wichers at aspectsecurity.com> wrote:
> I'm OK with sneaking PHP RFI back in to the Top 10 as a configuration 
> item that is now covered under A6 - Security Misconfiguration.
>
> I don't know if that is a stretch but it at least is a place to hang 
> your hat. :-)
>
> -Dave
>
> -----Original Message-----
> From: Steven M. Christey [mailto:coley at linus.mitre.org]
> Sent: Tuesday, November 17, 2009 7:22 PM
> To: Ty Miller; Dave Wichers
> Cc: owasp-topten at lists.owasp.org
> Subject: Re: [Owasp-topten] RFI taken out
>
>
> On Tue, 17 Nov 2009, Dave Wichers wrote:
>
>> we are trying to get a sense of how big this problem is across all
> users
>> of the top 10. Based on the data we saw from MITRE, Aspect, White 
>> Hat, and Softek, the frequency of this issue had dropped 
>> significantly
> since
>> 2006/2007, and for non-PHP developers this is a relatively rare issue.
>
> Based on my interpretation of the CVE data, RFI has dropped 
> (relatively speaking), suggesting that the pool of 
> obviously-vulnerable applications is dropping, or there is a higher 
> cost-benefit ratio for launching a successful attack.  I'm seeing more 
> CVEs that target code snippets like this one from CVE-2009-3064:
>
>  require("./../".$_GET["filename"]);
>
> This is more LFI than RFI.
>
> Also - in modern PHPs, allow_url_fopen is disabled, which in 
> conjunction with restrictive register_globals settings, suggests that 
> much of the remaining RFI problem is related to configuration.  
> (Though admittedly, some modern PHP oddities are still equivalent to 
> RFI, and admins are often stuck using older PHP versions.)
>
> Note that RFI/LFI is occasionally reported in CVE for other languages 
> such as ColdFusion, Python, Ruby, and other interpreted languages.  
> But that's extremely rare.  (Could be that the researchers aren't 
> paying attention in this area, though.)
>
> Disclaimer: CVE data is necessarily affected by what vuln researchers 
> decide to publish, so it reflects their own biases.  And as Dave said, 
> CVE isn't the only data source for the Top Ten.
>
> - Steve
> _______________________________________________
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-topten
>
_______________________________________________
Owasp-topten mailing list
Owasp-topten at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-topten


More information about the Owasp-topten mailing list