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 > >
