[Owasp-topten] OWASP Top 10 2009
owasp at nxtg.net
Tue May 19 02:12:14 EDT 2009
" There are still a lot of security professionals that don't understand
it's seriousness, and with a quick read may misinterpret its loss from
I find hard considering this as a strong argument to keep XSS separate.
The Top 10 lists the top 10 flaws found, whatever they are and I
strongly feel we should not consider grouping/degrouping items based on
the ability to so-called security professionals to understand it.
Moreover, based on this reasoning, that would also lead to reconsidering
the A4 section (Insecure Direct Object Reference), which basically will
never ever mean anything to most people, even web developers themselves,
until they closely look at examples. It is however, a flaw of utmost
importance and indeed, I see it very frequently in web applications.
Secondly, if the discussion raises such questions, it means some people
might lack an agreement on what the top 10 was (including me). As I
understand it, the top 10 listed the "top 10 security flaws found in web
applications", sorted by frequency, first position being the most
frequent. In such case, the question about whether an item should be
kept separate or not because of the confusion it might trigger wherever
it stands did not apply. The process was about reading statistics,
numbers, occurrences; not taking decisions on which ones should or
shouldn't be regrouped, yet. Otherwise, I think we might need to
recalibrate the definition and the mission of the list in order to make
it really tell what it pretends to.
Next. 2009's version. If we regroup flaws, it means they are basically
considered as results of the same "mistake". XSS flaws result from an
input that is injected as 'raw' content into a larger structure let's
from an input being injected as 'raw' content into a larger structure,
let's say, a SQL query. One can easily see the point: they result from
the same "human flaw", which is, considering input as a "parameter"
whereas it should be considered as "input that needs to be kept as a
Now, the question about whether we should separate them or not is
already answered by the mission of the Top 10 list itself. And this is
were it becomes tough version 2009's mission has changed (Wichers, mar.
18) and is "the top 10 biggest security risks to web applications." Risk
is no more only about probability (as in Top 10 2007/2004) but also
about impact. In that case, a flaw such as a SQL injection on a SQL
Server instance located inside a corporate DMZ means instant death
penalty. End of discussion. 1st. rank. Even if we find SQL injections a
thousand less times around on the web than XSS flaws, one SQLi has
precedence over all the others. Moreover, year 2008 massive web
infections clearly showed the security community that SQLi are far from
dead: the list not only needs to deal with "code builders" but also with
"code owners", those who maintain web applications all around the globe
with flaws that were implemented years ago but will be exploited during
What I just wrote can result in war. It's like religion: pretending that
SQLi is a thousand times riskier than XSS is a personal opinion and I
have no facts to prove what I am saying. Dave's round 1 (Wichers,mar.
18) gave us directions on where to go, it's a strategic goal. I think we
now need to think tactical. We left the "frequency" planet to join the
"risk" planet. Risk is more complicated. Risk means money. Risk means
investment. Risk means decisions. Risk means dealing with the riskier
first. Whatever is ranked 1st.,2nd., 3rd. and so on in a 'risk-based'
document needs to be justified. At someplace, some high-ranked guy will
have to respond why he decided to trust such a document. As for current
state, he will still be exposed to people asking questions like "Why is
this item ranked 1st. and not 3rd.?" or "Why did you fix this item
before that one???" "The Top 10 is complete BS, Item 3rd. is far more
important than item 1st.!"
In order to achieve this, we could first jump to round 2 officially
(most people seemed to agree with Dave's vision about the new Top 10
orientation) and answer 3 most basic decisions for the OWASP 2009:
- What are candidates for an entry? (which flaws? which groups of
flaws?) what is the official list of flaws that are considered? is it
the entire CWE? part of the CWE? Even entries of the CWE? ...?
- What are the metrics we use to qualify them?
- What is THE final metric we use to rank them? (how do we combine all
the metrics into one major metric)
With these questions answered, I think the top 10 2009 will contain
elements that fully deserve their place, their rank and their attention.
Morever, the list will have a strong elective background for becoming a
standard more than a reference. Whatever the rank of an item, when
someone asks "why is this item ranked X?", we will be able to answer
"Because it is ranked X, stfu and read the methodology!" If we can't
reach that level, we might consider sticking on the 'frequency' planet
at least for another year. Nobody gets hurt anyway.
as usual, my 2,1 cents :)
Ralph Durkee wrote:
> I would rather see XSS kept separate from injection attacks. Although
> there valid points about it being a subset of HTML injection there
> would be a couple of serious losses by merging it in. As we have been
> educating the community on these attacks to merge something as
> widespread as XSS off the Top 10, I think would cause confusion by
> it's absence. There are still a lot of security professionals that
> don't understand it's seriousness, and with a quick read may
> misinterpret its loss from the list. Also, even though it's broadly a
> type of an injection attack the fact that it be run by the browser
> rather than the server, changes the attack and the defense very
> significantly, so that it's helpful to talk about them separately.
> -- Ralph Durkee, CISSP, GSEC, GCIH, GSNA
> Rochester OWASP President
> Tyler Reguly wrote:
>> I don't see it as simply a way to create a slot.
>> While it's true that XSS and SQL Injection are the top two reported
>> conditions, I don't think that merging them in the OWASP Top 10 will
>> take away from that or decrease their importance. I think it just
>> improves the accuracy of the list items.
>> Again, this only applies, as I said, if you leave A2 as Injection
>> Flaws.... (which I'd say detracts just as from SQL Injection as
>> placing them both in the same bucket would). If A2 were specifically
>> SQL Injection, then XSS would make much more sense as it's own item.
>> Some logic behind this:
>> A2 States: "SQL, Hibernate Query Language (HQL), LDAP, XPath, XQuery,
>> XSLT, HTML, XML, OS command injection and many more."
>> So then why if I inject these two lines:
>> <iframe src="http://www.google.ca"></iframe>
>> Would we classify one of them as A1 and the other as A2?
>> If we look at entry for A1, we see the following: "Cross-site
>> scripting, better known as XSS, is in fact a subset of HTML
>> injection." To me this is just confusing to some developers coming in
>> and trying to tackle the OWASP Top 10. Why does one of the Top 10 fit
>> within another one?
>> To me this goes further to the point that the OWASP Top 10 isn't
>> necessarily targeted for universal use, it needs some clarification
>> before casual developers at SMBs, and even some developers at large
>> businesses can fully wrap their heads around it.
>> Maybe the bigger issue here is that the Top 10 varies between specific
>> attacks (CSRF, XSS) and buckets (Injection Flaws, Broken
>> Authentication and Session Management).
>> The SANS Top 20 used to identify the top 10 Windows services and top
>> 10 Unix services with flaws. It has since evolved to the point where I
>> believe it includes every vulnerability ever released in one of it's
>> 20 categories :). They went from 20 specific services to 20 classes of
>> vulnerabilities (Instead of IE being a bullet point, Browser-Based now
>> Perhaps it's time for the Top 10 to follow that same path? Become a
>> Top 20 (or two Top 10 lists). One list identifying the top 10 buckets,
>> the other identifying the top 10 vulnerabilities within those buckets.
>> 1) Injection Flaws
>> 2) Insecure Communications
>> 3) Broken Authentication and Session Management
>> 4) Insecure Direct Object Reference
>> 5 )Insecure System Configuration
>> XSS (maps to 1)
>> SQL Injection (maps to 1)
>> Path Traversal (maps to 4)
>> Use of SSL v2 (maps to 2)
>> Use of Default System Credentials (maps to 5)
>> I'm not trying to argue the importance of XSS or SQLi, I wouldn't do
>> that... knowledge of them is extremely important. I'm also not trying
>> to undermine the Top 10... I believe that it's a great resource. My
>> goal here is to improve it so that it's accessible to everyone and
>> make sure it's as clear as possible.
>> A breakdown between buckets and vulnerabilities may also be beneficial
>> to businesses with limited resources to target problems. Example:
>> Injection flaws covers a lot of ground and issues... but resolving XSS
>> and SQLi is a huge jump in the right direction and takes significantly
>> less resources than tackling all of the issues it covers. The same is
>> true if you compare Path Traversal to Insecure Direct Object Reference
>> as a whole. At this point both become valid reference points, but the
>> further breakdown allows for identification of the key points.
>> On Sat, May 16, 2009 at 5:37 PM, Dave Wichers
>> <dave.wichers at aspectsecurity.com> wrote:
>>> Regarding merging injection and XSS, I really don't think that is a good
>>> idea. SQL Injection and XSS flaws are always reported separately and
>>> they are #1 and #2 in reported quantity so burying one inside the same
>>> bucket with the other would remove the emphasis that is sorely needed to
>>> keep these two items at the top of peoples radar. So, I don't think
>>> that is the best way to create a slot.
>>> That said, I agree with your concern about Insecure Configuration
>>> Management disappearing from the Top 10. This specific topic was brought
>>> up in Portugal at the OWASP summit so is definitely something we need to
>>> directly address.
>>> The two proposed options were:
>>> 1) Add it back in to the Top 10 (and there is definitely merit to that),
>>> 2) Make it clear in each top 10 item that the system needs to be
>>> configured properly in that area for that area to be performed properly.
>>> Item #1 makes this important issue much more obvious, but there were
>>> mixed opinions on which of the two paths we should take.
>>> So that is definitely something we need to discuss and resolve.
>>> -----Original Message-----
>>> From: owasp-topten-bounces at lists.owasp.org
>>> [mailto:owasp-topten-bounces at lists.owasp.org] On Behalf Of Tyler Reguly
>>> Sent: Thursday, May 14, 2009 5:29 PM
>>> To: owasp-topten at lists.owasp.org
>>> Subject: [Owasp-topten] OWASP Top 10 2009
>>> Hey All,
>>> Somehow I missed the thread on the first round of discussion on OWASP
>>> Top 10 2009, but I wanted to bring something up that has always
>>> bothered me slightly about the 2007 list.
>>> The 2007 list seems to "waste" a slot, by having Injection Flaws as a
>>> large bucket but then splitting out XSS (which is simply another
>>> injection flaw). I'd like to see that not exist on the next iteration
>>> of the list and to that point, the 8 items presented by Jeremiah, in
>>> the original discussion on this list, resolve this by removing
>>> injection flaws and inserting SQLi, which means that XSS doesn't
>>> become repetitive. From a historic stand point... in order to get
>>> awareness, I think it fit at the time, but now I'm not sure that it's
>>> - Cross Site Scripting
>>> - SQL Injection
>>> - Insecure Direct Object Reference / Predictable Resources Location
>>> - Cross Site Request Forgery
>>> - Clickjacking / UI Redressing
>>> - Insufficient Authorization
>>> - Insecure Communications / Insufficient Transport Layer Protection
>>> - Open URL Redirectors
>>> Since the presented list only contains 8 items, I wanted to bring up
>>> another point that I think deserves discussion. The 2004 list
>>> contained A10 - Insecure Configuration Management and discussed items
>>> such as vulnerable server software. I think this is an important
>>> point... the removal of this item makes sense if the list is designed
>>> to target people in pure development roles. In my mind thought it
>>> removes a critical item that other groups who rely on the Top 10 make
>>> use of. Owning the system means owning the web app and if the goal is
>>> to map the "Top 10 biggest security risks to web applications" then I
>>> think this deserves a spot. Web App Auditors and Web App Security
>>> Scanners should both be considering this aspect because undoubtedly
>>> the attackers are going to be. Yet I think the biggest group affected
>>> by the lack of this item is IT people at SMBs.
>>> Having worked in the IT role at an SMB, I know that it's quite often a
>>> single person responsible for OS, Software and Web Application
>>> security and that is only one of their roles. If they are deploying a
>>> web app and using the Top 10 as a checklist, they are missing a
>>> critical part of the infrastructure of that application. For that
>>> reason I'd love to see Insecure Configuration Management (or a
>>> variation of it) that covers all the underlying infrastructure, not
>>> just the web server included in the list.
>>> Owasp-topten mailing list
>>> Owasp-topten at lists.owasp.org
>> Owasp-topten mailing list
>> Owasp-topten at lists.owasp.org
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
More information about the Owasp-topten