full-disclosure - Web Application DoS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: mlachniet at sequoianet.com (Lachniet, Mark)
Subject: Web Application DoS

> +-----------------------------------+
> | Web Application Denial of Service |
> +-----------------------------------+
> There is a denial of service condition not in a specific software 
> product but in several web based applications.
> The idea is to make a rather small HTTP request and get a big amount 
> of data back from the HTTP daemon.

Ummm... Duh...  

BUT, it does raise an interesting problem from a design and testing
point of view.  I do a lot of web application tests, many of them with
automated tools like SPI.  In most cases, it is very easy to crash web
apps that rely on a database back end.  In fact, it's a big problem when
it comes to testing production servers.  Most small to medium web sites
just don't seem to take 15+ query threads at a time very well,
especially when you are doing complicated queries (10+ variables, etc.)

It is trivially easy to find (for example) a URL request that takes a
long time for the query to return (say, 10 seconds or more) and then
hammer it with a zillion requests using a simple script.  Not only can
the database server platform get choked up with requests that it cannot
service, but in some cases you can use up all of your licenses too.  You
might also use such a technique to mess up some logging systems if you
are lucky (ie, if it logs audit data to a database).  This problem is
made worse by the fact that many folks don't use stand-alone database
servers for just their web applications, and instead get one "big"
database, and use it for a variety of purposes.  In this case, you could
likely crash more than just the one web app.

If it were an IP network issue, I'd say to do some QoS, but is there a
good design equivalent of this commonly in use for n-tiered web
applications?  (for example, building into the web application some
logic that maintains a state table of requests, and ensures that single
source IP doesn't get more than 1 database lookup thread, or something
similar).  If there is some good example code for something like this,
I'd love to share it with my customers.  This subject might also be a
good addition to the OWASP guide, which (while and excellent piece of
work) doesn't seem to cover much in the way of Denial of Service
prevention as far as I know.

Thanks,
Mark Lachniet