Hi, Recently we had a bug report at Apache Wicket about this problem [1] - when the user agent sends a request with wrong URL encoding (in the query string) then Wicket throws an exception which was not easy to be handled by the application. The exception was 1) logged by the web container and 2) error code 500 returned. And 1) was the biggest problem - an attacker can easily flood the application logs by just issuing a request with bad url encoding. I've checked how Jetty and Tomcat react on such requests with a plain Servlet and the results were: -- jetty - throw an exception + error code 400 -- tomcat - fully ignore the bad url encoding
I've thought that Tomcat intentionally behaves like this to prevent the problem above. Wicket uses custom UrlDecoder implementation so it was easy to change the behavior. Now Wicket logs an INFO message and drops the badly url encoded entity. This way the application developers have better control on handling this type of error - they can ignore it completely by configuring their preferred logging library or log it in separate (rotating) log file. 1. https://issues.apache.org/jira/browse/WICKET-4803 On Fri, Mar 1, 2013 at 10:36 PM, Mark Thomas <ma...@apache.org> wrote: > Due to bug 54602 [1] I have been writing some test cases to examine how we > handle invalid bytes sequences in URIs. > > My expectation was: > - valid byte sequence for expected encoding -> 200 (assuming no other > problems) > - invalid byte sequence for expected encoding -> 400 > - partial byte sequence for expected encoding -> 400 > > However, that isn't what happens and I currently believe that this should > happen. The purpose of this e-mail is, therefore, to get agreement on what > should happen. > > There are multiple moving parts here so forgive me if this e-mail gets a > little long. There are multiple decisions and I expect some to be less > contentious than others. > > These issues were observed with UTF-8. Other encodings may have similar > issues. May aim is to get a consistent approach regardless of encoding. > > Issue 1: URI ends with partial byte sequence > Currently the partial byte sequences are ignored. I think the B2CConverter > should throw an Exception if the full input (i.e. when endOfInput == true) > ends in with a partial byte sequence > > Issue 2: URI ends with invalid byte sequence > This appears to be a bug in the UTF-8 decoder provided by the JVM. [1] has > provided one set of input bytes that triggers this. Currently the invalid > data is ignored. I think that B2CConverter should throw an Exception as > soon as it can determine that input is invalid. This would require: > - switching to the Harmony based UTF-8 decoder used by WebSocket > - further testing of the JRE and Harmony UTF-8 decoders to check for other > potential issues > > Issue 3: Fall back to 'ASCII' > If the conversion fails (i.e. throws an exception for any reason) [2], the > CoyoteAdapter attempts to decode the provided URI using 'ASCII' rather than > the configured connector encoding. I say 'ASCII" because the comments say > ASCII but it is actually ISO-8859-1. > I don't believe it appropriate to fall back to anything here. The fall > back code has been present since conversion support was added but I can't > think of any scenario where this stands any chance of working reliably. I > would like to remove this fall back code. > > I would like to make these changes in trunk and 7.0.x. > > I expect to have a similar discussion about request bodies once URIs are > resolved where I have essentially the same view - a decoding error should > lead to a request failure. > > Thoughts? > > Mark > > > [1] > https://issues.apache.org/**bugzilla/show_bug.cgi?id=54602<https://issues.apache.org/bugzilla/show_bug.cgi?id=54602> > [2] http://svn.apache.org/viewvc/**tomcat/trunk/java/org/apache/** > catalina/connector/**CoyoteAdapter.java?view=**annotate<http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?view=annotate>(line > ~1054) > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@tomcat.apache.**org<dev-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com <http://jweekend.com/>
