I understand. We will use the connector patch for now. But thanks again for sharing your thoughts. And the link to apache Confluence is really helpful!
Thanks, On Thu, 18 Oct 2018 at 12:12, Mark Thomas <ma...@apache.org> wrote: > On 18/10/18 11:55, M. Manna wrote: > > Thanks a bunch Mark. > > > > "The correct fix is to ensure that the user agents are sending > > specification compliant requests." - Do you mean at browser level ? If > so, > > is there any specific browser/update we can use? We've checked a few > > browsers so far (Firefox, Edge, Chrome) and none of them seem to have > this > > option (or we might've missed it). > > The browsers should fix it but I doubt they will. I've seen at least one > browser vendor refuse to accept the current behaviour is a bug and claim > that the browsers are working to their own, different spec. > > Investigations show that each browser has slightly different behaviour. > > https://cwiki.apache.org/confluence/display/TOMCAT/Encoding+and+URIs > > So even if the browsers are following a different spec, they aren't > implementing that one correctly either. > > Sigh. > > Mark > > > > > We are using relaxedQueryChars for now - but would like to understand the > > fix you've proposed above. > > > > On Thu, 18 Oct 2018 at 10:39, Mark Thomas <ma...@apache.org> wrote: > > > >> On 18/10/18 09:52, M. Manna wrote: > >>> Hello, > >>> > >>> We received in error in our application after we have upgraded to > 8.5.34 > >>> > >>> INFO: Error parsing HTTP request header > >>> Note: further occurrences of HTTP header parsing errors will be logged > at > >>> DEBUG level. > >>> java.lang.IllegalArgumentException: Invalid character found in the > >> request > >>> target. The valid characters are defined in RFC 7230 and RFC 3986 > >>> > >>> > >>> The URI we have for this problem has the following param (did work with > >>> 8.5.28) > >>> > >>> defaultMessageType=true&locale=en_US&action=[key:label.edit] > >>> > >>> The issue is the action parameter value. Could someone help me > understand > >>> the following? > >>> > >>> 1) Since the issue didn't happen for 8.5.28 - this means some CVE has > >>> triggered this change to be in place. I am just trying to confirm if > this > >>> is CVE-2016-681 ? If not, could you please let me know which one that > is? > >> > >> The change in request parsing was prompted by CVE-2016-6816. There > >> wasn't a specific attack that prompted this particular change. > >> CVE-2016-6816 was caused by not parsing the request line as per the > >> spec. Therefore, to reduce the risk of future vulnerabilities, we have > >> been tightening up the parsing of the request line. > >> > >>> 2) Apart from refactoring code, is there any recommended corrective > >> action? > >> > >> The correct fix is to ensure that the user agents are sending > >> specification compliant requests. > >> > >> The work-around is to use relaxedPathChars and/or relaxedQueryChars on > >> the Connector. > >> > >> 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 > >
