I'm currently working on a small JavaScript library which makes requests to a REST web service. Since the server side needs to log incoming request to measure the number of requests, I want to secure it somehow. The library is very similar to the Google Maps API. So my question is now, is there some way to secure it better then just adding an API key to the libraries requests? How can I ensure, if that is even possible, that only the 'right' client uses the key? I guess I could compare the referrer url to a set of valid urls, but this can be spoofed to right? Please keep in mind that is impossible to use some else's authentication method (facebook, google, twitter etc.) since it has to work without user input.
Cheers,
Daniel
A decent RESTful approach would be to require an Authorization header to be supplied by the client, matching some scheme that your server will accept (see Basic Access authentication as an example). Seeing as you only wish to validate that your client is the one making the request, you probably don't need too complex an authorization mechanism.
Related
This is a design question for AngularJS websites that access a REST API. Since all the AngularJS code can be viewed from the client side (assuming obfuscation is not completely secure) how do you hide the API access credentials (the API key and password or even a JWT)?
This can be extended to a broader question about how other application logic can be hidden in an AngularJS website?
My research led me to some insights, one of which was
http://billpatrianakos.me/blog/2016/02/15/securing-api-keys-in-a-javascript-single-page-app/
But this has me more confused now, since the post suggests an SPA connecting to a REST API is not a good architecture. I thought it was and now can't figure what the right approach is.
The closest I can come to an answer is this resource:
https://developers.facebook.com/docs/facebook-login/security#appsecret
Facebook, is pretty good with their security and say:
Never include your App Secret in client-side or decompilable code.
Use unique short-term tokens on clients.
In short, do not keep API secrets on the client side
Answering the discussion in comments for sake of not being brief:
And then my question would be "what then is the correct architecture for SPAs and server side code (or database access)?".
There's no one correct architecture, it depends on the size and scope of your project. It will also depend on what frontend and backend frameworks you choose. Those choices also will depend on how many other APIs you are calling, or what other developers or you are most familiar with.
Speaking more specifically about security though, ideally you'd like to set up a session for the user which consists of a token that the user uses to identify himself. This is usually generated for each user by the server when they login. Generally this is provided by the framework you are working in, but even if it isn't, it's fairly simple to build. You will want to prevent cross origin requests (making sure the user is actually on YOUR frontend) and have secure connections (setting up SSL and https, though this can get complicated). You will generally want to run your JS code through something like Uglify to prevent it from being too easy to look through, but this does NOT guarantee that people cannot take that code and un-uglify it.
As the other answers have suggested, you should never keep API keys or any secrets in the client source code. There is no way to hide anything on the client, and obfuscation != security.
If you are looking to architect secure authentication/authorization into your app, you will want to return a JWT to the AngularJS application. You can then pass this JWT as a Bearer token to your API which will verify the validity of the token and allow the API to authorize access to the AngularJS application.
As for where to store the JWT token, you can store it in either Local Storage or in a cookie. There are serious considerations between choosing whether to store the token in either of these locations.
If security is your concern, I would look into the OAuth 2.0 Implicit Flow.
Don't put API keys in your client side source code. Keep them on your server, and have your client make a request to YOUR server, which then calls out to external APIs for data.
Let's say I write a piece of code that makes an http call to a web api, something like:
$http.get('www.myapi.com/api/controller/endpoint').then(function(resp){...})
I then give this code to two people that live in different cities and they hit my API from their respective houses (just from some browser). What information can my API get out of the http request that will allow me to tell apart person A and person B calling it? Is the IP always available? Is the MAC address ever available? What else is there?
How can person A pretend to be person B when calling my API?
Furthermore, what if person C calls my Web API from their own Web API (backend)? Will the same information be available, or what will be different?
This is a general question, but if you want to get specific, let's assume ASP.NET Web API 2 is receiving the http requests.
You're describing a desire for pre-authentication.
The IP will always be available. You could restrict the service to only those IP ranges. It's not a good way to do authentication.
Trying to get around having to perform authentication is not safe. You should use a proper authentication method. Combining IP restrictions with other methods is fine.
John Meyer's answer is essentially pre-shared token based user authentication. Having a valid token constitutes being constantly logged in. The token can be compromised far more easily than a typical token based user authentication that establishes a temporary token with a limited lifetime.
If you decide to go the pre-shared token route, please use a method that supports proper rotation or permutation of the token over time, such that it isn't vulnerable to replay attacks.
Your best option for this scenario is typical session-token based user authentication.
If you're actually not interested in who is using your service, only that they be uniquely identified, you can safely establish a session (or permanent, or arbitrary lifetime) cookie per user by the http Set-Cookie header that all clients should automatically respect and support, then use that as your method of tracking.
My team has accomplished this by requiring that an identification header be included on all requests. This does require some customization on the part of the calling party, but does not necessarily require that the user be logged in. Of course, the value of the header could be change by malicious users so if these calls need to be very secure you will need traditional authentication.
you seem really confused about this. what you are looking for is called authentication.
as you tagged C#, i am assuming you are developing your api in C#. I recommend checking Web Api.
there are a couple of authentication methods available these days. if you are developing a rest api, you can use json web tokens.
you can get a lot of information about the client calling your api via http headers.
I think you can always go with fully authenticated. I see your desire to go for a semi secured set of endpoints but I don't think any of the approach would serve you best. MAC, ip, user-agent, custom fields anything can be spoofed to be honest. Going with a bearer token or session token is your only bet here. For public apis you can limit user requests based on ip or you can try finding out whether a specific ip is trying to exploit you and thus block it but finding true identity might not be possible anyway.
I want to create an API at www.MyDomain.com that is accessible from public websites www.Customer1.com and www.Customer2.com. These public websites display each customers inventory and do not have any login features. They will use AJAX calls to read data from my API.
How can I secure the API so that it can be accessed via AJAX from different domains but no one can access the API to be able to scrape all of my customers data and all of their inventory?
I have tried thinking of different solutions on my own but they would all either require people to login to the public websites (which isn't an option) or it would require some secret "key" to be displayed publicly in the browser source code which could then be easily stolen.
Any ideas would be greatly appreciated.
Thanks!
P.S. Are their any obstacles that I am going to run into using Javascript & CORS that I need to look into now?
Anything that is accessible without authentication from a browser is by definition insecure, so you can't stop that. Your best bet is to have to have a relationship with the owner of customer1.com and customer2.com - the server apps for those two websites would make an HTTP call to you and authenticate with your service. Going this way also avoids the CORS issues you're talking about.
If you've already designed the client functionality, you can still probably do it without much change to the javascript - have it point to customer1.com for its AJAX call instead of your API, and customer1.com would accept this request and just act as a proxy to your API. Aside from the authentication, the rest of the request and response could just be pass-throughs to your API.
You can use Microsoft.AspNet.WebApi.Cors.
It's just need add ONE line at webapi config to use CORS in ASP.NET WEB API:
config.EnableCors("*","*","*");
View this for detail.
The simplest way to provide a minimum security here is to provide some kind of token system. Each app has its own token, or combination of tokens which it must pass to the server to be verified. How you generate this tokens is up to you and other than being linked to app's access, doesn't have to mean anything.
Provide a way for each API implementer to open an account with you. This way you will know who is accessing what and in some cases you can block/stop service.
For instance, a token can just be an MD5 hash:
7f138a09169b250e9dcb378140907378
In the database, this hash is linked to their account. On each request, they send this token with what they want. It is verified first to be valid, then the request is fore filled. If the token is invalid, then you can decide how to deal with it. Either don't return anything or return an "access denied" (or anything you want).
One thing to avoid is having a single token for everyone, though this can be a starting point. The reason for this is if some unauthorized app gets a hold of this token and exploits it, you have to change the token for everyone, not just the app that somehow leaked the token. You also can't control if someone has access to something or not.
Since you listed ASP.NET, I can also point you to WCF, which is fairly complex but has all the tools that you need to setup a comprehensive web service to service both you and your clients.
I hope this gives you a starting point!
EDIT:
There are security concerns here in the case that someone leaks their token key somehow. Make sure that you setup a way in which the app/your service do not expose the the token in anyway. Also have a flexible way of blocking a token, both by your clients in you, if it so happens that a token is exploited.
Looking at Twitter OAuth Libraries, I saw this note:
Be cautious when using JavaScript with OAuth. Don't expose your keys.
Then, looking at jsOAuth examples, I noticed that the keys are exposed in the code.
So my question is: How it is possible to not expose your keys when you use an OAuth library in Javascript?
Thanks.
UPDATE: Ok, maybe jsOAuth is not the right library to use, but how it is possible to do authentication with OAuth on a full Javascript web site?
As said in the documentation linked by you:
Written in JavaScript, jsOAuth aims to be a fully featured open source OAuth library for use in Adobe AIR, Appcelerator Titanium and PhoneGAP. In fact, anywhere that javascript can be used and has cross-domain XMLHttpRequests. For security reasons jsOAuth doesn't run in the browser. Browsers are only mentioned here for running the test suite. If you need jsOAuth in the browser, write an extension.
A good answer to your added question is available here:
Secure OAuth in Javascript
The only really reasonable way, right now, to do OAuth 1 in the browser, is to route API-calls via your server.
There simply is no way, as far as I have understood it, around this. If you do OAuth 1.0a calls through JavaScript from the browser -> You will HAVE to expose your consumer secret and access token secret, to at least the end user.
You cannot store these credentials in:
a cookie, the user can find them.
local storage, the user can find them (better than cookie though, since it does not entail sending a cookie back and forth all the time over HTTP)
in javascript, the user can find them (although this is probably your best bet since it is easier to obscure).
If it were only the access token secret that was exposed to the end user, that would be bearable - since it is in fact he/she who have authenticated your application. But losing your consumer secret is really not so hot, it means that your application is eligible for identity theft. I.e someone else could write an app that claims to be your app.
Even if you made it work securely in the browser, you are hampered by cross domain security blocks.
You could also make a script that sends all necessary values and parameters to the server to do the signing with.
The signed URL can then be sent back to the client (browser) that in turn does the actual request.
I have implemented OAuth 1.0a on the Twitter API that way using jsonp requests.
The benefit of this is that the response body is not relayed via your server, saving bandwidth.
That way you can have your cookie and eat it too.
Is there a norm for AJAX security?
When making an XMLHttpRequest, if querying an HTTPS url, will the browser handle all the certificate business and properly encrypt the request (or use an already existing authenticated tunnel)? Are there any security flaws in this model?
Then there's also user authentication issues with AJAX. This made me think that using the user's password to encrypt part or all of an AJAX request could solve some authentication issues. I've seen some impressive javascript based encryption tools. It seems like there'd be lots of potential there to build a single system that takes care of both encryption and authentication(host level and application user level). I have however not seen anything that seems 'tried an true'.
My question can be summed up as:
Is there a norm for secure AJAX either
using browser technologies or client
side javascript? What
is it? And if not, what's preventing
us from building one using javascript?
Thank you, as always.
SSL through HTTPS is sort of a cooperative venture with the destination server. The destination server will report its identity with its identity certificate (sent back to the client). This is part of the protocol that will encrypt the data stream between the client and the server.
However, this just encrypts the stream, it does nothing about several other security issues. Identification and authentication of the user entity making a request is handled through other means. If you're encrypting the stream with SSL, it should be safe to use HTTP basic auth. After that, the response to authentication should be a session id sent back to the client that will pass it back on all subsequent requests. Application servers typically manage the creation of those session ids.
Ajax does not inherently introduce new
security vulnerabilities in the realm
of web applications. Instead, the
applications face the same security
issues as classic web applications.
Unfortunately, common Ajax best
practices have not been developed,
which leaves plenty of room to get
things wrong.
from: http://www.securityfocus.com/infocus/1868
Basic authentication makes sense. I found this article explaining how to do it.
I somehow still have this desire to not use all the browser technologies and encrypt/authenticate things myself. Not sure if that would make any sense. Key caching would be hard to accomplish.
I'm still looking to find out if this (SSL + using basic auth in ajax calls) is the norm.