> Mark, > > On 11/21/19 04:00, Mark Thomas wrote: >>> 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? > > So something like CORS? I haven't dived into CORS, yet. Is it fair to > say that CSRF might be a simpler and less powerful standard while CORS > is a replacement for it? Or do they serve different use-cases?
Different use cases. Origin based CSRF protection is considered less effective than token based (I'm only going on what I read - I haven't dug into the whys) but it should be sufficient for the scenario you describe. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
