1

Similar questions have been asked before, but this a one is a little different. I created a REST API to send an XML document with `POST. I send data from my (Windows) application to the servers, which includes: open time, operating system, version, etc.

I have one problem though. How can I make sure people can't use the REST API? How do I know that the information sent to the server is from an application and not from someone who knows the URL? How do analytic software companies solve this problem?

Thank you.

Update

I would like users to use my application without having to log in. I am pretty sure that companies that create apps that do not force you to log in are able to see whatever you are doing.

JMRC
  • 1,336
  • 16
  • 34
  • You won't be able to make a "secure" API without some authentication of some kind. It does not need to be a person logging in, but you must have a way to verify that the person/script/server hitting your API is the one you think it is (with reasonable assurance) and that they are actually allowed to issue the API calls they are requesting (don't want customer X to manipulate customer Y's data). – SnakeDoc Jan 21 '14 at 21:15
  • The Amazon MWS API's are a good example of this. Amazon uses a couple of different "keys" to validate your API calls. `https://developer.amazonservices.com/index.html/188-2297581-2913105`. They do have a scratchpad site that you can actually see the XML data and see how they are authenticating users/scripts/servers. You can signup for a free developer account I believe. https://mws.amazonservices.com/scratchpad/index.html – SnakeDoc Jan 21 '14 at 21:17
  • @SnakeDoc. It is not important to me from which user the information is coming, since the main purpose is to track how long the application was used. I need to be sure that the data comes from the application and not from something else. I'd like to avoid having someone send 100 hour open time. If you take Microsoft Office for example, how do they track how long I used the application? If they would simply use a REST API, wouldn't I be able to see the URL they use and send some false information? – JMRC Jan 21 '14 at 22:49
  • you probably can, if you were to use wireshark while Office is open, you should be able to see the POST request as well as the URL (if it's actually sending this data off to M$). In your case, you may want to try to validate your application, but, if someone is tech savvy enough, they can still fool it. (you can't stop someone from writing a program that behaves exactly like yours and will hit your API unless you authenticate your apps and users). – SnakeDoc Jan 22 '14 at 16:30
  • To make it more difficult, you can try having your API require a "key" with each request, something your client program can compute but would be inconvenient for anyone who's just trying to POST to your API. So say, perhaps your API provides a key, which your client-side uses as input for an algorithm and it outputs a hash which you post back to the API with your request. This would mean anyone simply trying to fool your APi would have to first learn the algorithm your client implements and then implement it themself. I do not think you can make this foolproof, but you can make it harder. – SnakeDoc Jan 22 '14 at 16:33
  • @SnakeDoc. Isn't it possible to get the algorithm with a disassembler? I think I'm going to let the application send a message to the server during start up and when while closing down. If I only save the data when it is used for at least a specific amount of time, no invalid data can be uploaded and it isn't possible to send for example 1000 open times within one minute. – JMRC Jan 22 '14 at 19:45
  • of course it's possible to use a disassembler, but then you are dealing with someone who is quite advanced, and other than implementing an actual secure API using the authentication techniques mentioned earlier, there will never be a way to combat that. Even your latest idea can be spoofed, I could make a program to send the startup message and ending message over and over and still skew your data. You won't ever be "secure" until you can verify the data is coming from a real client. This is why most secure API's use some sort of unique token + security key, etc. Amazon has 3 "secret" keys. – SnakeDoc Jan 22 '14 at 20:21
  • 1
    the idea of the algorithm is to make it more difficult for someone to spoof and get at it. just like with disk encryption, it's not impossible to break it, it's just way too much work to be worth while (it's unfeasible). If you increase the difficulty to a point where I'd rather spend time "hacking" someone else, then you've won. – SnakeDoc Jan 22 '14 at 20:23
  • 1
    you could do other things to make it less attractive to try to mess with, such as rate limit API calls from the same IP address (so a bot can't sit there an pound on your API call day), impose rules when APi calls are acceptable and what data is acceptable to the API, etc. – SnakeDoc Jan 22 '14 at 20:27
  • 1
    You're probably write, I'll combine some methods to make it as hard as possible. Thank you. – JMRC Jan 22 '14 at 20:50

1 Answers1

1

Well there are several way to secure your service. You can always setup authentication & authorization for the service - this way the service will be available only to registered/known users.

Here are links few links for more details:

Best Practices for securing a REST API / web service

http://www.stormpath.com/blog/secure-your-rest-api-right-way

Also there are less sophisticated ways such as setting firewall rules to allow connections only from certain places -- I don't think it is a recommended approach.

Community
  • 1
  • 1
MeIr
  • 7,044
  • 6
  • 40
  • 70
  • Thumb up for the correct approach, but i would like to this without needing the users to log in. – JMRC Jan 21 '14 at 20:55
  • @JMRC Almost every single API I have every written against has an authentication of some kind. It's not a user logging in per-say, but rather a unique hash token that gets embedded into the API call header (XML structure like SOAP, or similar), as well as a user ID of some kind (like: companyXapiuser), etc. This way, a person "spoofing" your API will need a unique token that should only be known by the real API user, as well as the correct company name/username. – SnakeDoc Jan 21 '14 at 21:11