DOS Attacks via Ajax using the Javascript: protocol?

[Alberto]

Do you deem possible that a successful DoS (Denial of Service, 'course) attack gets performed by simply typing in the location bar of a browser something like:

javascript:while(1){ajaxInstance.get('myphp.php')}

namely exploiting the Javascript protocol - after all Ajax classes are js files, visible to all.

If that could eventually incapacitate the myphp file from serving other clients, how would you circumvent such a DoS attack without giving up Ajax too?

Thank you
Alberto

Ps the reason such an attack may be attempted, is that Ajax requests sent consecutively this way, may be considered legitimate by the receiving php script because they would carry the fingerprint of a valid session being issued from the location bar of a legitimately logged in browser.

[edited by: Alberto at 11:38 pm (utc) on Aug. 29, 2006]

[Rambo Tribble]

I would doubt that one browser client could successfully mount a DoS attack against any but the most limited of servers. The bandwidth and the number of open HTTP requests one client could support would make this approach seem unlikely to work. DoS attacks are usually the result of numerous zombie machines simultaneously executing requests

[Alberto]

Would you therefore suggest to ignore the possibility that a group of say 5 or 6 guys may attempt it? It's a trade off as we know.
I have here guys who try to enter my windows ini files without even noticing they are not dealing with php queries but with banal html files with a javascript query string...

Actually I implemented a way to avoid this potential Ajax issue - I count the milliseconds between two consecutive Ajax requests by the same user, and I log the guy out if they are inferiror to 1 millisecond.

Do you think it's just wasted computational time, and we can simply forget about it?

Thanks
Alberto

[Rambo Tribble]

Well, I hesitate to make any proclamations, but DoS attacks usually involve thousands of machines, not a half-dozen. Still, there is a delicious "just desserts" quality to your approach. I doubt you are wasting much processing just testing for a time interval and you are, after all, getting some of that back if you drop a malefactor.

It might be worthwhile to wait for someone with more server management experience than myself to weigh in on this topic before coming to any conclusions.

[Alberto]

Ok thank you for your thoughts.

In case it may be vaguely interesting for anyone, here is how I proceeded.

The basic idea is that, with say 200,000 surfers, my drop down menus are all Ajax driven. Therefore, a pseudo-DoS attack may result from legitimate actions: instance, users who scroll the menus with the arrow keys. Since an arrow key scrolls the menus ultrafast, every newly selected option triggers an Ajax request. If 10,000 usres do that, I may have an utterly unnecessary burden on my server.

So, I firstly intercept via Javascript the keydown events on menus (javascript seems a rational protection when we are dealing with Ajax, because Ajax too is javascript - so who has "javascript disabled" (nobody LOL) would have also Ajax disabled.

Then my scripts meant to handle Ajax requests save in a superglobal array (SESSION, but maybe there are better options) the name of the scriptname (the page): it's an associative array, so it can be directly referenced:
$_SESSION[pagename]=microtime();

Every Ajax requests queries such look up table before being executed, and caluclates again the microtime. Before reassigning to $_SESSION[pagename] the new microtime, it makes the difference between the new and the old microtime. If it is below one millisecond, I refuse the connection (exit). It maybe a radical choice, but if somebody is delivering Ajax calls at that pace, it means he/she has circumvented some way the keydown js event handler: enough reason to distrust the guy and log him out...

It is not still clear from my tests if this works also with "javascript:" protocols. That type of loops eventually crash the browser. However I presume this "anti pseduo DoS" measure is working in the background as it does with less frantic Ajax requests.

You are absoultely right that DoS attacks need to involve many zombie machines - particularly successful ones. Yet it seems a neglected issue the fact that a site with many users and strongly Ajax driven may be susceptible to a "pseudo DoS" issue.

Maybe (maybe) this is at least an approach to mitigate the potential problem.

Thank you again
Alberto

[Alberto]

About the tactic above, I have a naive question.

The reason I use the SESSIOn to track Ajax requests pace is that it would be a disaster if a conceptual error in the protection codes would end up considering _all_ the surfers as _one_ surfer: if the "pseudo DoS Ajax" attack protected file, being used by EVERYBODY, considers not the requests of THIS user to be checked for the microtime, but ALL the requests, I would end up logging out everybody!

So the question, preposterous I agree but I prefer being paranoically ultra certain, is: if I perform this check using the session, what I am doing is checking the microtime requests only for THIS user, not for ALL users - correct?

I am not risking to log out everybody just because the file serves everybody, am I?

Paranoia seems mandatory with security issues, because you are always to discover you forgot something.

[celebx]

Why wouldn't users be able to use C:\test.html with an ajax object to perform this task? (so your banning code if there are to many requests is useless and costs user loading time).

Secondly, they could also write an windows aplication to query your script wich would be a lot faster then javascript.

I am not an server expert so I don't know anything about DoS but I do know that there are better and more easyer ways to query a script a milion times besides javascript.

Best Regards,
Snt

[carguy84]

This isn't a scenario I'm at all concernced about, I use a load tester on any site I create before releasing it, and if I turn it up high enough, I can DOS my own site on a LAN(a lot harder to do over the web since my inet is only 20/2Mbps).

However, I can point the load tester to any URL and if the server is a shared or otherwise feeble device, it will make the website unreachable.

4-5 users running a load testing app against a server is more of what I'd be worried about.

Since an arrow key scrolls the menus ultrafast, every newly selected option triggers an Ajax request. If 10,000 usres do that, I may have an utterly unnecessary burden on my server.

Unnecessary indeed. You should look at downloading the whole menu to the client once, and then using javascript to iterate thru the scrolling.

Chip-