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
Related
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.
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.
To avoid xss attack, MVC generating some antiforgery token.
But in our project we have Angularjs with web api.
My need is
Do we need antiforgery token to prevent xss attack in Angularjs project with web api?
If we need, how to implement?
The antiforgery token is against cross-site request forgery (CSRF). In very short and somewhat simplified, an attacker may be able to set up his own website, trick your user into visiting that website, and then create a webpage for the user that will make the user's browser post a valid request to your application, something your user did not want to do. The standard protection against this is generating a random token in your application that the attacker won't know and won't be able to send. OWASP has a nice description of CSRF and also a protection cheat sheet. This problem only comes up if authentication info (the session id or access token) is sent automatically by the browser with requests, ie. when it is in a cookie. Otherwise the attack is not possible.
This has nothing to do with cross-site scripting (xss). An attacker may want to inject Javascript into your page when viewed by other users so that he can access data displayed to or stored on the client by victim users. To solve this, you need to encode all output according to its context, or in Angular (and Javascript in general) you need to make sure that you only use bindings that may not create a script node in the page dom but only bind as text. OWASP has a cheat sheet for XSS too.
In case of Angular talking to Web API, you need to take care of CSRF in the Web API code if (and only if) you use cookie-based authentication / sessions. If the access token is stored anywhere else and you have to insert it into each request in code (like for example the token is stored in a Javascript object and added to each request as a request header by jQuery), it's fine and you don't need further protection against CSRF.
If the Web API serves JSON content, it's fine to have unencoded data in JSON responses (obviously this means you should encode data for JSON itself, but standard serializers do that for you, and you don't need to care about presentation at that level). When such data is received in Angular, you need to make sure that you only use safe bindings to actually bind that data to the UI so that Javascript cannot be inserted. Angular is reasonably good at that, but code can still be vulnerable. Also DOM XSS (a form of XSS) is a very common vulnerability in Javascript-heavy applications.
How exactly to implement these is way beyond the scope of an answer here unfortunately. It all depends on the details.
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.
It is common to authenticate to web services using an authorization header which contains a secret token. And since the security of this mechanism depends on the token to be secret care should be taken that this token is not leaked.
There are countless tutorials on the web which explains how such an authorization header can be set using angular and least the ones that I have actually read use an $http interceptor and now one discusses that the token is not leaked.
There are some public and some private APIs out there which can be talked to cross domain thanks to CORS. And obviously I do not want to send my internal authorization tokens on any of those requests.
Some other techniques come to mind such as setting the token manually only on each and every request, but that means lots of duplicate code. The $http server could be wrapped in an $authenticatedHttp service so that it is always appearent from the object used whether it is the authenticated service or the normal one. However the $http service has so many methods to be wrapped.
Is there a better solution?
UPDATE
From the answers I have the impression that my question was not understood. I try it with a more concrete example:
I have a private web page. People have to login with username/password and let's say for simplicity's sake that we use HTTP basic auth, so username/password are bas64 encoded and are transmitted on every request in the HTTP header "Authorization". So far there is no problem.
But there is this great&free weather widget. I can retrieve the current weather information in JSON format from https://myWhateverWeatherService.tld/weather.json. After the login to my private web service I also retrieve the weather information (CORS allows me to do this).
The problem is that even though myWhateverWeatherService.tld does not require any authentication at all, angular's $http service will still append the Authorization header. And I don't trust the guys at myWhateverWeatherService.tld. Maybe they just set up the service so they can steal Authorization token and do lot's of nasty stuff with them.
I need some reliable way to deal with that. I already thought about checking the url with some regex in the interceptor. This is possible, but it is also not to difficult to forget about a certain case that my regex will miss.
The token is always sent through the wire, I guess that is the most vulnerable part of it.
Since the token must always be present on the http header itself, the only way to make the request more secure is to encrypt the whole request, and for that you should use SSL.
If you are concerned about the safety of storing the token on the client machine, you can keep it only on the browser´s memory, without persisting it on a localstorage or something like that. So every time the user closes the browser and open it again, s/he must log in.