Handling API attack attempts

#1

I’d like to know what the best practice is when an attack is detected against a ServiceStack service.

I know this is not ServiceStack specific per se but any input would be appreciated.

I have seen another post using a filter and returning 403 (Best practice for implementing a blacklist IP / url check)

I’m using OrmLite exclusively with the typed API so from another post [here]
(Preventing SQL Injection Attacks) I gathered that SQL injection is not possible.

But for argument’s sake let’s say a mechanism is in place to detect attacks and if an attack is detected what should be returned? 403?

Is there a way to completely “drop” the request and let it timeout from the perspective of the attacker (caller of the API) and wouldn’t this be better?

I’ve been reading hacking tutorials and this would seem to be the most annoying for a potential hacker.

Thanks.

#2

This is a very broad topic, but I’ll add some notes incase it helps.

If there is a single bad actor, approaches like the blacklisting of IP address/banning users/making it harder for a bad actor user to register can provide a decent deterrent, but at the cost of likely adding friction to your new user registration process. Eg, if you are a high touch B2B setup, you can filter registration of of known free email domains to require manual approval or something similar. Lots of downsides, so it greatly depends on your business and level of problems some users are having.

For DoS type issues, CDNs like AWS CloudFront can at least reduce the impact on your services, and additional services like AWS Shield or AWS WAF can provide some additional protections, but your miles may vary.

Dropping a connection from your API will end the request for the client as well, letting it ‘timeout’ will still take away more resources from your server having a much larger impact on your server than the attacker. This is where CDNs can make a larger difference since the tables of resources are flipped where connections are cheap for the server to mitigate and lots never make it to your own API servers.

Again, it depends on the behavior/type/scale of attacks or issues the bad users are creating. Creative strategies like OpenCageData use for people caught continually registering multiple free accounts with new emails are just silently fed bad data and told to “Enjoy!”. If it is a public API, things will be harder and more general errors like “403” are probably the way to go.

Hope that helps.

#3

IMO it dosn’t matter much what HTTP error you return, only you want to be careful about the error information returned that it provide the attacker any additional information, e.g. when Username/Password sign in attempt fails you should return “Invalid Username or Password” as if you just returned “Invalid Password” they would know they have a valid Username.

But yeah any HTTP connection tricks like @layoric says should be handled by a purpose-specific proxy that are designed to withstand and identify such attacks, Cloudflare is another popular CDN known for their DDoS protection https://developers.cloudflare.com/ddos-protection/

#4

Excellent. So 403 it is.

I’m already terminally paranoid about the error messages I return and for anything that isn’t in the exact format expected from the app that sends the call I return generic stuff and log the details.

Thanks a lot. That was helpful.

2 Likes