IP Blocking with Brute Force - oAuth - Rest WebService


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:


Number 2 of the OWASP list:

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 :)



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.


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. :)

Hi Nuno,

I had a similar case, used GetIP() but after V9.1.600 GetIP() stopped working correctly. This ended up caused by our OS load balancer configuration. Works fine if you don't have more than 1 OS front end servers and a load balancer. 

See below.