[OWASP-TESTING] Application DoS Section

Eoin Keary eoinkeary at hotmail.com
Wed Sep 7 10:00:55 EDT 2005

Good point Larry.
The fact of Dropping a table is after the establishment of SQL injection and 
hence further damage.
Best to stay away from this otherwise we shall be repeating ourselves ad 

>From: "Shields, Larry" <Larry.Shields at FMR.COM>
>To: "Javier Fernandez-Sanguino" <jfernandez at germinus.com>
>CC: <owasp-testing at lists.sourceforge.net>
>Subject: RE: [OWASP-TESTING] Application DoS Section
>Date: Tue, 6 Sep 2005 08:56:02 -0400
>I think the difference might be that the DoS in a Buffer Overflow comes
>before the "real" exploit of command execution.  I've covered it in the
>existing chapter I've written.  But in the case of something like
>"dropping all the tables from the database", that can only happen once
>you're successfully exploiting SQL Injection attacks at will.  For
>example, will the Authentication section have a part that notes you can
>use SQL injection to add a fake account to accounts table in the
>database?  Will an authorization section note that you can use SQL
>injection to add permissions to the permission table?  The list sorta
>goes on.  Once you have a working remote exploit such as command
>execution or SQL injection stuff, there are a huge number of possible
>vectors.  I don't know that I'm convinced that it's wise to try and put
>stuff into every other security chapter that addresses things that
>people using other exploits could do after they've owned the box.  After
>all, that's not really "testing" at that point, so much as causing
>further damage once in.  I guess if you *really* needed to prove that
>having root on a server or admin command access in the database is bad
>to someone, it might be useful, but...
>Still, I'll defer to what people want to do here.  But just about every
>section will need to address these vectors...
>-----Original Message-----
>From: Javier Fernandez-Sanguino [mailto:jfernandez at germinus.com]
>Sent: Monday, September 05, 2005 5:30 AM
>To: Shields, Larry
>Cc: owasp-testing at lists.sourceforge.net
>Subject: Re: [OWASP-TESTING] Application DoS Section
>Shields, Larry wrote:
> > However, by this same logic, one could put the Buffer Overflow DoS
> > into that same type of category.  So I'm willing to listen to opinions
> > from others on this... Do we want to include a catch-all of other
> > possible ways someone could make the application unavailable if they
> > used other attacks to compromise something in the application, like
> > those we discussed here?
>Yes, I think that's best. Notice that a buffer overflow might not
>inmediately lead to code execution but can lead to a DoS (consider an
>application running on an obscure processor or a known vulnerability
>with no exploit code: you can find a buffer overflow in an obscure
>application (by simpkly feeding long parameter values) but he might not
>be able to debug the application in place in order to determine how to
>setup the buffer overflow to execute code.
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>owasp-testing mailing list
>owasp-testing at lists.sourceforge.net

Browse smarter with tabs - get the all-new MSN Toolbar! 

More information about the Owasp-testing mailing list