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.
Related
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
I am trying to create a secure way for users to log in to and perform certain authorized actions on my custom website. I am trying to have good security without the use of SSL.
At login now, this is what I am trying to improve:
User types in credentials (e-mail and password)
Client browser (JavaScript) one-way-hashes password with SHA-512, sends credential as login-request
Java-based backend receives request, further encrypts the received password-hash(with salt etc) to fit the hashing in the database (which was created on registration), checks for match, and returns a cookie containing a fresh token.
Backend also connects token to user in the database, and the backend will therefore know who future requests is coming from based on this token (without ever sending credentials in the request)
The idea is that if someone manages to pick up such a cookie (or the initial request), it's impossible to get the user's password.
This is great and all, but there's still the problem with repeat-attacks and man-in-the-middle-attacks, when 'bad guys' pick up a request, and uses the token to do stuff on another user's behalf.
By reading up on how to prevent this from happening, I have found that an acceptable method of preventing this could be adding a 'counter' to the token in the cookie, to show how many times the token has been used.
Let's say the cookie initially contains a token and a counter of 0, like this cookie-content: "abc123:0", where the token is abc123, and the counter is 0. It's suggested that the client increment the counter every time a request is made. Let's say a user wants to send a chat-message to another user. The cookie attached to this request will then contain "abc123:1". The backend stores the counter as well as the token, and checks both values. If the received counter is more than the stored counter, awesome. If a 'bad guy' picks up the requests and try to repeat it, the counter will still be 1, and the server will reject it, as the stored counter also is 1(or more).
This sounds great, but I'm not sure how this is any more secure? The 'bad guy' can simply edit the counter-value in the cookie to be 99999 and succeed?
I figured the content of the cookie (the token and the counter) should be hashed in some way, so that the content isn't plain-text. However, the client is HTML/JavaScript; the 'bad guy' can simply check which encryption-method is used, and decrypt it. All scripts are public.
I read something about improving this by sending a one-time 'secret' from the server to the client before the request is made, but I don't see how I can implement this. I guess, on requesting www.example.com/chat, I could generate a random 'secret', and send this to the client, and the client can add this to the cookie when sending a chat-message, or use it as a key, so that an encryption would be more secure, but how would the server know the secret upon receiving the request? How can the server reverse this? The server has to know the secret when decrypting it, so where should it be stored? Plain-text in the cookie next to the hash? Then the 'bad guy' can do the same thing. In the database? Upon requesting www.example.com/chat, should the backend know WHO is requesting it, so that it can be stored in the database along with that user? In that case, how should the backend authenticate the user, to be sure that there's not a man-in-the-middle or repeat-attack requesting /chat?
What is this method of security called, and is it possible to use it for what I need (with HTML/JavaScript)? If not, what are my options, beside SSL?
It's called bad security that does not rely on trust.
The client needs to fully trust the server, otherwise everything - including the page that is used to enter the password - cannot be trusted. Currently the only way of establishing trust is the certificate store that is provided within the browser (you should be able to trust the browser!). And the only software that is able to use it across browsers is SSL/TLS.
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.