I am having a hard time making CSRF Guard to work on Ajax Requests in my Grails Application. I already added the Javascript Servlet in the page and followed instructions in their website. The problem is that it kept on saying that I have missing token. Aside from that, our Ajax request is not inside a form which I would assume that CSRF would look for forms and auto-inject the token for Ajax POST requests. I just merely get each parameters and pass it as data in my Ajax POST request.
You should try with the pattern outlined by the author of this question Grails - Is there a recommended way of dealing with CSRF attacks in AJAX forms?
Related
I am soliciting advice on correctly implementing nonces for ajax powered forms.
The forms are written in plain html.
The way, I have currently implemented is - the default form submit is intercepted through javascript and before processing the form, a get call is made to get a nonce token in JSON, the resulting nonce data is appended to the form data and is sent to the server for further processing via POST (XHR).
For security reasons, I have limited the scope of the nonce to 300 seconds. And the url that generates nonce values check for http referer to ensure that requests are made from the site. However, this may be futile due to the reasons mentioned in Referer header: privacy and security concerns (MDN)
Thank you.
It seems creating and handling anti-CSRF tokens for Ajax calls in an Angular application is non-trivial and some are getting around the problem by applying a single token to every Ajax call. For example here.
The solution is quite neat. We just generate the token on the server and send it along with the first loaded page after sign-in. Then we ensure it goes out with all future requests like this:
$http.defaults.headers.common['RequestVerificationToken'] = 'token should go here';
But I am concerned this may simplify the job of an attacker. They need only get hold of $http in order to make any valid request. Is this the case? Is this method safe? Is there a 'best practice' regarding Ajax requests and CSRF?
Angular automatically does this for you.
Read Cross Site Request Forgery (XSRF) Protection section.
DOCS
I also suggest you read up CSRF, and what it is, if malicious script is already in your page it does not need to do cross-site requests to pose as the victim.
I am trying to use ajax in my spring mvc application. When I try a url (post/get) which is secured and needs authentication, the response is the html of login page as it is redirected behind the scenes.
What is the best approach to overcome this issue?
First, I would avoid displaying Ajax links to URLs needing authentication if the user is not authenticated, if possible.
If not always possible, your login page could be returned with a specific HTTP response code, (or any other way to distinguish it from a normal response) and your JavaScript callback could replace the entire body of the current page with the HTML received if this response code is received. Most AJAX libraries come with a way to define a handler to all the AJAX requests. Such a global handler could be used here.
The login page could also be adapted to only return a status code in case of an AJAX request, and the JavaScript code would then redirect to the login page (without using AJAX) if this status code is received.
I may not have explained the issue well. So I did not get the right response. However the response from JB Nizet contained some other points. So thank you.
I could solve the issue after coming back to this issue after some time, so
I posted about this on my blog.
I hope it is useful.
Do I need to use csrf tokens in my ajax requests?
I think that someone tricking my users to execute malicious ajax requests from another site, to my site, will fail because of the origin policy, which is handled by the browser, am I right?
I don't care about duplicated requests when using ajax, I'm only asking about the attacks.
Am I at risk if I don't use csrf in my ajax requests?
As per my research,
We can reduce the vulnerability by using POST request(for the request which will take side affect). But thing is that we can forge the POST request as well with form submission, cause same origin policy will not applies plain html for submissions. But it applies to request which are getting generated with JS.
So if you use ajax POST request and you are safe if you are using JSON payload.
Cause url encoded payload(POST request) can be forged with form submission from other sites.
If you use JSON, as it is not possible to send plain text pay load(with out urlform encoded) with html form submission you are safe. Because with ajax POST request if you use urlform encoded data payload it can be forged with POST form submission.
This is how we solved the problem with CSRF token in Ajax requests
http://mylifewithjava.blogspot.com/2010/11/implicit-csrf-protection-of-ajax_22.html
The fact that you are using Ajax doesn't mean that others have to as well. Your server won't be able to distinguish a request made by XHR from one made by <form> submission. (Yes XHR usually adds a header identifying itself, but this is not hard to spoof.)
So yes, you do need to consider CSRF attacks.
Edit
Django have a POC, which is why they and Ruby on Rails now implement CSRF protection on AJAX requests.
Once again, please check your facts before downvoting, and explain what the downvote is for.
Django comes with CSRF protection middleware, which generates a unique per-session token for use in forms. It scans all incoming POST requests for the correct token, and rejects the request if the token is missing or invalid.
I'd like to use AJAX for some POST requests, but said requests don't have the CSRF token availabnle. The pages have no <form> elements to hook into and I'd rather not muddy up the markup inserting the token as a hidden value. I figure a good way to do this is to expose a vew like /get-csrf-token/ to return the user's token, relying on browser's cross-site scripting rules to prevent hostile sites from requesting it.
Is this a good idea? Are there better ways to protect against CSRF attacks while still allowing AJAX requests?
UPDATE: The below was true, and should be true if all browsers and plugins were properly implemented. Unfortunately, we now know that they aren't, and that certain combinations of browser plugins and redirects can allow an attacker to provide arbitrary headers on a cross-domain request. Unfortunately, this means that even AJAX requests with the "X-Requested-With: XMLHttpRequest" header must now be CSRF-protected. As a result, Django no longer exempts Ajax requests from CSRF protection.
Original Answer
It's worth mentioning that protecting AJAX requests from CSRF is unnecessary, since browsers do not allow cross-site AJAX requests. In fact, the Django CSRF middleware now automatically exempts AJAX requests from CSRF token scanning.
This is only valid if you are actually checking the X-Requested-With header server-side for the "XMLHttpRequest" value (which Django does), and only exempting real AJAX requests from CSRF scanning.
If you know you're going to need the CSRF token for AJAX requests, you can always embed it in the HTML somewhere; then you can find it through Javascript by traversing the DOM. This way, you'll still have access to the token, but you're not exposing it via an API.
To put it another way: do it through Django's templates -- not through the URL dispatcher. It's much more secure this way.
Cancel that, I was wrong. (See comments.) You can prevent the exploit by ensuring your JSON follows the spec: Always make sure you return an object literal as the top-level object. (I can't guarantee there won't be further exploits. Imagine a browser providing access to the failed code in its window.onerror events!)
You can't rely on cross-site-scripting rules to keep AJAX responses private. For example, if you return the CSRF token as JSON, a malicious site could redefine the String or Array constructor and request the resource.
bigmattyh is correct: You need to embed the token somewhere in the markup. Alternatively, you could reject any POSTs that do have a referer that doesn't match. That way, only people with overzealous software firewalls will be vulnerable to CSRF.