I'm starting to get intermittent "blackhole" issues on my CakePHP 3 app. I think that it might be CSRF tokens expiring when a page is left open too long. Old answers (e.g. this CakePHP 2 one) point to a csrfExpires config key. However, I can't find any reference to any config keys in the main documentation or the code.
Can someone point me to the right documentation, or failing that provide your own info on config keys?
There's nothing in the security component docs because as of CakePHP 3.0, CSRF tokens are not part of the security component anymore, they are handled by either the (deprecated) CSRF component, or by the CSRF middleware.
If it actually is the security component blackholing your request, then it's probably not CSRF related, as invalid CSRF tokens would trigger different errors. Also note that by default CSRF tokens last for the browser session.
Related
I've looked at the following SO example which says that a unique token must be placed in the URL posting data.
That way if anyone creates a url like http://example.com/vote/30 it won't work because it does not contain the unique token.
I'm also reading through this tutorial which places a XSRF-TOKEN in the header. I'm just curious as to how this provides protection because if the user is logged in and clicks on http://example.com/vote/30 won't that request still pass?
In other words if I'm logged in and someone sends me the http://example.com/vote/30 link in an email and I click on it, wont that link still pass the the CSRF check, or will the browser not send the required headers since the the link will most likely open in a new tab?
It seems like the when the link is clicked the new tab will request the page. However the new browser window will not have the same XSRF-TOKEN that the logged in browser window has? Am I understanding this correctly?
CSRF
This above article offers a good explanation of what a CSRF attack looks like. The basic premise is you don't want a malicious website to make use of a valid session you have on another website. You prevent this by using a CSRF token. The malicious website doesn't have access to this token so they won't be able to make any POST requests on your behalf.
Spring Security CSRF
When using Spring Security, CSRF protection is enabled by default. The token is automatically configured when using supported HTML templating engines like Thymeleaf, but you can easily set it up on your own by following the documentation.
We have a token based OAuth authentication mechanism for our angularjs application. The acunetix tool indicated that XSRF threat is there.
Is CSRF an issue for token based authentication (Because we are not using any cookies for user identification / authentication / sessions)?
If CSRF is an issue for token based authentication, is there be any way to implement prevention without using cookies?
As far as I know token based authentication is in no way affected by CSRF. E.g. if you use cookies, and bad guys lure users into their site where they can create a special button that will do a post to your site -> here is CSRF where you can execute some requests on behalf of the users.
Now if you use tokens that are stored in session/local storage e.g., they are never automatically passed with the request. You probably use something like angular interceptor or similar technology to pass it along with every XHR request. This never happens automatically.
You can read a bit more on token auth in this very good post. In point number 6 there is a little section about XSRF/CSRF, XSS.
In my modest experience these big security tools can often tell you something that is not true just to make themselves more "significant". But it would be interesting to know exactly how it plans to execute CSRF and what exactly made it think it is possible? E.g. you might have a cookie that you missed?
P.S.
XSS attack (to steal token) gets more possible with tokens, since you can put HTTP-only like for cookies. So any successful XSS will be able to read your token, so you need to make sure that you have a good protection against that. But it's usually covered well by frameworks.
I've built an API with Node.js/Express which I'm currently using alongside my Angular app.
For authentication, I have a username/password setup which then returns a JWT which is happily used.
Now, I've been spending some time (and reading such Stormpath articles) I want to use cookies rather than localstorage for storing these JWTs. And thats where my questions begin.
So what I've essentially done thus far is updated the saving and reading, e.g. for saving from $window.localStorage['jwtToken'] = token; to $cookies.put('jwtToken', token);. And for reading, from return $window.localStorage['jwtToken']; to return $cookies.get('jwtToken');
At this stage I was wondering whether someone could help me understand a few bits, kindly correct and inform me of any missing parts of knowledge:
1 - So in addition to the actual saving and reading as above, is there anything else I need to explicitly set - what I think is HttpOnly cookie flag (so JS can't access the cookie data.
1b - Do i also need to update my node API so that instead of returning res.json its doing res.cookie?
2 - Do i also need to set the Secure cookie flag so that its sent via HTTPs. So at present i wrote a simple authInterceptor that attaches a header with each request: config.headers['x-access-token'] = token;. Is this where that secure cookie flag would be set?
3 - So using cookies am i correct to understand XSS attacks are minimised as JS can't touch the cookies however I need to concentrate on CSRF. For this I am thinking of using this CSRF middleware on my node api server side and use this alongside Angulars built in XSRF-TOKEN as described here. Is this a good implementation to follow?
4 - When looking at Chrome inspector, I see the cookie containing the JWT, however the HTTP/Secure/Same-Site are all untucked, also the Expires says Session. Could someone please explain what this means:
Sigh, I think thats it, sorry if its a little long winded. Hopefully others can gain from what we learn here.
Any help appreciated.
Thanks.
If you set HttpOnly $cookies.get('jwtToken'); wouldn't work...
1b. Don't understand the question here...
The Secure flag tells the browser to only include the cookie if the request is an HTTPS request. You can still make HTTP requests, but the cookie will not be included. document.cookie = "name=somevalue;secure"
If you set HttpOnly so that JavaScript can't read the cookie, that's some protection, but if you have XSS, then all bets are off. The injected script could still perform network requests, and do exactly what your code is doing to include the CSRF tokens. You still need CSRF-protection, but in most cases XSS means circumvention of CSRF-protection.
Session means the cookie will be deleted automatically if you close the browser (which people don't really do all that often anymore).
I have inherited a Ionic app which uses ng-token-auth+devise_token_auth to handle the authentication and the session between front and back.
What happens is quite strange. Sometimes (specially with slow connections) the request (or the response) get lost and after that I get only 401 http errors.
I know that that everytime I send a request the token expires, but when the xhr request is cancelled (by the server I suppose, or by the browser, I don't know) the token is expired without having been replaced by the new one generated by devise_token_auth gem.
I know Rails but I'm not familiar with Angular, neither Ionic and I don't know exactly where to look.
After reading a lot of SO answers where noone seems having my problem (which happens locally and in staging/production), I checked the following
storage is set as localStorage.
config.batch_request_buffer_throttle = 20.seconds
there is no pattern between cancelled requests, sometimes I perform get for the username, sometimes a post or a put to a comment.
Is not a CORS problem because it would happen always or never. (moreover I'm using a proxy as explained in ionic blog)
Maybe it could be related to provisional headers chrome bug. But, how can I be sure?
What puzzles my is that it happens only sometimes and not always. (and there are no errors in the backend)
The only workaround I have found in the devise_token_auth documentation is change config.change_headers_on_each_request to false avoiding in this way the regeneration of the token.
But I don't like this solution because I think it hides the real problem in an insecure way instead of solving the token loss. Any suggestion?
Kindly, please check this thing:
Version: which version of this gem (and ng-token-auth, jToker or Angular2-Token if applicable) are you using?
Request and response headers: these can be found in the "Network" tab of your browser's web inspector.
Rails Stacktrace: this can be found in the log/development.log of your API.
Environmental Info: How is your application different from the reference implementation?
This may include (but is not limited to) the following details:
Routes: are you using some crazy namespace, scope, or constraint?
Gems: are you using MongoDB, Grape, RailsApi, ActiveAdmin, etc.?
Custom Overrides: what have you done in terms of [custom controller overrides]
5?
Custom Frontend: are you using ng-token-auth, jToker, Angular2-
Token, or something else?
I want to disable CSRF guards in tomcat. I don't know how to allow the back, page refresh button to be functional. For the time being, i just want to disable everything related to csrf. For this purpose there is one file Owasp.CsrfGuard.Properties file. There are following properties:
org.owasp.csrfguard.TokenName=OWASP_CSRFTOKEN
org.owasp.csrfguard.TokenLength=32
org.owasp.csrfguard.PRNG=SHA1PRNG
org.owasp.csrfguard.Logger=org.owasp.csrfguard.log.ConsoleLogger
org.owasp.csrfguard.NewTokenLandingPage=PYEntry.jsp
org.owasp.csrfguard.action.Log=org.owasp.csrfguard.action.Log
org.owasp.csrfguard.action.Log.Message=potential cross-site request forgery (CSRF) attack thwarted (user:%user%, ip:%remote_ip%, uri:%request_uri%, error:%exception_message%)
org.owasp.csrfguard.unprotected.QualificationPage=/pondicheryJan30/qualification.do
org.owasp.csrfguard.unprotected.PersonalPage=/pondicheryJan30/personal.do
org.owasp.csrfguard.unprotected.DownloadResume=/pondicheryJan30/DownloadResumeAction.do
org.owasp.csrfguard.unprotected.allotUpdatePage=/pondicheryJan30/allotUpdate.do
org.owasp.csrfguard.unprotected.PersonalEditPage=/pondicheryJan30/personalEdit.do
org.owasp.csrfguard.action.Redirect=org.owasp.csrfguard.action.Redirect
org.owasp.csrfguard.action.Redirect.Page=globalerror.jsp
I know this is old but for anyone looking for a solution, please try the following.
Add the following property
org.owasp.csrfguard.Enabled=false
Also try setting these properties explicitly to not perform per page tokens and rotate tokens per request. These should be disabled by default. but I am suggesting so that those possibilities are mitigated.
org.owasp.csrfguard.TokenPerPage=false
org.owasp.csrfguard.TokenPerPagePrecreate=false
org.owasp.csrfguard.Rotate=false
Rotating tokens typically results in back and forward navigation issues as the saved link tokens have already expired.
This is CSRF Guard specially used for preventing Cross Site Request Forgery.
If you want to disable Csrf Guard.
Goto your web.xml file and remove or comment csrf and XSS filter from web.xml