ср, 15 мар. 2023 г. в 13:29, Konstantin Kolinko <knst.koli...@gmail.com>:
>
> ср, 15 мар. 2023 г. в 13:15, Konstantin Kolinko <knst.koli...@gmail.com>:
> >
> > ср, 15 мар. 2023 г. в 12:07, Mark Thomas <ma...@apache.org>:
> > >
> > > On 14/03/2023 21:13, Christopher Schultz wrote:
> > > > Mark,
> > > >
> > > > On 3/14/23 13:57, Mark Thomas wrote:
> > > >> On 09/03/2023 14:23, Christopher Schultz wrote:
> > > >>> Mark,
> > > > >
> > > > > [....]
> > > >
> > > > I would go for a 1000 limit for all currently-supported versions. It's
> > > > *very* easy to raise the limit if it interferes with a specific
> > > > application's functions.
> > > >
> > > > I *would* add an entry in the "notable changes" for each release e.g.
> > > > https://tomcat.apache.org/migration-10.1.html#Tomcat_10.1.x_noteable_changes
> > >
> > > Makes sense.
> > >
> > > I'll do that.
> >
> > -1 unless the behaviour of "silently dropping extra parameters" is
> > changed as well.
> >
> > Silent loss of data is not what I want to see in production.
> >
> > Documentation [1] says "Request parameters beyond this limit will be
> > ignored."
> > [1] https://tomcat.apache.org/tomcat-8.5-doc/config/http.html
> >
> > More details shortly.
>
> First, some notes regarding the source code.
>
> (1) The limit is enforced in
> org.apache.tomcat.util.http.Parameters#addParameter().
>
> It throws an IllegalStateException which is either caught and retrown
> later, or caught and swallowed.
>
> (2) I see the following 4 code paths and cases:
>
> [....]
>
> Proposals shortly.
Additional notes:
(4) In general, there are the following kinds of errors:
- decoding errors (format errors),
- hitting limits (such as max parameter count),
- i/o errors (client disconnect).
Looking at org.apache.tomcat.util.http.Parameters.FailReason (used by
FailedRequestFilter), it is
public enum FailReason {
CLIENT_DISCONNECT,
MULTIPART_CONFIG_INVALID,
INVALID_CONTENT_TYPE,
IO_ERROR,
NO_NAME,
POST_TOO_LARGE,
REQUEST_BODY_INCOMPLETE,
TOO_MANY_PARAMETERS,
UNKNOWN,
URL_DECODING
}
(5) Skipping parameters due to decoding errors has potential for abuse,
similar to a known trick used by phishers,
combining a well-known site name in an URL with junk. E.g.
http://www.microsoft.com.blabla.phisher.site
http://www.microsoft....@blabla.phisher.site
E.g.
http://foo.bar?par1=...&par2=safety
and one is able to trigger ignoring "par2", it may be abused.
Proposals:
1. I think that maxParameterCount would better be configured per-Context.
The count of parameters is a property of a specific web application.
2. I wonder if we can make handling of the errors configurable.
I think that the following options are possible:
a) Drop parameters that exceeded the limit, or failed to decode.
b) If there is any error, ignore all parameters and behave as if none
were provided.
c) Blow up by throwing a RuntimeException for any call to
Request.getParameter() methods.
It may be an IllegalStateException.
My first thought was to go with c). I know that it contradicts with
Servlet API JavaDoc, but if it is configurable then it is a possible
option. I suppose that a web application should have error handling
configured and should be able to deal with errors.
If we go with c), it requires adding try/catch to safeguard
getParameter() calls in the following classes of Tomcat:
- org.apache.catalina.filters.FailedRequestFilter
- org.apache.catalina.valves.ExtendedAccessLogValve
(The ExtendedAccessLogValve can be configured to log the value of a parameter.)
3. I propose to change the default behaviour to b), "ignoring all parameters".
The loss of data will be clearly visible to the applications. It would
not go unnoted.
Even if one has not configured a FailedRequestFilter (or implemented
similar login in their own way) in their web application.
In case if no web application is matched to a request (no Context
configured), ignoring all parameters is a good default, as they won't
be processed.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
