On 18/10/18 12:17, Johan Compagner wrote: > 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...
Browsers these days try to be helpful and show the user the un-encoded URI in the address bar but send the encoded version to the server. Personally, that sort of behaviour bugs me as I like to know exactly what is going on - not have the technology perform 'magic' for me under the covers to get stuff to work. But I suspect that is just me. And that is why I do a lot of my testing in this area with telnet. In this instance, the browser should encode the '[' and the ']' but it does not. See this link for how browsers should (as per the RFC) encode characters in the path and query string compared to how they actually behave. https://cwiki.apache.org/confluence/display/TOMCAT/Encoding+and+URIs Mark > > > 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 >>> >>> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
