When configuring a datasource for a database, like MySQL for example, I can give any host/username/password, and hit "Test" to see if my credentials are right.
This is a nice experience for users, but it also creates a problem. I can essentially try out multiple different passwords, for a given database host, and brute-force my way in.
But this is something that can be done to databases already. After all, I can invoke the mysql shell command in a loop to try out multiple different passwords. Indeed, but this is solved by the databases implementing rate-limiting. Database admins would ideally have a configuration like, if there's an IP that did three failed authentication attempts within 5 seconds, drop any requests from that IP for the next 5 minutes. Or something to that affect.
But with Appsmith, they don't have to worry about their own IP address getting blocked in this way. It's Appsmith's external IP that'll get blocked, and it's reputation tarnished.
That's not the only layer where we're getting blocked. We got a report from AWS recently, that they've noticed too many failed MSSQL authentication attempts to the same host, and so blocked our outgoing IP. This, is very bad, since we explicitly ask our users to whitelist our IP so we can connect to their databases. If our IP gets blocked by AWS, all those users may be blocked. Note that the IP we use for prod, is ultimately owned and operated by AWS.
So, we need some for of rate-limiting on the application level, for authentication attempts. Not on a per-datasource level, but on a per-hostname level. If there's three failed authentication attempts to the same host, in the last 5 seconds, irrespective of if they belong to the same datasource or not, then deny any further requests to connect to that host for the next 5 minutes. We can perhaps make the blocking specific to IP address too, since it might be possible to abuse this by trying to authenticate with the DB of one of our customers, and getting it blocked to disrupt their operations. We need a way to block only the bad-actors in this, as precisely as possible.
Ideas and questions welcome. We need to solve this, hopefully before there's another AWS alert about this.
We have found issues that are potential duplicates:
[#27735] [Epic]: Rate Limit Datasource Test API (85%)
If any of the issues listed above are a duplicate, please consider closing this issue & upvoting the original one.
Alternatively, if neither of the listed issues addresses your feature/bug, keep this issue open.
When configuring a datasource for a database, like MySQL for example, I can give any host/username/password, and hit "Test" to see if my credentials are right.
This is a nice experience for users, but it also creates a problem. I can essentially try out multiple different passwords, for a given database host, and brute-force my way in.
But this is something that can be done to databases already. After all, I can invoke the mysql shell command in a loop to try out multiple different passwords. Indeed, but this is solved by the databases implementing rate-limiting. Database admins would ideally have a configuration like, if there's an IP that did three failed authentication attempts within 5 seconds, drop any requests from that IP for the next 5 minutes. Or something to that affect.
But with Appsmith, they don't have to worry about their own IP address getting blocked in this way. It's Appsmith's external IP that'll get blocked, and it's reputation tarnished.
That's not the only layer where we're getting blocked. We got a report from AWS recently, that they've noticed too many failed MSSQL authentication attempts to the same host, and so blocked our outgoing IP. This, is very bad, since we explicitly ask our users to whitelist our IP so we can connect to their databases. If our IP gets blocked by AWS, all those users may be blocked. Note that the IP we use for prod, is ultimately owned and operated by AWS.
So, we need some for of rate-limiting on the application level, for authentication attempts. Not on a per-datasource level, but on a per-hostname level. If there's three failed authentication attempts to the same host, in the last 5 seconds, irrespective of if they belong to the same datasource or not, then deny any further requests to connect to that host for the next 5 minutes. We can perhaps make the blocking specific to IP address too, since it might be possible to abuse this by trying to authenticate with the DB of one of our customers, and getting it blocked to disrupt their operations. We need a way to block only the bad-actors in this, as precisely as possible.
Ideas and questions welcome. We need to solve this, hopefully before there's another AWS alert about this.