I'm writing a simple REST API, and I want to restrict access to my mobile-client only. In other words, I'm trying to prevent a malicious user from e.g. using curl to make an unauthorized POST request.
Of course, this is impossible. However, there are certain countermeasures that make it difficul...
For what its worth, I read somewhere in an official document on HTTP (sorry, don't remember the source), that returning 404 instead of 401 is permissible so as not to leak information about resource existence to unauthorized clients.
The OP is aware that this is security by obscurity. This is an interesting question because it's asking "what's the best method of security by obscurity I can do, when I have no other option?" Embedding the private key in the app is pretty good. Of course it is simple for a determined hacker to extract it, but there is a threshold of determined-ness they will need.
@Pascal Do you mean 403? It's right in the standard. 403 indicates that the user has valid credentials but is not allowed to access the resource; it makes sense you might want to hide the existence of the resource from users who aren't allowed to access it. 401 indicates invalid credentials; this would be like trying to hide the fact a log in is required at all. Returning 401 everywhere but your public resources is effective enough at hiding whether there's a real resource at that location or not.
Are you authenticating/authorizing your normal requests? Why do you need to prevent curl requests? What harm will this do to your application? Question number 1 about any security system is, "What threat are you protecting from?"
Essentially, I have a game where the player can earn extra points for watching ads. It's an online game, and to prevent cheating, the points are stored server-side. However, the ads are loaded client-side, and once they are loaded I send a POST request that increments the player's points. I want to prevent hackers from issuing these POST requests from their own hosts.
"but the difficulty in reverse-engineering an iOS app will hopefully deter all but the most determined hackers" - this is still easy to bypass. Use a jailbroken iOS device to unsign the app which decrypts it, then look for the private key in the binary, or easier yet just monitor requests using a something like Charles proxy.
Well, I'm using a secret key (stored client-side) to encrypt all requests, so monitoring won't yield anything but encrypted binary data. I'm obfuscating this secret key to make it a bit harder to find in source code. Of course, these are not the only security measures I am implementing. My plan is to verify physical devices using SMS, and also limit the rate of these API requests. I understand the risks, and in my case, these will suffice.
@jpmc26: No, I'm almost positive it was a 404. I remember thinking it was interesting that a spec would allow the wrong status to be returned on purpose. Thats why I remember it at all. Then again, memory does play tricks on us now and then...
@Pascal No. A 404 in place of a 403, as opposed to a 404 in place of a 401 (which is what you said above). The standard allows this explicitly to avoid revealing the existence of a resource to a user that is not allowed to access it. But doing the same with a 401 doesn't make sense; a 401 doesn't leak information if you require authentication for all locations that match the pattern the application uses regardless of whether they exist.
@Evi1M4chine This simply isn't true. How is SSL in any means security by obscurity? All parties involved know(or can know) EXACTLY how the process works down to the very last line of code. Nothing is obscured. There's simply a hidden private key that the owner never has to give up to anyone ever.
@Pascal, other way around. A 403 can stand in for a 404. A 404 is "doesn't exist". A 403 is "I won't tell you anything about this, even whether or not it exists".
Discussion on question by mpl: Return…
Discussion on question by mpl: Return…