My website returns a JSON string contains database result when you call the URL through ajax. It's actually public. I mean everybody can send an ajax request to my website and simply get the result neatly (currently my website acts like a free API).
Now all I'm trying to do is authenticating all requests and just response the known ones. So I think I need to pass a token with along each request for identification.
My question: How should I make that token (that no one else can)? And how should I identify that token on server side?
If your "website" and the "app" that calls your website reside on the same domain. Then this can be done server side.
First CORS will stop any java-script app from replicating your client code on another server and calling, or the lack of.
Second. On your server just check that all incoming calls are from the same HOST or the host you want to permit. This would reject any calls that did not originate from the same domain - which you control.
I don't know what language you are using so i can't post code.
I suggest you use jwt to authorize. U can achieve this by requiring that a user log in first and respond with a token on successful request. This token will then be used for subsequent requests
Related
I am developing a Chrome extension which will be sending data via an AJAX request using jQuery. I need to ensure though that only the logged in user has send the request. This might not be the right approach trying to secure the AJAX request itself so any advice is appriciated.
you cannot secure Ajax requests on client side as every one can request to your APIs if it's included in your JS.
but there are some workarounds which you can choose to have more secure interact with your server:
you can send encrypted data
you can also obfuscate your code to make it much harder to read
use SSL to protect data from snoopers
EDIT:
as you mentioned if you want to make sure a user is logged in to do something you can use encrypted cookie and a token as mentioned in another answer. but if you want to prevent requests and not rejecting them maybe above solutions will help you.
To make this work, when the user logs in, you need to set a cookie that contains some sort of authentication token or session ID (usually some unpredictable string of characters) that is also stored on your server.
Your Ajax request can then include that authentication token from the current browser's cookie as a parameter of the ajax call and your server can then authenticate that the token belongs to a legitimate user.
If the user is not logged in, there will be no cookie and thus no token.
I have a PHP application which has some jQuery and Ajax features in it. I would like to know, how is it possible to regenerate the Session Token - which I'm sending to validate the Ajax request - upon each Ajax request (without loading the page)?
I have more elements on the page which are running multiple Ajax queries, however at this moment they all get the same token. So if someone has the tokey, they can submit a forged request from another form I guess.
Generating token on client side makes no sense. You can't trust anything coming from client side, as you don't know if it's your client software which sends the request, or a malicious one.
You must create as many tokens as you have ajax possible requests, and return a new token with each response.
You should generate a CSRF token on server side for each user or each session. You can store it in your database, or in your session. You should send that token to your client, and wait it back with the ajax requests. It will work until your site is not XSS vulnerable...
Btw the first step to secure your application is using the HTTPS protocol...
I have some questions about XMLHttpRequest using $.Post $.Ajax:
1- How the server side verifies if the request was sent from same browser?
2- How the server side verifies if session user who sent the request has been changed on same browser? (ex: user logout and another user login on same browser)
3- Do I need any special settings or PHP code at server side for #1 and #2?
Also please give me a link to good documentation about any security issues related to XMLHttpRequest.
Thanks
Browsers and servers use cookies to check whether request was sent from same browser. Every request will have cookies attached.
The basic idea about the sessions is simple. Whenever you send a request to the server, the session variable (if present) will be sent along with the request to your server.
Again, if you modify anything in session or clear the session, the response will contain the modified session. Since both request and response contain sessions, they can operate independently.
By using $_SESSION in PHP, you will be able to retrieve sessions in server. Just use $_SESSION['userid'] == to check whether it's the same user.
I understand you are a PHP person but take a look at node.js request and response objects for a better clarity about sessions.
Also you can encrypt session variables in server for security. Code Igniter session library is an excellent example for this.
It doesn't
By whatever mechanism it uses to track who is logged in for any other kind of request (presumably the data your server side application stores in the session will change)
No
I have a question regarding cross-origin policies.
I have a web app that gets data, usually in JSON format, via ajax.
When the web app initialize, a unique 'key' or 'token' is created from the server via ajax and is sent to the client, as a mean to identify it. The token is sent back on every ajax call for validation purposes. If it is not validated within two hours, a PHP script deletes it, and the user is required to authenticate him/herself again.
If the user sends another ajax call (i.e. if there is activity with the associated token), the token sets its expiration for another 2 hours.
On every call, I validate the token and then process the request. Everything works well but my issue is security-oriented.
Since the token is stored client-side (very crudely, like window.token = 'YTM0NZomIzI2OTsmIzM0NTueYQ==';), won't it be possible for malicious users to inspect the code, copy the JavaScript including the token, and create another app that will access the same data?
Since the token is stored client-side (very crudely, like window.token = 'YTM0NZomIzI2OTsmIzM0NTueYQ==';), won't it be possible for malicious users to inspect the code, copy the JavaScript including the token, and create another app that will access the same data?
Yes.
And possibly even more disturbing to you may be this: it doesn't even matter how your token is stored client-side - they'd even be able to login using the same API you expose to your users for logging in. (And if you think you don't have a login API because it's a form-post or something similar, you're fooling yourself - a form post is just as much an "API" as anything else... and can easily be replicated elsewhere).
The cross-domain stuff has very little to do with anything - as that's a client-side restriction of a browser - intended for the user's protection - not yours. I can make any HTTP request I want from a desktop or a server. I can even setup a service which allows me to proxy all requests made to my service over to your service... so the cross-domain security in browsers is of no help to you.
I like the way Google Maps' api is consumed, using a script include, but I'm worried:
My api is "semi-private", that is, accessible over the internet but should allow for secure transmission of data and some kind of authentication. The data should remain private over the wire, and one consumer shouldn't be able to get at another's data.
How can I use SSL and some kind of authentication to keep the data secure, but still accessible "horizontally" from a plain HTML page with no server-side proxy required? Do I need to manage keys? How will the keys be posted to the server without being intercepted? Can I use OpenId (or some other 3rd-party authentication) to authenticate api users, or do I have to create my own authentication mechanism? I've been all over Google and can't find a good guide to designing and deploying my API securely.
Right now I'm using REST and AJAX to consume them, but cross-domain calls are impossible. Any help or a pointer in the right direction would be much appreciated.
I'd probably use a dynamically-generated script tag with an SSL URL that included a key in the query string that was public-key encrypted. The server would use the private key to decrypt the query string parameter and return script that included the relevant information (or didn't, if the key was invalid). Or something along those lines. But I'll admit that I haven't actually had to do it in practice.
I'd also look for prior art, like Amazon's S3 service.
So:
User provides secret
Client-side code uses public key to encrypt the secret
JavaScript appends a script tag that includes the URL
Server handles the script request, decrypts the secret, checks it, and sends back the relevant response.
You may well need two cycles, because otherwise the request to the server could be re-used via a man-in-the-middle attack. That would be:
JavaScript appends a script tag that requests a unique key (probably with some confounding information, like the source IP and some random further key)
Server responds with a one-time key tied to that IP
User provides secret
Client-side code uses public key to encrypt the secret, including the unique key from #1
JavaScript appends a script tag that includes the URL
Server handles the script request, decrypts the secret, checks it, and sends back the relevant response.
The response could well be encrypted (to some degree) using the random key included in #1
None of which I've actually done. (Or have I? BWAa-ha-ha-ha...) FWIW.
OAuth might help with this situation by having the user login to the 3rd-party application and allowing your application to access the 3rd-party on their behalf by using a request token when you make xhr requests. http://oauth.net/documentation/getting-started/
========
The reason for using a server-side proxy boils down to the Same-origin policy built into web browsers: http://en.wikipedia.org/wiki/Same_origin_policy
Essentially the browser only allows requests to be made to the address in which the page comes from (e.g. facebook.com can only make requests to facebook.com URIs). A server-side proxy solves this issue by making requests to servers outside the current origin. Server-side proxies are also the best practice for making requests like this.
Check out the opensource javascript Forge project. It provides a javascript TLS implementation that allows secure cross-domain xhr requests. It might be of use to you:
http://digitalbazaar.com/2010/07/20/javascript-tls-1/
http://digitalbazaar.com/2010/07/20/javascript-tls-2/
https://github.com/digitalbazaar/forge
One potential solution:
Set up an Apache server to run your site.
Get an SSL certificate for your site.
Install the apache mod that comes with Forge to setup a cross-domain policy that allows other sites to access yours.
Host Forge's TLS implementation on your site along with your site's certificate in PEM format.
Tell other sites to include the javascript from your site and use it to make secure calls to your site to do whatever it is you want to.
(3rd party) Page uses OAUTH or something similar to authenticate the user and get a token from your server.
Page loads an IFRAME from your server via SSL passing the token along for authentication.
The IFRAME can communicate securely to your server via SSL
Use easyXDM or something similar to communicate between the IFRAME and the 3rd party page, using some limited RPC-like or socket-like API you create.
Or if you really don't trust the third party - do your authentication inside the iframe (no need for oauth then, just use a plain html form) and communicate anything the outer page needs to know about the user using easyXDM.
Not too sure of what the question is exactly, I take it you're attempting to do a jsonp-like call to [https://secure.com] in order to process/display data on [http://regular.com]?
Can the two servers talk to each other? How about something like this:
User logs in on [https://secure.com]
Upon authentication, secure.com generates an token (lets call it syntoken) and passes it directly to regular.com (server-to-server), maybe like a session_id, some arbitrary message, and an otp cipher (lets call it syncipher).
Broswer receives a session_id cookie, and Secure.com then redirects the browser to http://regular.com/setcookieandredirect?session_id=blabla&otpencryptedsynmessage=blabla
Regular.com looks up otp cipher using session_id as a key, and decrypts otpencryptedmessage "blabla."
If decrypted message matches the original message in the syntoken, we can verify user is logged in [regular.com] and regular.com generates another token (lets call it acktoken, lolz) and passes it directly to [secure.com], consisting of session_id, some arbitrary ack message, and a different otp cipher (lets call it ackcipher).
Regular.com then sends the browser a cookie consisting of otpencryptedackmessage (let's name this cookie "verified_session").
Finish loading the page.
From there, you can do jsonp-like calls to
https://secure.com/getscript.js?query=dataname&verifiedtoken=(verified_sessions_cookie_value)
where secure.com/getscript.js will take the verifiedtoken, lookup the ackcipher based on the original cookie session_id sent by [secure.com] as the key, and decrypt the otpencrypedackmessage. If the decrypted message matches the ack message, render the script file.
It's kinda like a 3-way handshake. The secret sauce is that the servers have to be able to talk to each other directly to pass secret keys discretely. You don't have to use the same session_id for both servers, I was just using that as an easy point of reference to find a way to access the syn/ack otp ciphers. The ciphers must be completely hidden from public.