> 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?
Use an Origin based protection? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
