You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Polina Georgieva <po...@gmail.com> on 2021/08/26 14:48:49 UTC
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: Improve logging in
org.apache.catalina.filters.RestCsrfPreventionFilter ?
Posted by Jalaj Asher <ja...@eclinicalworks.com>.
That will be a great enhancement to have.
Regards
Jalaj P Asher
-----Original Message-----
From: Polina Georgieva <po...@gmail.com>
Sent: Thursday, August 26, 2021 10:49 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Improve logging in org.apache.catalina.filters.RestCsrfPreventionFilter ?
[You don't often get email from poli.m.georgieva@gmail.com. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.]
Attention! - This email has originated from an External Source outside of eClinicalWorks. Always use caution when opening attachments, clicking links, or when responding to this email. If you feel this is a phishing scam, please use the Phish Alert Report button in Outlook.
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcheatsheetseries.owasp.org%2Fcheatsheets%2FLogging_Cheat_Sheet.html%23which-events-to-log&data=04%7C01%7Cjalaj.asher%40eclinicalworks.com%7C6cc1405176314999ce0d08d968a0af18%7C7ce747e48f6d4e0697efa9b76a063808%7C1%7C0%7C637655862166690290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZKENhmdqWfpNGijcGbHz2usa%2FJzJiq%2FNUtvtN91%2FDBA%3D&reserved=0
CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains confidential information belonging to the sender that is legally privileged and proprietary and may be subject to protection under the law, including the Health Insurance Portability and Accountability Act (HIPAA). If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
CONFIDENTIALITY NOTICE TO RECIPIENT: This transmission contains confidential information belonging to the sender that is legally privileged and proprietary and may be subject to protection under the law, including the Health Insurance Portability and Accountability Act (HIPAA). If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Improve logging in org.apache.catalina.filters.RestCsrfPreventionFilter
?
Posted by Polina Georgieva <po...@gmail.com>.
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 <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Improve logging in
org.apache.catalina.filters.RestCsrfPreventionFilter ?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org