Re: Improve logging in org.apache.catalina.filters.RestCsrfPreventionFilter ?
Hi Chris, Thanks a lot for the hints! Here is my PR: https://github.com/apache/tomcat/pull/452 Best Regards, Polina On Sat, Aug 28, 2021 at 12:52 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > Polina, > > On 8/26/21 10:48, Polina Georgieva wrote: > > Currently the RestCsrfPreventionFilter is responding with 403 response > when > > the csrf token sent in the request is different from the one stored in > the > > session. > > > > However except the 403 response code visible in the http access log file, > > there’s no indication what happened and why is the error response. > > > > So I think introducing some logs in this filter would be beneficial at > > least from two points of view: > > > > 1. Troubleshooting > > > > It would be easier to troubleshoot problems with clients that did not > > integrate with the csrf prevention mechanism properly or could give more > > clues for other situations - for example cases of session invalidation > > (done by other filter for example) before the request reaches the filter. > > Currently such requests are also responded with 403 though the client > seems > > to have sent valid session cookie and csrf token. That’s why I believe > it > > would be of great help to add log(s) stating: > > > > - if the requested session is found > > - if there’s token stored in it > > - if there’s token and session cookie sent in the request > > > > without revealing their actual values or other security sensitive data. > > > > And this information could be logged only in cases of 403 responses, i.e. > > would appear only when needed. > > > > 1. Improve identifying/tracking security related incidents > > > > According to OWASP guidelines it’s recommended to have probable malicious > > attacks indicated in the logs to better identify security incidents. For > > more details please refer to [1]. > > > > > > > > If you agree with these ideas, I’ll be happy to propose a patch? > > This sounds like a great idea. The RestCsrfPreventionListener and its > superclass CsrfPreventionListenerBase both have access to a log object > via the getLogger() method. It would be trivial to: > > 1. Add logging for whatever situation you'd like to log > 2. Configure a logger to direct the output of the CSRF failures wherever > you'd like > > So I think you don't need to worry too much about the logging > *mechanism* but instead simply add calls to the existing logger. > > I was surprised to see *zero* logging in these classes, and adding such > logging would certainly be a welcome improvement. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Improve logging in org.apache.catalina.filters.RestCsrfPreventionFilter ?
Hello, Currently the RestCsrfPreventionFilter is responding with 403 response when the csrf token sent in the request is different from the one stored in the session. However except the 403 response code visible in the http access log file, there’s no indication what happened and why is the error response. So I think introducing some logs in this filter would be beneficial at least from two points of view: 1. Troubleshooting It would be easier to troubleshoot problems with clients that did not integrate with the csrf prevention mechanism properly or could give more clues for other situations - for example cases of session invalidation (done by other filter for example) before the request reaches the filter. Currently such requests are also responded with 403 though the client seems to have sent valid session cookie and csrf token. That’s why I believe it would be of great help to add log(s) stating: - if the requested session is found - if there’s token stored in it - if there’s token and session cookie sent in the request without revealing their actual values or other security sensitive data. And this information could be logged only in cases of 403 responses, i.e. would appear only when needed. 1. Improve identifying/tracking security related incidents According to OWASP guidelines it’s recommended to have probable malicious attacks indicated in the logs to better identify security incidents. For more details please refer to [1]. If you agree with these ideas, I’ll be happy to propose a patch? Best Regards, Polina [1] https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html#which-events-to-log
Re: Extensibility of LegacyCookieProcessor?
Hi Chris, > The SameSite attribute should be ignored by browsers that do not support it. Which browser are you trying to work-around? You can find more information about the incompatible browsers here: https://www.chromium.org/updates/same-site/incompatible-clients >The newer cookie parser is much more strict. Can you be more specific about what you need? Thanks for the clarification as this was not clear from the documentation. We’ve been using the LegacyCookieProcessor quite some time and the switch to the other processor might be a bit disruptive for our customers but we’ll consider it for our next major version. Meanwhile do you think LegacyCookieProcessor could be changed to non final? Best Regards, Polina On Wed, Jan 20, 2021 at 11:45 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Polina, > > On 1/20/21 04:24, Polina Georgieva wrote: > >> I'm curious: what customization do you need, here? > > > > We’d like to override the generateHeader(Cookie cookie, > > HttpServletRequest request) because we need to centrally handle the > > addition of the sameSite cookie attribute of the session cookie as > > some old browser versions do not support the sameSite cookie > > attribute. For them the adding of this attribute should be skipped. > > The SameSite attribute should be ignored by browsers that do not support > it. Which browser are you trying to work-around? > > >> Why do you need the legacy cookie processor? > > > > We use the LegacyCookieProcessor as it is with more strict > > interpretation of the cookie specifications and provides additional > > configurations if needed. > > The newer cookie parser is much more strict. Can you be more specific > about what you need? > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Extensibility of LegacyCookieProcessor?
Hi Chris, >I'm curious: what customization do you need, here? We’d like to override the generateHeader(Cookie cookie, HttpServletRequest request) because we need to centrally handle the addition of the sameSite cookie attribute of the session cookie as some old browser versions do not support the sameSite cookie attribute. For them the adding of this attribute should be skipped. >Why do you need the legacy cookie processor? We use the LegacyCookieProcessor as it is with more strict interpretation of the cookie specifications and provides additional configurations if needed. Thanks and regards, Polina
Extensibility of LegacyCookieProcessor?
Hello, On our Tomcat 8 we are currently using org.apache.tomcat.util.http.LegacyCookieProcessor and we need to override its method generateHeader(Cookie cookie, HttpServletRequest request) to handle sameSite cookie attribute in a custom way. However the LegacyCookieProcessor class is final (not extensible). So would you please consider making LegacyCookieProcessor class extensible just like the other available cookie processor - org.apache.tomcat.util.http.Rfc6265CookieProcessor? Thanks and regards, Polina
Apache Tomcat Native Library - compatibility clarification needed?
Hi all, Would you please clarify the compatibility restrictions (if any) between the Apache Tomcat Native Lib and its dependencies on one hand and between Apache Tomcat server and the native lib. My questions are based on the information available here: http://tomcat.apache.org/native-doc/ 1) Is it possible (or at all advisable) to build the tc-native once and then use it on a system that is not necessarily with the same versions of dependencies or JVM as the ones it was built with? Or for productive systems it is recommend always to compile on the actual system that the lib will be running on. I’m specifically interested for Linux environment. 2) Are there strict requirements for the dependencies versions, meaning Tomcat Native Lib version X works only with APR version Y, OpenSSL version Z, etc. ? 3) Are there any strict compatibility mapping between the native lib version and the Tomcat server version? In other words could every Tomcat version work smoothly with the latest tc-native version? Thanks a lot! Regards, Polina
