[OWASP-TESTING] Application DoS Section

Shields, Larry Larry.Shields at FMR.COM
Tue Sep 6 08:56:02 EDT 2005

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.



More information about the Owasp-testing mailing list