ср, 20 нояб. 2019 г. в 23:36, Christopher Schultz <ch...@christopherschultz.net>: > > All, > > The servlet spec defines the workflow for form-based authentication: > if the client requests a protected resource, an authorization check is > performed. If the user is unauthenticated, the login form is shown. > Successful login allows the user to be sent to the > originally-requested resource. > > This works great to allow users to pick-up workflows where they > left-off in the case of session timeout: once authenticated, the user > is sent back to the page they were trying to get to originally, > including a potential re-POST of form data, for example. > > With the CSRF prevention filter in-place, this then causes an error > (well, CSRF policy violation == forbidden response) because the nonce > originally added to the request's query string no longer matches a > valid nonce on the server. > > This can be considered both good and bad behavior. Good: if handed a > forged nonce from an attacker, the nonce will not be valid if the user > is asked to login. Session-fixation attacks could get an attacker > around this. Bad: it completely and totally breaks workflow-resumption. > > I'm looking for a way around this because I *really* like the fact > that you can resume a workflow after re-authenticating. > > (I happen to be using a 3rd-party authentication and authorization > library implemented as a Filter and I'm having some issues with > getting that working as well, but the problem exists with the stock > Tomcat authenticators.) > > Is there a safe way to implement workflow-resumption in the presence > of the CSRF prevention filter? Or even under *any* CSRF scheme?
1. I think you need to look at specific examples. E.g. with Tomcat Manager web application, do you want to resume such an operation? Possible scenarios: 1) The operation was triggered from a stale page E.g. the top page was open for more than 30 minutes and one tries to stop a web application, or to upload a new one. 2) The operation was triggered by following a bookmark in a browser 3) The operation was triggered by following a link prepared by an attacker 4) An attacker triggers a link silently, e.g. using it as a src address for an image. 2. I think that resuming an operation a) needs some clear confirmation from a user. b) should be distinct from any other confirmation. E.g. not to be confused with an authentication prompt. c) it should be clear to a user what specific operation is being resumed. So that an attacker (in scenario 3)) cannot trick you into performing a different operation than what you were expecting. 3. I think that a lot can be done with a custom 403 page if there is an indication that the 403 response was triggered by a CSRF filter. At least we can make the 403 page in Tomcat Manager more friendly in case the rejection was caused by CSRF protection. We already have some request attributes that indicate that there was a problem with processing of a request, org.apache.catalina.parameter_parse_failed org.apache.catalina.parameter_parse_failed_reason I use them in configurations for AccessLogValve. Maybe we could introduce similar features for the rejections generated by CsrfPreventionFilter, CorsFilter, RemoteAddrFilter / RemoteAddrValve, so that the cause of rejection could be visible in an access log and so that one could prepare a custom error page. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
