2

I have an ecommerce website with over 5 million customer database. From past couple of days, probably a hacker is hitting an AJAX endpoint continuously. This endpoint takes email address as a parameter and returns whether that email address is registered on our website or not, and we accordingly prompt user to login or signup. My bet is that this hacker is trying to exploit User Enumeration vulnerability.

I have employed various measures to stop this hacker, but he seems to be very smart. I am getting hits from all over the world and hundreds of differents IPs in each country. Which is making it extremely difficult to block him.

To stop him, I have done following:

  1. Applied rate limit using AWS WAF - not more than 100 requests per 5 minute from single IP on this endpoint.
  2. Blocked over 1500 IP address manually going through Access logs
  3. Blocked complete traffic from over 50 countries which doesn't contribute much in revenue.

Although above steps has curtailed the speed of attack a lot. But that guy is still running this attack and it's not possible to keep on blocking IP addresses or countries because he keeps on bringing new IP address.

What can be a good way by which I can stop him without hampering our genuine user's experience? I don't want to introduce captcha, is there any other way?

Abhinav
  • 139
  • 4

3 Answers3

1

The cause of your problem:
Your system has a major design flaw where it's giving away information that it shouldn't offer openly. You've created a leak and someone is using it against you.

Now you could go great lengths to get get rid of the hacker, but in the end you're simply fighting windmills trying to block someone who's using a botnet. And even if you actually succeeded in the end - which is extremely unlikely in the first place - all you're doing is treating the symptom instead of the actual problem.

How to solve this:
Legitimate users know whether they're signed up already or need an account first. So fix your login form, nuke that endpoint and you're good.

Paul
  • 783
  • 5
  • 12
  • I agree this is a sort of easy exploit, but offering user to either login or signup after taking his email is a kind of industry standard this days. Right from Amazon, flipkart etc. all major websites are offering this to easy login process. Is there any fix that you can suggest with existing architecture? – Abhinav Nov 22 '20 at 04:55
  • 2
    @Abhi nope. With the existing architecture you're working along the lines of "I like to keep my frontdoor unlocked, but some guy keeps breaking in. So now I'll build a higher fence". You might slow the attacks down, but in the end you won't achieve much more on that vector, simply because it's one of the reasons why botnets came up in the first place. – Paul Nov 22 '20 at 13:49
1

Really, many web sites offer users to login or to signup. But it does not mean that they implement it in the same way as you have done.

With your existing design you cannot prevent the attacker from sending multiple enumeration requests. The usage of different tools can only reduce the slow down the process, but you cannot prevent it completely.

Login:

When login fails, the error message should not disclose if the email is registered in your database or not. It should be generic like "Email or password is not correct."

Signup:

  1. You can offer to only enter an Email, then send a link to this Email so that user can complete registration process. Also you display a generic message no matter if user is new or is already registered. Thus the attacker will not know if the email is registered or not.
  2. You can offer user to fill all the data you need for registration: Email, password, etc. At the end you send a link to this Email to validate it. Again, you display only generic message. If the Email exists, you send an Email about an attempt to register it again. If the Email doesn't exist, you just throw away all the entered data. Again, the attacker will not know if the Email is registered or not.
mentallurg
  • 8,536
  • 4
  • 26
  • 41
0

This endpoint takes email address as a parameter and returns whether that email address is registered on our website or not, and we accordingly prompt user to login or signup.

Such Ajax endpoint should not be exposed publicly in the first place. There should be no need to have these information at the front-end of your web application since you should not blindly trust the front-end anyway. If this is only checked in the front-end then it might be possible for a malicious user to create duplicate users, so it must be checked in the back-end anyway.

It is thus better to design your application so that unlimited access to these information is only needed at the back-end and that the access to the API endpoint is restricted accordingly. This makes it possible to include a more complex logic on the server side, to decide when the result of such lookup will be exposed to the front-end. A common way to limit exposure is to use third party reputation sources which can include the use of captchas in cases where the reputation of the user is low (i.e. potential bot or similar).

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424