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: JAVA -tomcat- Request header is too large
Amit, On 12/11/23 11:32, Amit Pande wrote: Mark, Chris, What request ID we're referring to here? Perhaps, I missed some documentation? How do we enable it? Request-id is available in Tomcat 11.0 and 10.1 at the moment. Are you using either of those? I'm not seeing any documentation in the AccessLogValve for reporting that value anywhere... -chris -Original Message- From: Mark Thomas Sent: Monday, December 11, 2023 3:06 AM To: users@tomcat.apache.org Subject: Re: JAVA -tomcat- Request header is too large CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. On 08/12/2023 22:01, Christopher Schultz wrote: Are request-ids always allocated, or only if they are "enabled"? Always allocated. I think adding the request-id to this exception detail message might be helpful, even if the request-id hasn't been enabled in the access-log. WDYT? Good point. More widely, we should probably be adding the request ID to every request related error message. Mark - 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 - 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: Should allowHostHeaderMismatch be case sensitive
On 11/12/2023 17:08, David Cleary wrote: Just want to check if this is by design. The above property default was changed to better secure the default configuration. We started having some tests fail due to this. In our scenario ( as shown below ), the Host header value in the HTTP request is case-sensitive difference compared to the Request Line, and it's crucial that Tomcat, our web server, does not block or reject requests based on variations in the letter case within this header. Request Line: GET http://HZN-OE-A079:8080 HTTP/1.1 Host header: hzn-oe-a079:8080 Just want to confirm that this property, now with a default of false, is supposed to reject requests based on the case of the host name. David, Host names are case insensitive so I can see the argument for making this comparison in a case insensitive manner. However, the language in RFC 9112, section 3.2 is: A client MUST send a Host header field (Section 7.2 of [HTTP]) in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 4.2 of [HTTP]). The key word for me in the above is identical. We probably need to go back to the HTTP working group and clarify whether then intention was for that "identical" to be in a case sensitive or insensitive manner. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Should allowHostHeaderMismatch be case sensitive
Just want to check if this is by design. The above property default was changed to better secure the default configuration. We started having some tests fail due to this. In our scenario ( as shown below ), the Host header value in the HTTP request is case-sensitive difference compared to the Request Line, and it's crucial that Tomcat, our web server, does not block or reject requests based on variations in the letter case within this header. Request Line: GET http://HZN-OE-A079:8080 HTTP/1.1 Host header: hzn-oe-a079:8080 Just want to confirm that this property, now with a default of false, is supposed to reject requests based on the case of the host name. Thanks David Cleary Progress
RE: JAVA -tomcat- Request header is too large
Mark, Chris, What request ID we're referring to here? Perhaps, I missed some documentation? How do we enable it? Thanks, Amit -Original Message- From: Mark Thomas Sent: Monday, December 11, 2023 3:06 AM To: users@tomcat.apache.org Subject: Re: JAVA -tomcat- Request header is too large CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. On 08/12/2023 22:01, Christopher Schultz wrote: > Are request-ids always allocated, or only if they are "enabled"? Always allocated. > I think adding the request-id to this exception detail message might > be helpful, even if the request-id hasn't been enabled in the access-log. > > WDYT? Good point. More widely, we should probably be adding the request ID to every request related error message. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JAVA -tomcat- Request header is too large
On 08/12/2023 22:01, Christopher Schultz wrote: Are request-ids always allocated, or only if they are "enabled"? Always allocated. I think adding the request-id to this exception detail message might be helpful, even if the request-id hasn't been enabled in the access-log. WDYT? Good point. More widely, we should probably be adding the request ID to every request related error message. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
