how is the browser to blame for " defaultMessageType=true&locale=en_US&action=[key:label.edit]"
that url is not generated by a browser but by some software that uses a browser... On Thu, 18 Oct 2018 at 12:55, M. Manna <manme...@gmail.com> 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). > > 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 > > > > > -- Johan Compagner Servoy
