Assuming there is a mobile app that sends the mobile phone number to the backend, and the backend sends an SMS with a code to allow connection if the phone number exists. This works as intended.
But a user recently created many accounts and then made a script (?) that calls the backend route (10 times with 10 different accounts) then switches IP, calls the backend again with this new ip, etc. Every time they call the route, it generates a new SMS.
The only result is that many SMS are sent and it adds cost to the company.
Is there a way to prevent this?
Currently, a single user can not call more than 3 times the API without a successful login, but with many accounts rotation, it still generates a lot of SMS. And I guess the script can be improved.
Can we add protection API side, even if the IP changes and the headers are all correct?
Related
There is a registration service using SMS. The phone number is transmitted to the api of the service, then the service sends the code in SMS. How to protect the service from an attack using bulk SMS. For example, an attacker will send multiple API requests with different random phone numbers. It is possible to identify attempts to register by IP. But the provider can use one IP for a large number of users.
It is possible to limit the number of hits from one IP per minute.
you can add rate limit, doesn't it work?
I have api which will return user status i.e exists or not exists in the shop against email. Now the challenge here is to rate limit any specific user/bot which is sending multiples request. One solution is to use advanced cloudfare rate limit but its only support IP counting in core subscription which we have already but IP counting is not a good solution at all since it can be send from any corporate LAN having multiple users or proxy servers.
While if I go for normal server side solution we have node modules like express-rate-limit but I still think the user is coming to our server and then we are blocking them.
Not sure if we have any best solution on cdn level. Also how can I track a user request uniquely with IP address which attributes I can use.
I’m building an application and I’m thinking about asking user phone number to send a verification SMS. Though, imagine if the phone number is cancelled and attributed later to someone else. Then, the new person would be able to connect to my app in the name of the old one...
So is there any way to prevent this behavior ?
I want to make it like tinder : sign up possible by 2 different ways : (facebook connection and phone number) or (phone number and mail)
I have another question : I see that many sms sending services are not free (all of them actually). If I make an api with these services, anyone can send a lot of http request to it and make me pay 0,05€ times 100000000 ? And I can’t rely on IP adresses because with 3G an ip is not associated with a particular person...
To your first question:
You are describing Two Step Authentication (aka Two Step Verification) which you can read about in the Wikipedia page: Multi-Factor Authentication (MFA):
a method of confirming a user's claimed identity by utilizing something they know (password) and a second factor other than something they have or something they are. An example of a second step is the user repeating back something that was sent to them through an out-of-band mechanism.
You are correct that a phone number can change owners (as can an email address though over a longer time period on average). You are using their phone number as that out-of-band mechanism described above.
If the user has recently authenticated with their password, when you send the user an out-of-band code and they re-type that into an input box you have some degree of confidence that the end user both knows the password and has access to the SMS message and are choosing to trust that association.
You will need to consider if, and for how long, you can trust that association within the security context of the use case.
For example, adding two step verification when detecting the end-user has just authenticated on a device you have never seen before is a nice additional protection. However, using the out-of-band SMS verification in account recover could open up a big security hole. You do not want to bypass the authentication with something they know (password) in a password reset flow by simply having access to that SMS number. SMS is also not an appropriate mechanism for one-time-password (OTP).
If you want to offer you users more protections on their accounts look into implementing true MFA with software tokens (eg. Google Authenticator, Authy, etc.) and hard tokens (eg. FIDO U2F devices such as Yubikey, Google Titan, etc.).
To your second question:
You are correct, IP-based limiting is insufficient. With SMS services you are likely going to be making a server-side API call to the SMS provider. First check to see what security features your provider has out of the box. Next, protect your endpoint that is triggering the API calls to the SMS provider.
Rate limit the number of SMS messages to any one given recipient (eg. no more than X SMS messages to a single number per Y minute window)
Rate limit the number of SMS messages one person can make to different numbers (eg. no more than X different phone numbers per user per day).
Do not allow unauthenticated requests. The user should have already completed the first authentication step (something they know eg. username/password) before performing the out-of-band SMS step.
Protect the SMS form from Cross Site Forgery Requests (CSFR). Your back-end should only make the API call to the SMS provider if it knows the request came from your front-end and not another host.
Protect the SMS form from bot attacks. There are many approaches with Google ReCaptcha being one of the more common.
my case is simple:
I need an application layer solution to identify and then apply some sort of rule to requests coming from the same origin.
If a guy will request my server from Postman, or from a browser or from a cURL I want to identify this guy and then do something with this information.
In my particular case I want to blacklist a guy who would be attacking my server for sometime.
Is it possible in Node/Express?
There is no uber identifier that comes with a web request that tells you who the user is behind the request, no matter how the request was initiated (browser, cURL, Postman, node.js app, PHP app, etc...).
This question comes up pretty regularly among new web developers. In the end it boils down to two things:
Requiring users to have an account, login to that account in order to use your service, requiring login credentials with every use of the service and then tracking their usage to see if it meets your usage guidelines. If it does not, you can ban that account.
Rate limiting users either by account or by IP address or some combination of both. If they exceed a certain rate limit, you can slow them down or deny access.
A browser provides a cookie so you can attempt to identify repeat users via browser cookies. But, this can be defeated by clearing cookies. Cookies are per-browser though so you can't correlate the same user across multiple devices or across multiple browsers with a plain cookie.
cURL and Postman don't provide any identifying information by default other than the originating IP address. You can attempt to track IP address, but there are some issues with relying only on IP address because corporate users may be going through a proxy which makes them all appear to come from the same IP address. If you ban one user for misbehavior, that may affect lots of other innocent users.
If you look how Google, Facebook, etc... do this, they all require you to create some sort of account and then provide credentials for that account with every request. This allows them to track your usage and manage your traffic if needed. And, for free usage, they generally all have rate limits that limit how frequently you can make API calls. This prevents any single user from using more than an appropriate share of the load of the service. And, it allows them to detect and regulate accounts that are abusing the system.
One step further than this concerns how an account is created because you don't want an abuser to just be able to run a script every 10 minutes to automatically create a new account. There are a variety of schemes for protecting this too. The most common is just requiring some proof that a human is involved in creating the new account (captcha, question/answer, etc...) which prevent automated account creation. Other checks can require a valid credit card, unique email address verification, etc...
I am working on an application that requires communication via email with the user and the client for whom the application is being developed.
Basically the flow is thus :
Program Does Something
Program sends an email detailing if it worked or not to the user and my client
We have established a Gmail account to make this happen. Unfortunately my clients users are multinational and Gmail freaked out and started blocking users, which started throwing exceptions when they were trying to use the program.
In the emails I saw when I checked the account, I saw I see at least two of these emails that say "Suspicious sign in prevented", and there was a red bar that said multiple attempts were tried to sign in and asked if it was me, and there were points all over the world.
How would I go about making it so that Gmail doesn't freak out when it sees users trying to sign in all over the planet?
Isn't sending through a some kind of a server application not an option? I.e. instead of making SMTP connection from your end user app directly to Gmail server your app sends a request to your web server which does actual SMTP connection. This way you'll also eliminate issues when SMTP ports are blocked on end users' machines.