True enough, but that being said, there's not a fundamental difference between having an ajax script call a php page that checks to see if a username has been taken, and having a a web form perform the same validation. So don't assume that Ajax is the problem here, just realize that it doesn't provide any additional security either. If you let an unauthenticated user know that a username has been taken, then you're basically giving away the list of usernames on your site. Any mechanism can be brute forced with time. Some common practices that are used to discourage bots from testing all user accounts are as follows: 1. Put in a time delay based on a session variable. After the 2nd or 3rd try, make it start taking longer. Consider doubling the processing delay for every iteration. It's important here to use a long delay if the session cookie (or variable is not set), since passing session cookies is a voluntary thing for browsers. Bots can work around this by destroying and recreating session cookies for every hit, but it does discourage some of the more common ones, and makes you not the "Lowest hanging fruit". 2. Use a captcha, or math problem or some variant as part of the username selection process. This makes a user do some visual recognition or smarts to try and ensure its not a bot. 3. Use something like apache mod_security to control who can access these pages on a site. Mod security can also be used to invoke limits on how many times a page gets hit from the same source IP etc, and try and detect bots from hitting specific pages. This is probably the most complicated, but also the most secure of the strategies. There may be other strategies, but these are the most common ones I've seen used. Typical bot protection approaches limit the number On May 7, 2007, at 4:57 PM, Gerhard Killesreiter wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Ashraf Amayreh schrieb:

...

Hello all,

One of my friends has a sign-up page that contains an AJAX call to the server that check the username availability without submitting the page. This is not much unlike many sign-up services now-a-days. He was wondering how he could prevent someone from abusing this by writing his own page which could gather information from repeatedly calling the web server via AJAX calls?

I've read many threads on AJAX security, but none that I have read handle such a trivial scenario. The above case is very simple but I'd like to see what people have in mind to protect against abusing such a call to gain sensitive site data.

If the usernames on your system are sensitive data, then you can't have an ajax callback on the signup page. It's as simple as that.

Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGP7zsfg6TFvELooQRAlIqAKCdCCWciRpfK0iCy+EIM59GJyGKNACgigN6 vsfhXjF7EZYl+mfsgk5sRUI= =0Kor -----END PGP SIGNATURE-----

Thanks all. The information is not that sensitive, but in the least, such a measure is important to prevent a DoS attack as Khalid mentioned. Yet even if user data is not that sensitive, it's still inappropriate to allow someone to just run off knowing most of the registered users on a site. This could be a first phase for performing a more elaborate and targeted attack on a site. David, how could using a captcha help here? By storing the result in a session variable and expecting it back with the AJAX call? How can we change the captcha on the next call without refreshing the page? I haven't really used captcha's before, so apologies if these questions are invalid in this context. What is evident here is that any full client side solution is bound to fail as it is easily manipulated by the client. Thanks. On 5/8/07, Khalid Baheyeldin <kb@2bits.com> wrote:

On 5/7/07, David Metzler <metzlerd@metzlerd.com> wrote:

...

True enough, but that being said, there's not a fundamental difference between having an ajax script call a php page that checks to see if a username has been taken, and having a a web form perform the same validation. So don't assume that Ajax is the problem here, just realize that it doesn't provide any additional security either.

The difference is that in AJAX (as most commonly used), if you type "aa", then all the users with names beginning with Aa will show up for you, then

you do "Ab", and get a list, then "Ac", ...etc.

This does not happen in a normal not AJAXified form. All you can get is whether the full name you chose exists or not.

Ashraf,

If this data is sensitive, then just don't reveal it. Also, check that there is sufficient delay before retrieving results, so as not to get DoS attacks by asking for the data too quickly, overloading the database.

The difference is that in AJAX (as most commonly used), if you type "aa", then all the users with names beginning with Aa will show up for you, then you do "Ab", and get a list, then "Ac", ...etc.

This is not the case here. While Drupal's regular nickname completion behaves like that, the check for usernames doesn't show a list of taken names but rather checks if a certain distinct name is already taken. Konstantin Käfer – http://kkaefer.com/