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]
Message-ID: <0FD9D979B9535D4890AE309799B6D1E59DA440@lansingemail.seqnt.com>
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




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ