In my case, I would like to use CSRF, Cross-Site Request Forgery in typo3 extbase version 7.6.11 but I am not sure how to implement it. Could you guide me how to do that?
Did you already check the documentation on this topic?
You can use the FormProtection classes to do that.
Related
I am looking for a JavaScript AJAX request library for browsers that also supports cookies. I tried broswer-request but apparently it does not support cookies.
Any suggestions?
It is also better if it is available for NodeJS through NPM for server side.
Regards
I suggest jQuery's functions $.post, $.get, and $.ajax for the ajax requests. You can also edit cookies with jQuery, if you use this plugin.
StackOverFlow Post
Link to file
If I understand correctly, there's no need for a CSRF token if you're only allowing JSON as application/json from an "AJAX" (really AJAJ for JSON) form, right?
If someone tries to post to the form from another page using some nifty POST-to-iFrame hack it will be application/x-www-form-urlencoded, you can throw it out immediately.
If someone tries to post to the form using AJAJ, it will only succeed if OPTIONS has the CORS headers that allow it.
Conclusion: unless you're using CORS you're safe from CSRF as when you're using application/json instead of application/x-www-form-urlencoded.
Any contradictions I'm not considering?
Have a look at this Sec.SE question and answer. In short: you are correct (presently), but it's probably not a good idea to rely on this behavior, so use tokens anyway.
2022 Update
So much has changed - such as fetch giving more control to requests.
Yes, it's still dangerous
It is possible to do a cross-site JSON POST that includes cookies.
(the attacker can't see the response, but they can POST successfully)
CSRF is necessary by default.
Yes, it's easy to mitigate
Same-Site Cookies
There's now a same-site cookie option. Using this correctly makes it completely unnecessary to use CSRF tokens at all.
API Tokens
Completely abandoning Cookies in favor of per-request API tokens, such as the well-standardized JWT, will make CSRF attacks impossible.
This is best done by separating token routes from cookie routes, such as:
/api/account/xxxx for authenticated JSON API
/api/assets/xxxx for <img src="xxxx" /> and other assets that should not have a token in the URL and must therefore rely on cookies
According to this article it is enough to validate X-Requested-With header for AJAX requests sent by jQuery. So in this case it is not necessary to implement tokens?
And if yes, where is defined that cross-browser requests are not allowed?
Thanks in advance.
The article itself says that this method is insufficient:
Warning
The method of preventing CSRF attacks described in this post
is now considered to be insufficient. A comment on this post links to
more details about an attack that circumvents it.
I've created a RESTful API that supports GET/POST/PUT/DELETE requests. Now I want my API to have a Javascript client library, and I thought to use JSONP to bypass the cross-domain policy. That works, but of course only for GET requests.
So I started thinking how to implement such a thing and at the same time trying to make it painless to use.
I thought to edit my API implementation and check every HTTP request. If it's a JSONP requests (it has a "callback" parameter in the querystring) I force every API method to be executed by a GET request, even if it should be called by other methods like POST or DELETE.
This is not a RESTful approach to the problem, but it works. What do you think?
Maybe another solution could be to dynamically generate an IFrame to send non-GET requests. Any tips?
There's some relevant points on a pretty similar question here...
JSONP Implications with true REST
The cross-domain restrictions are there for a reason ;-)
Jsonp allows you to expose a limited, safe, read-only view of the API to cross domain access - if you subvert that then you're potentially opening up a huge security hole - malicious websites can make destructive calls to your API simply by including an image with an href pointing to the right part of the API
Having your webapp expose certain functionality accessed through iframes, where all the ajax occurs within the context of your webapp's domain is definitely the safer choice. Even then you still need to take CSRF into consideration. (Take a look at Django's latest security announcement on the Django blog for a prime example - as of a release this week all javascript calls to a Django webapp must be CSRF validated by default)
The Iframe hack is not working anymore on recent browsers, do not use it anymore (source : http://jquery-howto.blogspot.de/2013/09/jquery-cross-domain-ajax-request.html)
Is it possible to know that a HTTP request is from Ajax?If yes, how?
Many frameworks add a header X-Requested-With set to XMLHttpRequest when sending an AJAX request. If you are using jQuery or Microsoft frameworks, this should work. If using another framework, you'll have to check the documentation. Since normal requests don't have the header, a check for the presence of the header should be sufficient.
If you are using your own "home-built" AJAX or the framework doesn't do this, but does allow you to set a header, you could simply follow this convention and add your own header when making the request.
Most frameworks set X-Requested-With header to state it. But standard AJAX requests doesn't.
I would assume that any request received by a server would appear to be the same (ie http post/get) and that you would need to look at the referer, but that may just give you the browser details?