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
