RE: XSS, SQL injection etc - permutations of input strings

["Conacher, Chris" <Chris.Conacher () negt com>]

Mike

I worked on a project with a very large software company training their internal (not product) developers and 
application testers on application security testing and development.

That company overcame the problem of what needed to be demonstrated before it would be fixed by educating senior 
decision makers as to the potential implications of xss, sql injection, buffer overflows, etc.

These people in turn decided that it was not acceptable for applications to be deployed in the environment that had any 
potential for certain vulnerabilities. Other vulnerabilities were assessed on the basis of available time, resource 
implications, etc for fixing and were rated as to priority or the level of exploitation that needed to be demonstrated. 
Note that buffer overflows did not need to be shown to be exploitable as it was considered that no developer working 
there should be allowing buffer overflows in any situation.

This was then published as a company policy with great effect.

For example, all a tester had to show was that it was possible to bypass an input validation designed to prevent sql 
injection by entering a tick a returning an error and the application was kicked back to the developers for them to fix.

This removed any ability of the developers to argue as to the 'real impact' of a particular vulnerability and saved so 
much time in the to-ing and fro-ing between testers and developers.

The business basically understood that just because a tester is not able to demonstrate serious potential for a 
vulnerability does not mean that there are not people out there with more ability and time who could and made a 
decision. 

It removed the ability of the developers and testers to affect the decision making process and became a business 
decision as what was acceptable to that business.

Chris

Chris Conacher
Security Analyst

Ext:    34508 
Tel:    +1.503.833.4508 
Email:  chris.conacher () negt com

-----Original Message-----
From: Mike Andrews [mailto:mike () se fit edu]
Sent: Monday, September 20, 2004 9:41 PM
To: webappsec () securityfocus com
Subject: RE: XSS, SQL injection etc - permutations of input strings



*******
Please don't read on any further if you were planning to post a reply to the
original message.
*******

So, firstly thanks to the people that have (or still are) replying to the
original message.  Please keep them coming.  I appreciate the insights from
the people "on the front lines".

I must say that I had a bit of an ulterior motive for posting the question
in the first place and I'm getting the kind of (great) replies I expected.

It seems that most companies want/need an exploit to prompt a fix.  I think
that's just plain wrong, although I can see some of the cost/benefit
arguments.  If there's a few vulnerabilities to fix then of course they need
to be triaged, but I think that there's better ways than spending time in
creating an exploit (DREAD, etc?).  For example, in my experience, crafting
certain buffer overflows can be quite time consuming and at the very least
there's a DOS attack in there somewhere.  The time spent crafting the
exploit may be better spent (e.g. doing further testing).  In the current
security conscious climate, I would have hoped that any vulnerability would
be closed without debate, but I've certainly experienced times when
vulnerabilities weren't fixed without an exploit (even returned "no repro")
and sometimes even when a really good exploit was provided it wasn't fixed
for some time.

Also, I don't particularly like the idea of *having* to produce an exploit
to get a fix.  If we go back to the old IEEE definition of a defect (bug)
then somewhere there's a flaw in the program that may (or may not) produce a
failure (or failures).  I have no evidence here, part of the ulterior motive
of looking to see why developers create bugs in the first place and how they
were fixed, but by providing an exploit developers may fixate on the failure
rather than the flaw, leaving the flaw in the program for future
exploitation that we may not currently know.

I do agree however that following an exploit though can be a great way to
uncover further vulnerabilities.  The example that I have is an SQL
injection - you may be able to select from the original table, but are there
additional permissions on the DB so you can't get to information you
shouldn't have (i.e. defense in depth).

Once again thanks.

Cheers,
Mike.

----
Mike Andrews
Florida Institute of Technology.


> On Sat, 18 Sep 2004 19:15:54 -0400, Mike Andrews <mike () se fit edu> wrote:
> > Over the past few days I've seen many posts about different ways of
> encoding
> > XSS/SQL injection strings, as well as leveraging a discovered
> vulnerability
> > in order to get more information about the target (other DB
> fields/schema).
> > The question I'd like to ask the list is once you know a particular
> input
> > vector is vulnerable, why are people trying to push the exploit further,
> > assuming that they are pen-testing rather than hacking the target?  For
> the
> > uninformed client, being able to show them that you 0wn3 their
> server/app
> > once should be enough to treat *any* discovered flaw as serious enough
> to
> > fix, even if it's only a JS alert box, a "or 1=1", or a "select from
> another
> > table" attack.
> >
> > My assumption here is a tester should use a variety of inputs to see how
> an
> > application responds, but when it's clear that there's a defect
> somewhere
> > you report the flaw back to the developers, telling them what/when/how,
> etc,
> > then work with them to ensure they only accept *valid* input and not
> just
> > filter for all of the ways you've attacked the flaw.  There's obviously
> > alternative inputs (i.e. debugging to help understand the defect),
> > re-testing issues, and ensuring the fix actually did what it was
> supposed
> > to, but my belief is that once developers know they have a problem (for
> > whatever reason) they are in much better position to put in a generic
> fix.
> > Any thoughts on this.  What is the point of extending an attack to (for
> > example) discover the entire DB schema unless it is just showing off?
> >
> > Cheers,
> > Mike
> >
> > ----
> > Mike Andrews
> > Florida Institute of Technology
>
>
>
> --
> ___________________________________
> Harrison Gladden <hgladden () gmail com>
> Computer Engineer & Science Major
> ~Past experience: He who never makes
>    mistakes, never did anything that's worth.~