Re: Weird CSRF prevention behavior
Konstantin, On 12/20/23 12:10, Konstantin Kolinko wrote: пт, 1 дек. 2023 г. в 23:27, Christopher Schultz : [...] I build-from-source and launch my custom-build Tomcat with my application in it. No logging. Oh, right... logging.properties. So I add this to my conf/logging.properties file: org.apache.catalina.filters.CsrfPreventionFilter.level = FINEST To be sure there's no funny business, I use "catalina.sh run" and wait for the console log to settle down. I make a few requests. No logs. Hmm. Oh, the ConsoleAppender is set to FINE and not FINEST. java.util.logging.ConsoleHandler.level = FINEST Done. CTRL-C, catalina.sh run. Make some requests. Nothing. Okay maybe the Filter is just ignoring these for some reason. Regarding the logging issue: It is worth to check a) If you have a "logging.properties" file in your class path. I.e. if the web application has its own configuration of logging. (Usually in lib/classes, but in bad cases one may be present in a library jar file.) Thanks for your reply. I actually came to the same conclusion right about the time you were writing this. I had been trying to configure this in CATALINA_BASE/conf/logging.properties and I needed to do it in my application's WEB-INF/classes/logging.properties file. So it's working entirely as expected, now. :) b) What are the values of "java.util.logging.manager" and "java.util.logging.config.file" properties. I.e. whether JULI is used at all. If nothing else, remote debugging should help. ;) I ended up using a remote debugger to poke-around in the runtime Logger object to see what was happening. No amount of configuration changes in conf/logging.properties was making any change to the logger, but fiddling with the in-memory object via debugger would make it do ... something. Then it occurred to me that the configuration was in the wrong place :) -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird CSRF prevention behavior
пт, 1 дек. 2023 г. в 23:27, Christopher Schultz : > > [...] > > I build-from-source and launch my custom-build Tomcat with my > application in it. No logging. Oh, right... logging.properties. So I add > this to my conf/logging.properties file: > > org.apache.catalina.filters.CsrfPreventionFilter.level = FINEST > > To be sure there's no funny business, I use "catalina.sh run" and wait > for the console log to settle down. I make a few requests. No logs. Hmm. > Oh, the ConsoleAppender is set to FINE and not FINEST. > > java.util.logging.ConsoleHandler.level = FINEST > > Done. CTRL-C, catalina.sh run. Make some requests. > > Nothing. Okay maybe the Filter is just ignoring these for some > reason. Regarding the logging issue: It is worth to check a) If you have a "logging.properties" file in your class path. I.e. if the web application has its own configuration of logging. (Usually in lib/classes, but in bad cases one may be present in a library jar file.) b) What are the values of "java.util.logging.manager" and "java.util.logging.config.file" properties. I.e. whether JULI is used at all. If nothing else, remote debugging should help. ;) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Weird CSRF prevention behavior
Chris CS> HTTP POST should not be prohibited unless I'm reading CS> both the code and the CSRF specs incorrectly. cjb> Pretend that it does. How would you solve that? CS> You have to manually add the CSRF token in each CS> in a hidden FORM parameter. It's doable, but it sucks to CS> have to do that across your whole application. Yeah, that would be tedious. In my old JSP days we had a function "htmFormBegin" that we called to auto-populate all the needed hidden fields on every page for every form. (It could have been a tag.) The discipline of using that function instead of hard coding all the forms made changes like that trivial. Ah well. CS> Application B has a feature where we present a web form to the user. CS> It's fairly simple (paraphrasing): CS> CS> cjb> What happens if you cheat? Can you use a redirect from cjb> B to A instead, or will that violate the filter rules? CS> That would be even more complicated. I'm looking for "simple" :) It's too bad the CSRF handling can't be offloaded to the load balancer instead. Or perhaps an exception list could be added to the TC filter. It sounds like, in your case, CSRF *should* be allowed as an exception between your 2 apps, if I understand it correctly. FWIW, even if my suggestions suck, I hope maybe that can provoke to "think outside the box" instead. -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
Re: Weird CSRF prevention behavior
Cris, On 12/11/23 12:48, Berneburg, Cris J. - US wrote: Hi Chris Any ideas? About EITHER issue? Ping. Any ideas? Yeah, and hopefully you won't gag too much. :-P [SNIP] My application is using log4j2, but that library is only used by the application and the JAR file is in WEB-INF/lib/. I wouldn't expect that it would interfere with server-level logging. [...] If anyone can help with logging, maybe I can figure out what's happening in the Filter. Forget using the logging mechanism for now. Many folks have trouble setting it up anyway. Go "bone knives and bear skins" and just use System.out.println (or S.err.p). You are running in the console, right? Fair enough. HTTP POST should not be prohibited unless I'm reading both the code and the CSRF specs incorrectly. Pretend that it does. How would you solve that? You have to manually add the CSRF token in each in a hidden FORM parameter. It's doable, but it sucks to have to do that across your whole application. [SNIP] Application B has a feature where we present a web form to the user. It's fairly simple (paraphrasing): What happens if you cheat? Can you use a redirect from B to A instead, or will that violate the filter rules? That would be even more complicated. I'm looking for "simple" :) -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Weird CSRF prevention behavior
Hi Chris > Any ideas? About EITHER issue? > Ping. Any ideas? Yeah, and hopefully you won't gag too much. :-P [SNIP] > My application is using log4j2, but that library is only used by the > application > and the JAR file is in WEB-INF/lib/. I wouldn't expect that it would interfere > with server-level logging. [...] If anyone can help with logging, maybe I can > figure out what's happening in the Filter. Forget using the logging mechanism for now. Many folks have trouble setting it up anyway. Go "bone knives and bear skins" and just use System.out.println (or S.err.p). You are running in the console, right? > HTTP POST should not be prohibited unless I'm reading both the code and the > CSRF specs incorrectly. Pretend that it does. How would you solve that? [SNIP] > Application B has a feature where we present a web form to the user. > It's fairly simple (paraphrasing): > > > > What happens if you cheat? Can you use a redirect from B to A instead, or will that violate the filter rules? > You'd think a Tomcat committer could figure out how to make logging work. FWIW, by the time I respond to a plea for help, you know you're scraping the bottom of the barrel. ;-) My experience with CsrfPreventionFilter was limited to one small app with a simple setup a few years back. Sorry I don't have anything better for you. P.S.: I still owe you a beer. -- Cris Berneburg CACI Senior Software Engineer Tomcat Newbie This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird CSRF prevention behavior
All,
Ping. Any ideas?
-chris
On 12/1/23 15:26, Christopher Schultz wrote:
All,
I'm experimenting with the CsrfPreventionFilter in Tomcat 8.5. I've had
issues with it in the past so I haven't actually enabled it in any of my
applications, but I'm sufficiently motivated at this point to get it done.
My "application" is actually split up into two applications, each
running in a separate JVM but in the same URL space. I have a
reverse-proxy that figures this all out and it's been working for years.
I don't see why this wouldn't work.
I have enabled CSRF prevention in Application A which is the "primary
application" and the secondary application (Application B) is capable of
mimicking/proxying the csrf token back to Application A.
Application B has a feature where we present a web form to the user.
It's fairly simple (paraphrasing):
When I submit this form, I get an HTTP 403 response. Our application
doesn't send 403 responses. When I remove the CsrfPreventionFilter from
the configuration) by commenting-out the in
WEB-INF/web.xml, I do not get the 403 response and the form submission
is successful. I'm sure that the CSRF token is *NOT* in the POST
request: the browser shows me what is sent and it's not there. I have
hacked the form and added the token, submitted it, and it /works/.
But this is an HTTP POST and should be ignored by the filter.
So I figure I'll enable logging and see what's happening. There isn't
much logging in CsrfPreventionFilter, so I add this line to the
beginning of the skipNonceCheck method:
log.trace("skipNonceCheck(" + request.getMethod() + " " +
request.getRequestURI() + ")");
I build-from-source and launch my custom-build Tomcat with my
application in it. No logging. Oh, right... logging.properties. So I add
this to my conf/logging.properties file:
org.apache.catalina.filters.CsrfPreventionFilter.level = FINEST
To be sure there's no funny business, I use "catalina.sh run" and wait
for the console log to settle down. I make a few requests. No logs. Hmm.
Oh, the ConsoleAppender is set to FINE and not FINEST.
java.util.logging.ConsoleHandler.level = FINEST
Done. CTRL-C, catalina.sh run. Make some requests.
Nothing. Okay maybe the Filter is just ignoring these for some
reason. So I add this line to the beginning of doFilter, before anything
else happens:
log.trace("doFilter(" + request + ")");
Re-build. CTRL-C. catalina.sh run. Make some requests.
Nothing.
The Filter is absolutely running. If I reload a page, the csrf tokens on
all the links are changing. What's going on?
You'd think a Tomcat committer could figure out how to make logging work.
My application is using log4j2, but that library is only used by the
application and the JAR file is in WEB-INF/lib/. I wouldn't expect that
it would interfere with server-level logging.
Any ideas? About EITHER issue? If anyone can help with logging, maybe I
can figure out what's happening in the Filter. If you have any
suggestions about the Filter, I'm al ears. HTTP POST should not be
prohibited unless I'm reading both the code and the CSRF specs incorrectly.
Thanks,
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird CSRF prevention behavior
Lasse,
On 12/1/23 15:45, Lasse Lindqvist wrote:
Well, one thing that could be wrong is that Log4j2 does not have FINE or
FINEST levels. It does have TRACE. If that does not fix things, you could
always change tour log.trace to log.error if you only care about debugging
the original issue.
I'm not expecting to use log4j2 at the server level. I mentioned it was
in the application in case there would be some kind of confusion.
logging.properties, as I understand it, always uses the JULI conventions
for things like log-level spelling.
Thanks,
-chris
pe 1. jouluk. 2023 klo 22.28 Christopher Schultz (
ch...@christopherschultz.net) kirjoitti:
All,
I'm experimenting with the CsrfPreventionFilter in Tomcat 8.5. I've had
issues with it in the past so I haven't actually enabled it in any of my
applications, but I'm sufficiently motivated at this point to get it done.
My "application" is actually split up into two applications, each
running in a separate JVM but in the same URL space. I have a
reverse-proxy that figures this all out and it's been working for years.
I don't see why this wouldn't work.
I have enabled CSRF prevention in Application A which is the "primary
application" and the secondary application (Application B) is capable of
mimicking/proxying the csrf token back to Application A.
Application B has a feature where we present a web form to the user.
It's fairly simple (paraphrasing):
When I submit this form, I get an HTTP 403 response. Our application
doesn't send 403 responses. When I remove the CsrfPreventionFilter from
the configuration) by commenting-out the in
WEB-INF/web.xml, I do not get the 403 response and the form submission
is successful. I'm sure that the CSRF token is *NOT* in the POST
request: the browser shows me what is sent and it's not there. I have
hacked the form and added the token, submitted it, and it /works/.
But this is an HTTP POST and should be ignored by the filter.
So I figure I'll enable logging and see what's happening. There isn't
much logging in CsrfPreventionFilter, so I add this line to the
beginning of the skipNonceCheck method:
log.trace("skipNonceCheck(" + request.getMethod() + " " +
request.getRequestURI() + ")");
I build-from-source and launch my custom-build Tomcat with my
application in it. No logging. Oh, right... logging.properties. So I add
this to my conf/logging.properties file:
org.apache.catalina.filters.CsrfPreventionFilter.level = FINEST
To be sure there's no funny business, I use "catalina.sh run" and wait
for the console log to settle down. I make a few requests. No logs. Hmm.
Oh, the ConsoleAppender is set to FINE and not FINEST.
java.util.logging.ConsoleHandler.level = FINEST
Done. CTRL-C, catalina.sh run. Make some requests.
Nothing. Okay maybe the Filter is just ignoring these for some
reason. So I add this line to the beginning of doFilter, before anything
else happens:
log.trace("doFilter(" + request + ")");
Re-build. CTRL-C. catalina.sh run. Make some requests.
Nothing.
The Filter is absolutely running. If I reload a page, the csrf tokens on
all the links are changing. What's going on?
You'd think a Tomcat committer could figure out how to make logging work.
My application is using log4j2, but that library is only used by the
application and the JAR file is in WEB-INF/lib/. I wouldn't expect that
it would interfere with server-level logging.
Any ideas? About EITHER issue? If anyone can help with logging, maybe I
can figure out what's happening in the Filter. If you have any
suggestions about the Filter, I'm al ears. HTTP POST should not be
prohibited unless I'm reading both the code and the CSRF specs incorrectly.
Thanks,
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird CSRF prevention behavior
Well, one thing that could be wrong is that Log4j2 does not have FINE or
FINEST levels. It does have TRACE. If that does not fix things, you could
always change tour log.trace to log.error if you only care about debugging
the original issue.
pe 1. jouluk. 2023 klo 22.28 Christopher Schultz (
ch...@christopherschultz.net) kirjoitti:
> All,
>
> I'm experimenting with the CsrfPreventionFilter in Tomcat 8.5. I've had
> issues with it in the past so I haven't actually enabled it in any of my
> applications, but I'm sufficiently motivated at this point to get it done.
>
> My "application" is actually split up into two applications, each
> running in a separate JVM but in the same URL space. I have a
> reverse-proxy that figures this all out and it's been working for years.
> I don't see why this wouldn't work.
>
> I have enabled CSRF prevention in Application A which is the "primary
> application" and the secondary application (Application B) is capable of
> mimicking/proxying the csrf token back to Application A.
>
> Application B has a feature where we present a web form to the user.
> It's fairly simple (paraphrasing):
>
>
>
>
>
> When I submit this form, I get an HTTP 403 response. Our application
> doesn't send 403 responses. When I remove the CsrfPreventionFilter from
> the configuration) by commenting-out the in
> WEB-INF/web.xml, I do not get the 403 response and the form submission
> is successful. I'm sure that the CSRF token is *NOT* in the POST
> request: the browser shows me what is sent and it's not there. I have
> hacked the form and added the token, submitted it, and it /works/.
>
> But this is an HTTP POST and should be ignored by the filter.
>
> So I figure I'll enable logging and see what's happening. There isn't
> much logging in CsrfPreventionFilter, so I add this line to the
> beginning of the skipNonceCheck method:
>
> log.trace("skipNonceCheck(" + request.getMethod() + " " +
> request.getRequestURI() + ")");
>
> I build-from-source and launch my custom-build Tomcat with my
> application in it. No logging. Oh, right... logging.properties. So I add
> this to my conf/logging.properties file:
>
> org.apache.catalina.filters.CsrfPreventionFilter.level = FINEST
>
> To be sure there's no funny business, I use "catalina.sh run" and wait
> for the console log to settle down. I make a few requests. No logs. Hmm.
> Oh, the ConsoleAppender is set to FINE and not FINEST.
>
> java.util.logging.ConsoleHandler.level = FINEST
>
> Done. CTRL-C, catalina.sh run. Make some requests.
>
> Nothing. Okay maybe the Filter is just ignoring these for some
> reason. So I add this line to the beginning of doFilter, before anything
> else happens:
>
> log.trace("doFilter(" + request + ")");
>
> Re-build. CTRL-C. catalina.sh run. Make some requests.
>
> Nothing.
>
> The Filter is absolutely running. If I reload a page, the csrf tokens on
> all the links are changing. What's going on?
>
> You'd think a Tomcat committer could figure out how to make logging work.
>
> My application is using log4j2, but that library is only used by the
> application and the JAR file is in WEB-INF/lib/. I wouldn't expect that
> it would interfere with server-level logging.
>
> Any ideas? About EITHER issue? If anyone can help with logging, maybe I
> can figure out what's happening in the Filter. If you have any
> suggestions about the Filter, I'm al ears. HTTP POST should not be
> prohibited unless I'm reading both the code and the CSRF specs incorrectly.
>
> Thanks,
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
