You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2019/11/20 20:36:31 UTC
Using CSRF prevention filter with session-timeout workflow resumption
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Using CSRF prevention filter with session-timeout workflow resumption
Posted by Konstantin Kolinko <kn...@gmail.com>.
ср, 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Using CSRF prevention filter with session-timeout workflow
resumption
Posted by Mark Thomas <ma...@apache.org>.
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Using CSRF prevention filter with session-timeout workflow
resumption
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3WsvMACgkQHPApP6U8
pFim4xAAkL2PrvyfhLM1LLAaJry8e12dUDxKamwziiy7jsF/Vp47ZXm/E2HUl4H3
tSrxa14C7/7p2MiNF3nWSxgI6xLUY8nSrSnJP8cok2YenkxGFaSe2z5A1AtPcaLh
hSP+sT4VP0Ddnd968r/iHd2b9Z2RmQZnVT9ZICEsCd2+o/7+hNom5mK+LWqej5qB
4wmhpbLhE/nmEM697yvXw2bbLIMuhxU+aQ0XshKJKKvatmpm2Ncskjbrrov4CCfO
oKYb2sj9yIfObt2B1JGPqokGWOZyoEJ9LXsXE2SZ8VFRo8vgjrkugDUWrNfb5LXY
iigJH+w0sdxu/iKohxmEoEPV4Nst+yW76l9/DcMr7eDaWmpDrXO4AyQU3oc/TP8z
bNcXb4QI5E1WpAT9zbaQiko9Yku+AUmaacu3pOm4npDsUWCrwwz7YoSKazimWVW6
UbGpiiYxB84cf06A0QvY7r/UnvOMYC/VsAV+S6f02FefeNOardIxzx1Rha5PBCtb
67xJK+ceuJcqmnconjcwrqMdPVEeMEkVxS8XbEKHrJmc2K+/6il7RrgYJMMFdeyy
hwJihK8356/FahlrEkyfW77KPE45LphMlU8YyOQkI/FOMi9EFeTvMN/dVOroByrO
ItJy+UxuHv9ZtfYNbIUoZrsvshzF7FRyMavofsWPoIQwH3pSTxw=
=2BcQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Using CSRF prevention filter with session-timeout workflow
resumption
Posted by Mark Thomas <ma...@apache.org>.
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org