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 > >
Re: reporting a problem with LDAP auth to Windows Active Directory with Kerberos using the default spnegoDelegationQop="auth-conf" value for Tomcat 9.0.31 and 9.0.52
Am 2021-09-14 um 18:23 schrieb Tim Miller Dyck: Hello, I wanted to report an issue with Tomcat LDAP user authentication lookups with Tomcat container Kerberos security that I found in our environment when upgrading to version Tomcat 9.0.52 from 9.0.30 and what configuration settings bypassed the problem. Here is our base pre-Tomcat upgrade configuration which was working for both LDAP user authentication and with Kerberos-enabled authentication (e.g. with the Tomcat Manager app). * Tomcat 9.0.30 running on Windows Server 2019 * Microsoft OpenJDK packaging, build 11.0.12+7 64-bit * Tomcat is authenticating users using LDAP queries to Windows Server 2012R2 Active Directory controllers * Tomcat server.xml LDAP configuration: * We have some web apps that use Tomcat container Kerberos authentication, e.g. we configure the Tomcat Manager app WEB-INF\web.xml with SPNEGO Tomcat Manager Application The same configuration was then upgraded to Tomcat 9.0.52 with otherwise all the same overall configuration in place (Kerberos settings, Java settings, cert settings, etc.). The following problem then appeared when trying to log into the Manager app using SPNEGO/Kerberos (and also our web apps using Tomcat container Kerberos authentication). From the Tomcat stderr file: 14-Sep-2021 07:00:32.196 SEVERE [https-jsse-nio-443-exec-10] org.apache.catalina.realm.JNDIRealm.getPrincipal Exception performing authentication javax.naming.NamingException: LDAP connection has been closed; remaining name 'dc=myorg,dc=com' at java.naming/com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133) at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:443) at java.naming/com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:639) at java.naming/com.sun.jndi.ldap.LdapClient.search(LdapClient.java:562) at java.naming/com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2014) at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1873) at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798) at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) at java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267) at org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1610) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1447) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1376) at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2352) at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2288) at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2269) at org.apache.catalina.realm.RealmBase.authenticate(RealmBase.java:504) at org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:365) at org.apache.catalina.realm.LockOutRealm.authenticate(LockOutRealm.java:194) ... In testing with Tomcat ver. 9.0.52, I found the following: * Using Manager with basic auth but still with LDAP user lookups worked - only Kerberos-enabled apps had problems with LDAP auth * Switching our connectionURLs to use non-encrypted LDAP instead of LDAPS caused the problem to be resolved and LDAP+Kerberos to work again so it was something to do with use of SSL with LDAP (but we only want to use LDAPS, of course, for security) * In the LDAP server.xml configuration, as per Tomcat documentation, these two settings are the defaults if not otherwise specified: useDelegatedCredential="true" spnegoDelegationQop="auth-conf " * As per documentation, these settings cause a users's Kerberos credentials to be used for the LDAP lookup (if Kerberos credentials are available to Tomcat) instead of the specific LDAP connection username and password in the JNDIRealm configuration. * I tried setting stripRealmForGss="false" (the default is true, where the domain is stripped from the username) - but has the same problem with both true and false settings * I tried adding only the line spnegoDelegationQop="auth" and this caused the problem to be resolved with Kerberos+LDAP working again * The options for spnegoDelegationQop are auth-conf (default, "authentication plus integrity and confidentiality protection"), auth-int ("authentication plus integrity") and auth ("authentication only"). * I also tried auth-int, but this had the same "org.apache.catalina.realm.JNDIRealm.getPrincipal Exception performing authentication" error * I then tested by adding only the line useDelegatedCredential="false" and this also caused the problem to be resolved with Kerberos+LDAP working again
AW: JASPIC AuthConfigProvider packaged with the web application not found
Hello everyone and thanks for the hints. They also work as expected and I can package the provider in the web application . Nevertheless, the Configuration Reference (https://tomcat.apache.org/tomcat-9.0-doc/config/jaspic.html) suggests that you define your own provider in jaspic-providers.xml and Tomcat will then find it. I am really only interested in a separate server auth module (SAM). Since I saw no way in the documentation to pack this into the web application. That's why I tried the way through the provider. As I said, your suggestions work, but there are also a number of additional classes needed to provide the actual SAM. Thank you again Mit vielen Grüßen Matthias Keil -Ursprüngliche Nachricht- Von: Bernd Schatz Gesendet: Freitag, 17. September 2021 09:53 An: users@tomcat.apache.org Betreff: Re: JASPIC AuthConfigProvider packaged with the web application not found Hi Matthias, Am 17.09.21 um 09:39 schrieb bernd.sch...@daimler.com: > From: "Keil, Matthias (ORISA Software GmbH)" > To: users@tomcat.apache.org > Subject: JASPIC AuthConfigProvider packaged with the web application > not found > > I would like to develop an AuthConfigProvider and would like to deploy it > together in a web application. > > The Tomcat 9 configuration reference for the AuthConfigProvider indicates > that "The implementation may be packaged with the web application or in > Tomcat's $ CATALINA_BASE / lib directory." > > The variant with the $ CATALINA_BASE / lib directory works as expected. My > class of the AuthConfigProvider is found and instantiated. > The variant of packing the implementation together with the web application > does not work. In this case I get a java.lang.ClassNotFoundException. [SNIP] You can register it by using a ServletContextListener (or via CDI): AuthConfigFactory factory = AuthConfigFactory.getFactory(); factory.registerConfigProvider(new AuthProvider(), "HttpServlet", null, "TEST"); -- greets Bernd - 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