IP Blocking with Brute Force - oAuth - Rest WebService

Hi,

Because we developed our oAuth management we are not using the Outsystems User functionality.

The HTTPRequestHandler API provide us the GetIP action -> Gets the IP host address of the remote client (IP of the user machine performing the HTTP request).

So before the requester achieve the Rest API Method (in the On Request event) we will check if the IP is blocked or no

If no the request will reach the Method and validate the Client Id and Client Secret, if is not correct the process will add one attempt to our auxiliar table (IP_Access_Management)

One simple question for we fill more comfortable with our decision:

If we suffer a Brute Attack and because the request always archive the "On Request" to validate the IP. It's enough for we don't have performance issues.

Security wise seems ok because the Operation teams will see the IP that is blocked and that one can't do anything during a time or an unblock.


Thanks to share you experience.


Kind regards,

Nuno Oliveira



Hi Nuno,

I can't speak for the internals of the OnRequest action, but if you're querying the database every time a user contacts you in an effort to consult his previous attempts, that alone is going to take some of your resources. If you cache the results, that's less resources used, but that's still bandwidth being taken from honest users.

Could I ask you what attack vectors your team is thinking of? More precisely, do you predict a handful of malicious users abusing your system? I ask because while this solution will block average Denial of Service/Brute Force attacks, it probably won't do much against determined attackers employing Distributed attacks with a large number of IPs.

Hi Afonso, thanks for the reply.


I was trying to create something that the Outsystems platform already provides for us in the User Management:


https://success.outsystems.com/Documentation/11/Managing_the_Applications_Lifecycle/Secure_the_Applications/Protection_against_Brute_Force_Attacks


Number 2 of the OWASP list:
https://www.outsystems.com/blog/posts/owasp-10-web-application-security-flaws/


To avoid per IP a robot process send infinit requests with clientid and client secret until they get the Token


Is a nice observation: "Distributed attacks with a large number of IPs", but if per IP you have 5 tryes it means that to get the correct combination you need a world of IPs. Doesn't seem possible.


Related with Performance if is only the Database Request that has influency. I'm confident that is not a problem because this table will be almost empty and will check the IP that is an Index, imediatly in the beginning if is there that request in stoped and never archieve the method.


Thanks to braihstorm this with me 

After to get some input/ideas I can spak about this with the Security Experts here :)

Cheers


Solution

Hi Nuno. That solution seems fine, and I have used it in the past as well. You also have the precedent of using the same technique employed by OutSystems in the Users module - they have already done research on possible solutions to the problem, and if they came up with that solution it must be at least a good compromise between performance and security.


It's true that your database lookup will spend resources. However, cache would also consume resources - and worse, it would use memory, rather than the database disk. Yes, the cache would be reclaimed in case of low memory (so it would never cause an out of memory condition), but it could still cause performance problems. Not to mention the fact that it could get outdated if you have a farm with a load balancer.


If you want to consider something safer or more efficient, or if you're worried about DDoS, then I would recommend you to look into purchasing an enterprise software for intrusion detection.

Solution

Thanks Leonardo.

You toutch in some important points for we implement the process like this and feel confident that is the best approach.

Time to develope and work in the process to bring it live. I believe that this discussion will be part of a document. :)