0

When a customer signs up for a site, we want to let them know whether a username/email is available for use. We have a httphandler that serves the purpose of feeding a jquery script that showsthe customer whether or not their desired username/email is available.

The question is: The service can clearly be seen being called when you view the request in fiddler. It shows /emlhandler.asmx?name=xxxxxxxxxxx@yyy.com

From the handler, a simple 0 or 1 is returned to indicate whether or not the name/address is available.

My concern is that this seems like a major security issue that would be very easy for an inexperienced person to exploit to discover all the users on the site.

So friends, how do you protect your site info and still allow the ajax callback to provide a great user experience?

Thanks. Heath

Haldrich98
  • 379
  • 3
  • 13

2 Answers2

0

You are being slightly paranoid here. Every site that allows user registration has to do something similar. One thing you can reasonably do is add a slight delay (maybe 2 or 3 seconds) to the handler's processing in order to reduce the likelihood or ease of a brute-force attack. Frankly, I don't think anyone would bother.

Another option is just to ignore repeated emails and send a verification email before a user's registration actually becomes active. If a new user attempts to use an existing email, the original email owner receives the verification and can cancel or ignore it. But I don't recommend this.

I'd say the vast majority of the sites I've used will just immediately say "this email address is already registered... did you forget your password?" Just knowing an email address is already in use on a given site does not in itself represent a security breach.

Bryan
  • 8,748
  • 7
  • 41
  • 62
0

One possible solution would be to only enable POST requests for that method.

And since you cannot invoke services from JavaScript from another domain (XSS - Cross-site Scripting) without your authorization, then you would be protected.

However this technique would prevent malicious users from calling your web service to discover user names but this wouldn't prevent the user to automate a process to simulate user entering data in a text box to force a call to the service, in that case, perhaps you could allow just a number of requests per user in an X amount of time.

You could keep track of the number of attempts using the Session object from your web service

Another approac would be to add a re Captcha to your site, however this would decrease the level of responsiveness if you used to allow your users to capture a user name and as soon as they write you call your service. Implementing would require your users to write the auto-generated captcha in order to submit your data

Jupaol
  • 21,107
  • 8
  • 68
  • 100