-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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? - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3Vo88ACgkQHPApP6U8 pFjuWxAAirnEimlquVNLUA+yfTT+rsCA+6TFxv0soDDg/ln5F7GX7AsVdnAL3SDZ jPWxBYKsiW+jaPS56DYIawW5foTqy+dHfgawmR8zH4g4IK1tvlBq+yMOJ1zDDPLC 5lcWm2vGXHuFO+/PHo97Yom0r+I7cVOm9V7S5oa8vJtq/YXHGchqKfDzF/10NBAp xNQaQ1FJhEQBjcup9ZWFy51+f5g9F3GmtvAgqdirhCAgr5N+muWbyaUMXkXPqagx HdZhpZNJ1jtiidhE9lAK10wOHz9AtlacLNQker8etg6Bct2QDxbooxHKppdZwQP9 WrtXreE8BNtmDCYKyKIMHKQq4VozO834FMFCMLfDBKE8j4u07ctDnj5GzahEKGTp pr/81Q9bLnH5YeHFFkNeh1uZNpcy7M/NBALvF1cJF0QztRQw6V7I7m7AAsC/AjW6 wKfQh+qhmQzSHQcho8E3kdF5HbU38lNS8hVFFoowwzKKUJXjXWOZ77z2di4tW6ll MQRIpw0oFfDZoVQHDLEp51OyVtrPfhia12NFWrY26H9hBHYXZIDrzbUgNgDsfEJh i9tytiPpl/A0Tmh1yhuKRlZsb29tSDKKEki39G7rz/Usgi64U+vslkA5TWp1YJ2I CSq2mXGhERguTguSC8eg3tXQUsTz/gWFIccC/LALP4caqJYTqfI= =NJaQ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
