I'm drawing an architectural blank on good ideas of how to handle token authentication.
We have phone apps that generate REST requests to our backend API (rails).
Right now varnish is in front of our API and it's working great, however there's a gaping hole in how we handle auth: we dont.
I'm not looking to get flagged for asking for someone to solve it, I'm just asking from a high level how some have.
The phones create their device in the app via POST and get a unique token. They submit that token in all their other GET requests via Authorization: OAuth {token}. Our rails API handles this fine, but since the GETs are cached through varnish, we've hamstring'd it.
Due to performance we want to not cache each response per phone. The responses across the phones are all the same. If I were to add the token header to the hash in vcl_hash, that means that if 50 phones were to request /a/1, then we'd have 50 of the same items in cache, and the backend would get 50 requests. We'd like to avoid that.
I'm at a blank on how to authenticate the clients on a group level of some method.
Not sure if helpful:
Varnish 3.0.7 is what we have. Not against 4, just havent.
Every client goes through varnish, however we only care about User-Agent being android/ios. That part is done, anything else just goes straight to the API.
Given the previous point, it's safe to assume that all clients that we would hash/cache would have the same authorizations. It's purely the auth token issue. ie. All clients with a token we would just check to make sure it's valid and give them the cached resource. There will never be different resources across the clients using tokens.
If I'm understanding correctly, I see a couple potential approaches.
1) You can set up a backend that does nothing but validate the user - have Varnish validate anything that has not been restarted, and only after validation return the cached resource. Here's a good blog post that gives some VCL to get you started.
2) This is more speculative on my part - you can use ESI (Edge Side Includes) in Varnish to do the Auth. What I'm not sure about is if there's a way to kill the request or pass a failing status code from within an ESI fragment. If not, you'd end up returning the content even if the auth failed. Messy.
Related
I am making an api backend that makes use of another api,for example Twitter. (Please note the actual api isn't twitter but I am using them as an example).
Let's say that Twitter has a limit on the number of calls that can be made to their api and above this limit, it starts to charge my credit card. This is why it is very important to me that no one misuses my api.
I want to prevent people from looking at my frontend code and seeing which endpoint it hits, because if a malicious person were to do this, I would very quickly go over the limit and have to pay $$$.
My frontend code uses a get call to mybackend.com/twitter/api
Is it enough to simply add an Access-Control-Allow-Origin header to my backend?
headers['Access-Control-Allow-Origin'] = 'myfrontend.com'
The reason I am asking this is because I noticed that typing mybackend.com/twitter/api directly into the browser worked, which is not what I would expect if I had access-control-allow-origin set to a specific website.
Am I doing something wrong? How do I prevent someone from simply writing a script to hit my backend since it is clear that just typing it into the url of my browser works, despite me having an access-control-allow-origin header.
There are two possible solutions for your problem. You can try to implement a request signature for your API, to know exactly the source of it on your backend. You can take a look on how this works here.
The second option, and for me, a one witch fits your problem better, is to set up a Denial of service approach on your server Load Balancer to prevent multiple requests from a same origin, and so, don't let those kind of malicious requests hit your backend.
We have a JSON hash that the backend processes and serves to our frontend to calculate a map. The JSON hash is rendered from a GET request and is constantly being updated (not cached).
We need a way to lock down the route so that only the app itself can connect to it (stopping bots from pinging the URL to grab the hash). The frontend and backend are tied together in one Rails application (no separate services).
My issue is that ActionController::RequestForgeryProtection::ClassMethods does not support GET and ActionController::HttpAuthentication::Token is overkill since I need to restrict the JSON hash to the app (not to a specific user). Request.referrer can be spoofed so I hesitate in checking that.
I would appreciate any suggestions on how to reject outside GET requests to a Controller when it is not the app making the request.
Rails: 4.2.6
You won't be able to prevent arbitrary programs (ie: "user agents") from making HTTP requests against your server. You can, however, refuse to respond with useful content unless the user agent can prove that it's your app.
What you want to do is cryptographically sign your requests in your client app, then verify the signature on your server before responding. I don't know of any Ruby/Rails library to do precisely that (and I couldn't find any upon a cursory search), but it could be built from existing libraries. Here's a quick and dirty implementation concept:
Embed a secret key into the client app.
Whenever the client app makes a request, it:
Generates a UUID that will be used exactly once, ever. (A "nonce").
Generate a signiture by hashing the nonce with the secret key.
Pass the nonce and the signature with the request (probably as HTTP headers)
When the server receives a request, it generates a signature based on the incoming nonce and the secret key (which it already knows). If the signature matches, and the nonce has never been used before, then the server returns the content. If either of those conditions are not true, then the server can't guarantee that it's your client app making the request, and thus should respond with a failure.
Disclaimers:
This is entirely dependent on the security of the secret key embedded in the client app. If the key is hacked (and it will be, given enough effort on the part of the attacker), then this scheme falls apart.
If you use the same secret key for all client apps (and there's a good chance you'll need to, depending on your app architecture), then if one client app install gets hacked, you lose security on all of your installations.
This is just an illustration of the general principle, not a fully fledged secure implementation. I'm not a security expert and have not run through all of the potential attack vectors for this plan.
I also suggest reading up on how OAuth works. It solves a similar problem, and you may be able to adapt it for your purposes.
I've written a rails back-end for the mobile app I'm working on and it occured to me that even though I'm using token authentication, anyone could write a malicious script that continually registers users / continually makes requests in attempts to fill the database / attack the server.
I guess there are two questions here:
1) What modifications would I need to make in order to ONLY allow API access from my mobile app
2) How can I protect my API urls?
Thanks :)
There are multiple things you can do to protect your API :
The simplest thing you can start with is verifying the user-agent header in your request. That usually gives you a good indicator of what the initiating device is.
That being said, it isn't always accurate and its definitely fakeable.
If you control the client side of the mobile app as well, you could encrypt the requests/responses with a cypher or key system which requires a key that only your mobile-app knows. Look at openssl for that... using a public/private key pair.
Token authentication is a good idea. I would actually look at oAuth or similar systems for authentication and keep your session timers short.
On top of that, you can probably add some rate control in order to limit consecutive calls from the same IP in a given timespan.
Finally, I would look at something like "fail2ban" or similar to automatically ban brute-force type attacks.
I know that there are a ton of threads about this. But I'm still confused.
I've got an app that making request to my server(nodeJS) to get JSON-data.
For the moment everyone can get everything at: http://myserver/allUpdates/ with no password. They just have to know the URL.
So I thought I would do it little more secure.
I been looking at Basic Auth, that seems to work by sending username and password in the header for every request.
Is that enough?
Some guys say that it doesn't do much if youre not using SSL. But it must be better than nothing, right?
I've never used SSL and it seems there is a lot to learn.
So my question is, should I bother with auth when I'm not using SSL?
Or are there other alternatives?
Some guys say that it doesn't do much if youre not using SSL. But it must be better than nothing, right?
Unfortunately, those guys are right. Basic Auth is, when sent plaintext, probably worse than nothing as it gives you the vague feeling of some security without any actual security.
This is because it is trivial to intercept network requests through a proxy or similar. If you're not used SSL then every parameter you're sending is easily and readily visible, including your basic authentication credentials.
In answer to your question "should I bother with auth when I'm not using SSL?" - that depends. If you want to ensure your data is only accessed by authenticated users, then it's really SSL or nothing. But if all you're trying to do is reduce the burden on your servers (i.e, rate limiting), then maybe not. I'm going to assume you're looking to do the former, in which case I'd recommend taking the time to get to grips with SSL. There are lots of resources out there about using Node with SSL, depending upon what additional frameworks you might be using (Express, etc).
SSL encrypts your requests, which means that anyone that sniffs your network traffic can't read the payload of the request.
You have two ways to auth the client to the server:
send credentials or an API key with every request OR
login in the client once with credentials or API key and reuse it's session
In both ways, you should use SSL and send the credentials with your POST data.
I'm trying to find my way around the OAuth spec, its requirements and any implementations I can find and, so far, it really seems like more trouble than its worth because I'm having trouble finding a single resource that pulls it all together. Or maybe it's just that I'm looking for something more specialized than most tutorials.
I have a set of existing APIs--some in Java, some in PHP--that I now need to secure and, for a number of reasons, OAuth seems like the right way to go. Unfortunately, my inability to track down the right resources to help me get a provider up and running is challenging that theory. Since most of this will be system-to-system API usage, I'll need to implement a 2-legged provider. With that in mind...
Does anyone know of any good tutorials for implementing a 2-legged OAuth provider with PHP?
Given that I have securable APIs in 2 languages, do I need to implement a provider in both or is there a way to create the provider as a "front controller" that I can funnel all requests through?
When securing PHP services, for example, do I have to secure each API individually by including the requisite provider resources on each?
Thanks for your help.
Rob, not sure where you landed on this but wanted to add my 2 cents in case anyone else ran across this question.
I more or less had the same question a few months ago and hearing about "OAuth" for the better part of a year. I was developing a REST API I needed to secure so I started reading about OAuth... and then my eyes started to roll backwards in my head.
I probably gave it a good solid day or 2 of skimming and reading until I decided, much like you, that OAuth was confusing garbage and just gave up on it.
So then I started researching ways to secure APIs in general and started to get a better grasp on ways to do that. The most popular way seemed to be sending requests to the API along with a checksum of the entire message (encoded with a secret that only you and the server know) that the server can use to decide if the message had been tampered with on it's way from the client, like so:
Client sends /user.json/123?showFriends=true&showStats=true&checksum=kjDSiuas98SD987ad
Server gets all that, looks up user "123" in database, loads his secret key and then (using the same method the client used) re-calculates it's OWN checksum given the request arguments.
If the server's generated checksum and the client's sent checksum match up, the request is OK and executed, if not, it is considered tampered with and rejected.
The checksum is called an HMAC and if you want a good example of this, it is what Amazon Web Services uses (they call the argument 'signature' not 'checksum' though).
So given that one of the key components of this to work is that the client and server have to generate the HMAC in the same fashion (otherwise they won't match), there have to be rules on HOW to combine all the arguments... then I suddenly understood all that "natural byte-ordering of parameters" crap from OAuth... it was just defining the rules for how to generate the signature because it needed to.
Another point is that every param you include in the HMAC generation is a value that then can't be tampered with when you send the request.
So if you just encode the URI stem as the signature, for example:
/user.json == askJdla9/kjdas+Askj2l8add
then the only thing in your message that cannot be tampered with is the URI, all of the arguments can be tampered with because they aren't part of the "checksum" value that the server will re-calculate.
Alternatively, even if you include EVERY param in the calculation, you still run the risk of "replay attacks" where a malicious middle man or evesdropped can intercept an API call and just keep resending it to the server over and over again.
You can fix that by adding a timestamp (always use UTC) in the HMAC calculation as well.
REMINDER: Since the server needs to calculate the same HMAC, you have to send along any value you use in the calculation EXCEPT YOUR SECRET KEY (OAuth calls it a consumer_secret I think). So if you add timestamp, make sure you send a timestamp param along with your request.
If you want to make the API secure from replay attacks, you can use a nonce value (it's a 1-time use value the server generates, gives to the client, the client uses it in the HMAC, sends back the request, the server confirms and then marks that nonce value as "used" in the DB and never lets another request use it again).
NOTE: 'nonce' are a really exact way to solve the "replay attack" problem -- timestamps are great, but because computers don't always have in-sync timestamp values, you have to allow an acceptable window on the server side of how "old" a request might be (say 10 mins, 30 mins, 1hr.... Amazon uses 15mins) before we accept or reject it. In this scenario your API is technically vulnerable during the entire window of time.
I think nonce values are great, but should only need to be used in APIs that are critical they keep their integrity. In my API, I didn't need it, but it would be trivial to add later if users demanded it... I would literally just need to add a "nonce" table in my DB, expose a new API to clients like:
/nonce.json
and then when they send that back to me in the HMAC calculation, I would need to check the DB to make sure it had never been used before and once used, mark it as such in the DB so if a request EVER came in again with that same nonce I would reject it.
Summary
Anyway, to make a long story short, everything I just described is basically what is known as "2-legged OAuth". There isn't that added step of flowing to the authority (Twitter, Facebook, Google, whatever) to authorize the client, that step is removed and instead the server implicitly trusts the client IF the HMAC's they are sending match up. That means the client has the right secret_key and is signing it's messages with it, so the server trusts it.
If you start looking around online, this seems to be the preferred method for securing API methods now-adays, or something like it. Amazon almost exactly uses this method except they use a slightly different combination method for their parameters before signing the whole thing to generate the HMAC.
If you are interested I wrote up this entire journey and thought-process as I was learning it. That might help provide a guided thinking tour of this process.
I would take a step back and think about what a properly authenticated client is going to be sending you.
Can you store the keys and credentials in a common database which is accessible from both sets of services, and just implement the OAuth provider in one language? When the user sends in a request to a service (PHP or Java) you then check against the common store. When the user is setting up the OAuth client then you do all of that through either a PHP or Java app (your preference), and store the credentials in the common DB.
There are some Oauth providers written in other languages that you might want to take a look at:
PHP - http://term.ie/oauth/example/ (see bottom of page)
Ruby - http://github.com/mojodna/sample-oauth-provider
.NET http://blog.bittercoder.com/PermaLink,guid,0d080a15-b412-48cf-b0d4-e842b25e3813.aspx