[WEB SECURITY] 2009 Top 25 Programming Errors

[Chris Eng]

Hi Arian,

 

Like you, I've dealt with lots of customers while delivering various
security projects over the years.  I can't picture one of my current or
former customers being insulted or offended by the Top 25 list, nor do I
believe it would reinforce this stereotype of "amateur security
professionals" that you believe is so pervasive.  Is it really just that
opening "Discussion" paragraph for each Top 25 issue that's bothering
you?  I can sort of see where you're coming from in that it doesn't read
like a polished deliverable, but that doesn't make it offensive.  I
certainly don't intend to reproduce the content verbatim in my own
reporting, but then again, that's not usually what one does with these
types of lists.

 

For the sake of comparison, here's the CWE description of XSS, linked
from the Top-25 page:

 

The software does not sufficiently validate, filter, escape, and encode
user-controllable input before it is placed in output that is used as a
web page that is served to other users.

 

Cross-site scripting (XSS) vulnerabilities occur when:

 

1. Untrusted data enters a web application, typically from a web
request.

2. The web application dynamically generates a web page that contains
this untrusted data.

3. During page generation, the application does not prevent the data
from containing content that is executable by a web browser, such as
JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX,
etc.

4. A victim visits the generated web page through a web browser, which
contains malicious script that was injected using the untrusted data.

5. Since the script comes from a web page that was sent by the web
server, the web browser executes the malicious script in the context of
the web server's domain.

6. This effectively violates the intention of the web browser's
same-origin policy, which states that scripts in one domain should not
be able to access resources or run code in a different domain.

 

Here is the WASC TC description of XSS:

 

Cross-site Scripting (XSS) is an attack technique that forces a web

site to echo attacker-supplied executable code, which loads in a

user's browser. The code itself is usually written in HTML/JavaScript,

but may also extend to VBScript, ActiveX, Java, Flash, or any other

browser-supported technology.

 

When an attacker gets a user's browser to execute his code, the

code will run within the security context (or zone) of the hosting web

site. With this level of privilege, the code has the ability to read,

modify and transmit any sensitive data accessible by the browser. A

Cross-site Scripted user could have his account hijacked (cookie

theft), their browser redirected to another location, or possibly shown

fraudulent content delivered by the web site they are visiting.
Crosssite

Scripting attacks essentially compromise the trust relationship

between a user and the web site.

 

Both go on to discuss reflected vs. stored, example code, etc. but I've
omitted those for brevity.  I think both descriptions fairly describe
the flaw, with a slight edge to CWE for the step-by-step commentary.
Both would benefit from some rewording (e.g. "A Cross-site Scripted
user"?)

 

-chris

 

 

 

 

> -----Original Message-----

> From: arian.evans at gmail.com [mailto:arian.evans at gmail.com] On Behalf
Of

> Arian J. Evans

> Sent: Wednesday, January 14, 2009 5:19 PM

> To: Chris Eng; websecurity at webappsec.org

> Subject: Re: [WEB SECURITY] 2009 Top 25 Programming Errors

> 

> Chris -- good point. I too have found that

> insulting and confusing people is effective

> in getting their attention.

> 

> Professionally I have found this approach

> to be less productive than others.

> 

> The content I quoted is the primary

> "Discussion" and the first content the

> reader encounters under each "issue".

> 

> If our goal is to persuade developers

> and business owners, we can be far

> more effective than this.

> 

> If you like the doc and the negative

> wording, cool, use it all you want.

> 

> For those of you that do not like this

> approach -- this was meant as a head's

> up that this is how SANS is going to have

> you doing business going forward.

> 

> 

> --

> --

> Arian Evans

> 

> 

> Anti-Gun/UN people: you should weep for

> Mumbai. Your actions leave defenseless dead.

> 

> "Among the many misdeeds of the British

> rule in India, history will look upon the Act

> depriving a whole nation of arms, as the

> blackest." -- Mahatma Gandhi

> 

> 

> 

> On Wed, Jan 14, 2009 at 12:51 PM, Chris Eng <ceng at veracode.com> wrote:

> > Arian,

> >

> > You realize that the XSS description you quoted -- the one written
in

> > 2nd person with a casual tone -- is not the primary content?  If you

> > click on the CWE-79 link
(http://cwe.mitre.org/data/definitions/79.html)

> > you get the technical, professional version that you probably
expected

> > to see, complete with examples, etc.  I think the paragraph you
quoted

> > is intended more to catch the developer's attention and get them to
read

> > further.  The individual CWE pages are generally pretty well
written,

> > and I don't think anyone expected that the one paragraph would be

> > sufficient to cover XSS.

> >

> > -chris

> >

> >

> >

> >> -----Original Message-----

> >> From: arian.evans at gmail.com [mailto:arian.evans at gmail.com] On
Behalf

> > Of

> >> Arian J. Evans

> >> Sent: Wednesday, January 14, 2009 3:36 PM

> >> To: Andy Steingruebl

> >> Cc: websecurity at webappsec.org

> >> Subject: Re: [WEB SECURITY] 2009 Top 25 Programming Errors

> >>

> >> Andy,

> >>

> >> I am not in any way attacking or denigrating CWE

> >> or Mitre. CWE is a fine effort by the first rate minds

> >> over at Mitre.

> >>

> >> My comments are about this "Top 25" list.

> >>

> >> These are "standards" because they are being used as

> >> a "standards" banner for products, contracts, RFPs, etc.

> >> already and will continue to be like other Top SANS lists.

> >>

> >> As I've said to several folks: It is an amateur piece of

> >> work that will simply reinforce the amateur nature of most

> >> security professionals to business owners and seasoned

> >> software developers. Apology to anyone whose kid I'm

> >> calling ugly here, but your kid is ugly.

> >>

> >> The WASC TC is a better guideline of issues with web

> >> software and in most ares more effective for communication.

> >>

> >> I know there are those that dislike these "Top N" lists

> >> but the spirit of this Top 25 is fine in my book.

> >>

> >> I would like to see a more professional list published and

> >> maintained by OWASP or WASC.

> >>

> >> My main criticism of this Top 25 list is with the content

> >> and the descriptions. Fixable? Sure.

> >>

> >> The fact that this was released is such an unprofessional

> >> state solidifies in my mind that Mitre and SANS are not

> >> the folks to be maintaining this list.

> >>

> >> I do not want to deal with this document and the inevitable

> >> reality that will stem from it. I do not want to respond to

> >> RFPs that ask if you test for "Failure to Protect Web Pages"

> >> and I do not want to have to build reports that report on

> >> this list with this garbage content and I do not want to

> >> have to explain why the remediation language, costs, and

> >> confusing suggestions are inaccurate or misguided.

> >>

> >> Take the "Remediation Cost:" bucket. I used to use these

> >> in my reports all the time, and agree with the spirit of intent

> >> on including this in a "Top 25".

> >>

> >> However -- the implementation in the Top 25 is misguided

> >> and useless as a result and should be removed.

> >>

> >> Half of the list is marked "Low" and there are even items

> >> marked "Low to High". (? why bother)

> >>

> >> There is no explanation or justification for any of it other than

> >> letting people know "this stuff is easy to fix".

> >>

> >> The reality of the cost of remediation is contextual to software

> >> and a business capacity and situation. Any effort to communicate

> >> cost should clearly communicate these realities and give the

> >> reader some notion of context, what they need to consider

> >> when evaluating cost, or simply be removed. Statistically

> >> speaking, the more likely you are to have massive XSS issues

> >> the more likely you are to have a hard time fixing it (because

> >> you've got a mess of ASP classic spaghetti code that got

> >> you where you are today). But I digress.

> >>

> >> I could go on criticizing but I won't. I will recommend that

> >> WASC or OWASP make a new Top 10 or Top 25 list and

> >> that we tackle the same spirit of intent, understanding that

> >> it will instantly become a "standard".

> >>

> >> Barring that we are going to live with this document for

> >> a while, and I am voicing my discontent.

> >>

> >> Steven @ Mitre is a smart guy and I bet this will improve

> >> over time if he starts filtering whom he listens too and

> >> who is allowed to contribute content. Or provides a guideline

> >> for content copy. Given who will use this and how it will

> >> be used this should be a very professional business document,

> >> not security-nerd speak with Star Treck naming conventions.

> >>

> >> Folks who name their variables or servers R2D2 and C3PO

> >> are probably not gonna agree with me here.

> >>

> >> If I had seen this mess up for review before it was

> >> published I would have commented or contributed

> >> much earlier.

> >>

> >>

> >> ...

> >>

> >> Feel free to note that I am too unmotivated to start my

> >> own project to make a new Top N list.

> >>

> >>

> >> --

> >> --

> >> Arian Evans

> >>

> >> Anti-Gun/UN people: you should weep for

> >> Mumbai. Your actions leave defenseless dead.

> >>

> >> "Among the many misdeeds of the British

> >> rule in India, history will look upon the Act

> >> depriving a whole nation of arms, as the

> >> blackest." -- Mahatma Gandhi

> >>

> >>

> >>

> >>

> >>

> >> On Wed, Jan 14, 2009 at 11:17 AM, Andy Steingruebl

> > <steingra at gmail.com>

> >> wrote:

> >> > On Wed, Jan 14, 2009 at 10:20 AM, Arian J. Evans

> >> > <arian.evans at anachronic.com> wrote:

> >> >>

> >> >> For all of you ignoring this -- this is going to replace the
OWASP

> > Top

> >> >> 10 and WASC TC 1.0 or 2.0 etc. That is the goal/agenda of SANS &

> > CWE.

> >> >> Begin press releases, beat the marketing campaign drums.

> >> >

> >> > How are any of these "Standards" anyway?  I'm not sure I
understand

> >> > what you're getting at here.  Are you saying there ought to be
some

> >> > standard that tells people what they have to check for and that

> > ought

> >> > to be the TC2.0?  If so, I think that is misguided as well.

> >> >

> >> > In either case though people are looking for requirements to
stick

> >> > into software purchase contracts to describe minimum security
levels

> >> > for something.  None of these lists is particularly well suited
to

> >> > that task, but at the same time the CC (Common Criteria) wasn't

> >> > exactly fitting that need either.  Maybe you'd like to write a

> >> > protection profile that your COTS software must meet?  Not me.

> >> >

> >> > So, while the language of the list of items might not be perfect,
I

> > do

> >> > have a lot of respect for the CWE itself, as it does a pretty
good

> > job

> >> > as a taxonomy.

> >> >

> >> > What are you looking to have produced to counter this?  How does
the

> >> > TC fit into that at all?

> >> >

> >> > --

> >> > Andy Steingruebl

> >> > steingra at gmail.com

> >> >

> >>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090114/d2b7ba2f/attachment.html>