Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to protect the 'public' part of a REST service from spam?

Tags:

I have a REST service that's reasonably complete and will be used with an iOS app. It's built using Ruby/Sinatra but I don't think that really matters here.

I'm using HTTP Basic Authentication over SSL for various endpoints and that part is working very well.

Question is: How do I stop spammers etc from calling parts of the REST service that aren't protected via HTTP Basic Authentication?

Example: User Registration

Let's assume the REST call is (POST) .../register_account passing a JSON object in the body.

For obvious reasons, this call cannot expect a username/password linked to a user account.

Ideas are:

1) The app has its own 'username' / password and some calls would check for app-credentials. Problem: Rooting the device etc could unearth those credentials.

2) The app passes a secret token via a HTTP header to the REST Service for those calls. Problem: Same as (1)

Are there any techniques commonly used out there to prevent such spam calls? I'm thinking maybe introduce the iPhone's device id in the mix but haven't identified a definite approach yet.

Thanks

like image 851
Riaz Avatar asked Jan 20 '12 19:01

Riaz


People also ask

How do I protect public REST API?

Use HTTPS/TLS for REST APIs As one of the most critical practices, every API should implement HTTPS for integrity, confidentiality, and authenticity. In addition, security teams should consider using mutually authenticated client-side certificates that provide extra protection for sensitive data and services.

What is API spamming?

Spam Check API performs a wide range of advanced heuristic and statistical analysis tests on email headers (if exists in text) and body text including text analysis, Bayesian filtering, DNS blocklists, and collaborative filtering databases.


1 Answers

While the app-specific code is a good idea for a first line of defense against spam, you should still implement some rate-limiting on any services you are concerned about.

For example, if you use sessions on your REST services, you can easily rate-limit the number of calls you process from a single session. The session doesn't have to be authenticated at all and is only used to identify a single client while they are making requests. A simple redirect back to the requested service if they try to connect without an open session is all that's needed, and virtually all web frameworks or stacks have this built in.

You can also rate-limit on other properties, such as IP or user-agent fingerprint, but those are less reliable than a session-based method.

like image 84
cdeszaq Avatar answered Nov 07 '22 23:11

cdeszaq