More concerns about Ajax programming as a security risk

I previously inquired about whether Ajax programming would pose an increased risk for web apps to become compromised or rendered inoperable due to DOS attacks.  I found a link from about Ajax, and the author (James, assumedly) noted that one of the downsides of his web-based login sample using Ajax was that it increases the opportunity for a brute-force attack.

Also, Alex Russell notes Ajax's apparent flaw of a malicious user being able to "hammer Web 1.0 architectures".

There's also been considerable debate about security concerns about Ajax, after various Earle Castledine blog posts about using the JavaScript XmlHttpRequest object to spy on a user. 


  • I usually try not to be snarky about technology, but I WOULD have to point out that using AJAX for a login page is just asking to get crushed. It's a good technology for what it does, but this is just an example of someone taking a decent idea way too far. It happens with every other technology, especially XML.

  • Whatever. You'd have the same DoS issues no matter what.

    The dorks writing these articles don't really realize that EVERYTHING on the web that requires server interaction *must* send a request. What's so different about using "AJAX"?

  • Maybe I'm missing something, but how is this more prone to brute force attacks than a "regular" form submit?

    From what I understand, all the script in the page is doing is call a script on the server via a URL and passing it data, where it would do essentiall the same work as a form submit with the data would be doing. An attacker is attacking a URL not a form. So, if that's not the area of concern, where is the added risk actually occuring?

  • Hi Jason, I do not understand where the difference is between a "normal" web site request and the AJAX requests. Both of them are using POST or GET to send/get data to/from the server using HTTP/HTTPS. So, they are not different, or I am missing something?



  • I have an example online where I use a similar way to do authentication. I think it is more secure than a FORMS authentication if you use AJAX. Say, we submit username and password using AJAX, returning an authentication ticket and store it in the page as a JavaScript variable. It will not be displayed in the HTML code (caching) and will not be a cookie that may be a problem (not sure). I can create my own ticket, including IP address, browser agent, ...

  • uber:"AJAX for a login page is just asking to get crushed."


    Like many others, I'm not sure where all this is coming from.

    You're using the client side XMLHttpRequest to either perform a HTTP GET or HTTP POST to some URI endpoint. It's absolutely EXACTLY the same as when submitting a 'normal' HTML form to the server.

    You're hitting the server. Period.

    Yes, you could create your own javascript and have a nice loop (for i=0;i<1000000;i++) which performs a GET or POST to this resource but in essence this is no different from analyzing an ordinary HTML form (use its form variable names) and trying a brute force attack by using .NET's WebRequest class and hitting the server like that.

    Bottom line: AJAX or no AJAX, we should be coding defensively, regardless. It hasn't all of a sudden become an issue since people started blurting out the word "AJAX"...

  • so that's agreed then - Mr. 'uber' is full of it

  • 423728.. He-he-he :)

Comments have been disabled for this content.