Hi Chris,
On 22 Jul 2005, at 03:15, Christopher J Varenhorst wrote:
<snip>
As far as automated attacks go, HTTP is too slow for bruteforce
password attacks
to be effective.
The objective of many brute force password attacks is not to gain
access to one specific user's account, but rather to gain access to
_any_ user's account. Instead of targeting the few users who have
strong passwords, attackers could target the users with weak
passwords by trying, for example, 20 commonly used passwords against
the known usernames.
The speed of an HTTP brute force attack is limited only by the server
response time and the available bandwidth. IMO even a regular DSL
line provides sufficient bandwidth to launch a brute force attack.
Automated form posting will fill server databases with
garbage, but I think its unlikely to bring the server to a
standstill. (maybe
I'm wrong?)
I'd agree that in most web apps, having thousands of bogus user
accounts won't be too much of a strain on the database, but what
about attacks that are launched using those accounts? Let's assume
an attacker has managed to create a number of fake accounts on a web
app and can therefore perform transactions with those accounts. He
could:
- Submit fake transactions that consume backend resources, such as
complex searches.
- Submit fake transactions that target manual processes behind the
service. For example, a transaction that ends up in the hands of a
human operator who needs to evaluate has a high processing cost. If
this transaction (and thousands like it) are fake, then the service
could effectively be DoS'd.
- Submit fake transaction that incur a financial cost to the site
owner. E.g. each check by a third party on a credit card number
incurs a small processing fee - whether that credit card number is
valid or not. Thousands of fake requests could result in a large
processing fee and perhaps an effective DoS.
A straight out DOS attack would be more effective at that.
And I think that's the reason we haven't seen many of these attacks
in the wild. It's simply much easier to use a DDoS system to bring
an app to it's knees, than it is to create a sophisticated
application DoS attack. But app level DoS attacks have the advantage
that they don't require as much bandwidth, so don't need all those
zombies - proxies work just fine.
Some
http servers will even automatically block automated attacks like
this.
Only if they're coming from the same IP, and (as I mentioned in
another reply) there are plenty of open proxies out there.
Regards,
Stephen
Quoting Chad Maniccia <wopazar@gmail.com>:
Hi List,
One thing I have not heard any one discuss is the use of automated
scripts and form hacking. I could easily write a Java program to
attack any ASP,JSP,PHP etc.. simply by viewing the page source to
find
the parameters the form processor will be looking for. You could use
this to fill up some ones database with garbage bring the server to a
standstill or worse yet bypass all the fancy javascript you had on
the
calling page. Some web applications actually use javascript to
calcualte currency transactions.
What ideas do you guys have to protect yourself from these?
Thanks,
Chad
