Securing AJAX post to our API without ApiKey - javascript

We offer a web service, where a user can execute a POST request and get HTML. This is done server to server. The post that is sent with the request data includes his secret key, and other parameters.
We want to allow for this to be loaded via AJAX. So the request will be done client side, after the page has loaded. This way, no server side implementation will be required to install our service, beyond a slight modification to output the script.
We are not sure how to secure this operation, because we can not output the secret key as a JavaScript parameter (it is exposed that way). We usually use a user ID + apiKey combination to authenticate the request when it is don't server to server.
We know the users's key, and their valid domain, so if there's a way to make absolutely sure the domain that is sending the request cannot be faked, it may also solve our issue.
How can we make it so that we can differentiate requests coming that way, without exposing our secret key, so that we may provide the information only the authenticated requests?

Related

Prismic - How to make API calls without exposing Access Token

I'm building a vue js web app and I would like to make respective calls to the to my prismic repo, but I don't know how to do it without exposing my access token. I am using the rest api approach shown here.
Any ideas?
The http request syntax is as follows. I want to do this inside my vue components while not exposing the access_token.
http://your-repository-name.prismic.io/api/v2/documents/search?ref=Your_Ref&access_token=Your_Token
In my API/Security settings I'm also given a Client ID and Client Secret. I can't figure out how I can use these either.
Thanks
You'd have to store your access token on your server and make it process the requests on behalf of the client.
In the end, you'd send requests to your server instead of directly to prismic.io, your server will then send the access token authorized request, fetch whatever you need and return it back in response to the client.
The work flow would look like this:
Client sends request to i.e. http://localhost:8000/api/endpoint
Server sends request to prismic.io endpoint associated with the above endpoint.
Server gets prismic.io response and sends it back to the client.
Client gets the response.
If you want to hide your access token client-side, then it's impossible. To protect your access token the other two options are:
Make users use their own prismic.io access tokens.
Allow access only to authorized users.
The two options above are probably not what you want, so setting up a proxy server is what's left.

signing api calls from frontend to backend

I am implementing a secure way for the frontend to communicate with the backend using a secret key. The backend is a sensitive service (mobile banking.)
First I was thinking JWT, but the token-based approach has two disadvantages:
a) the front-end has to obtain the token, this means it has to send some auth data to the back-end - and if the front-end can do this, anyone can do this.
b) even if there is some secure way of obtaining the token, anyone can fire up Chrome dev tools and use it while it's not expired.
So the alternative approach is to sign each request from a front-end with a secret key. The key is known to back-end and front-end the front-end is bundled and uglified so as to keep the key secret. We concatenate the request URL and its payload, encrypt them with a secret key and send the resulting hash in a header. The back-end gets the request, does the same encryption and compares the headers; if they are equal - it makes the request.
This leads me to three questions:
Does this really mean that even if the request is sniffed it cannot be reproduced unless the url+payload is the same? Is there something i'm missing?
Is there a JS library implementing this approach? (or maybe something for the backend too - I am using Django)
Is there a better approach?
Bundle as you want, if your security key which authorizes request is inside js i will be able to un-uglify (beautify) and get it. Use SSL to encrypt connection and just use JWT ;)
http://jsbeautifier.org/
You will have to authorize user somehow anyways, so it means sending private data to establish the "session". Let it be username, email, password or some "secret" token.

Render html views for multiple clients

I'm writing a Node.js server that answers to HTTP GET requests with a dynamic HTML page, rendered "on-the-fly" with some data retrieved according to the client requests.
To identify each client I use a session token (JWT) and this is sent back to the server as query parameter in each GET request, along with the other information, i.e.:
my.domain/api/service?token=blablabla&req=123
It works, indeed. I wonder if sending the session tokens as query parameters is a good (and safe) idea.
I would send it in the headers, but it's harder on the client's page because now I just set an href tag to the url above.
Do you recommend another way?
Security wise, doesn't really matter how you send it, as long as it doesn't contain sensitive information (e.g password) because it's not encrypted, it's encoded and token can be decoded very easily.
Even if someone (hacker, user etc) alters the token, server will verify and notice that (if you've set up verification correctly) and you can deny access to page, media, data or whatever your user requests.
Important! Use SSL! Otherwise hacker can steal the token from its owner and use it himself, server only checks if it's valid and not altered, not where it came from. Read more: man-in-the-middle attack
How you do it, is totally up to you and your project, however I would personally send it via header.

How to secure JSON calls of a HTML5 App to a Server

I'm currently planning to develop a HTML5 app. The basic concept is the following:
A user should be able to create a profile with username and password. The Server should be implemented in Ruby on Rails providing a JSONP Api (for Cross-Domain issues).
So the App will send Ajax requests to the Server and get responses from it.
My idea was now to transmit a session_key (generated by server) on the first response back to the client. Then the client has to authenticate himself with this token.
But now i have some issues.
How can i secure the first call of the client (when he is transmitting user and password)?
How can i protect the Session-key from beeing spyed out?
I am a complety noob in security aspects. Therefore it would be great if i could get some hints where to look at.
Secure your connection with SSL. This should require no changes in your code apart from putting 's' after 'http' ;-).
I used add a checksum to the ajax parameters (calculated using the submitted data), and then to crypt the hole ajax request into one string.
Somthing like sRequest=459fdjnfdw4r908vn....
sRequests holds my data (sUser=user&sPass=pass&iCheck=34564).
Edit: My client code was not public, compiled to an app.

How to make REST calls secure

I'm calling a webservice using the REST methodology using JSON/JS/jquery and am wondering if there is a way to call the webservice without exposing my API keys in the source code. Anyone know of a way to hide the API keys from the public and still make the call?
I'm worried that if someone goes through my source, they will be able to use my API key.
You could delegate the calls to your own server, so instead of:
Browser sends HTTP request to external REST API, with API key
External REST API sends response to browser
you have
Browser sends HTTP request to your server
Your server sends HTTP request to external REST API, with API key
External REST API sends response to your server
Your sever sends response to browser
I'm not sure that someone else "stealing" your API key is a huge problem, though, since API keys (Google, for example) are frequently associated with specific domains.
There's no way to send the API keys to the client, and have them be usable, and not have them be exposed. What you more likely want is to have a translation layer, where you allow external (non-validated) clients to make requests against an exposed endpoint, then you use some sort of logic to validate the request, then pass through the request.
API keys are typically for your use as a partner, not for distribution; this is the way to avoid distributing them.

Categories

Resources