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-----