[undertow-dev] Equivalents to Tomcat/JBossWeb valves and options

[James Livingston]

Hi,

A few weeks ago on jboss-as7-dev, Undertow compatibility with Tomcat
valves and -D options was briefly mentioned. Direct compatibility is a
different topic, but I think it is important to make sure that Undertow
can cover the reasons people are using some of those Tomcat options.

I've done some analysis on the JBoss support cases Red Hat deals with
and our knowledge base, and had a bit of a look over the community
forums. I looked at the forums less since it's less structured data but
what people mention there seems consistent with the the RH support cases.


I'm sorry this post is as long as it is, but hopefully what I've found
will help make sure we think about some cases people may run into using
Undertow, and remind us of a few lessons to learn from previous
Tomcat/JBossWeb bugs.



The most common valves we see people add are the RewriteValve,
RequestDumperValve and AccessLogValve. UNDERTOW-12 and UNDERTOW-17 are
already filed for equivalents to the first two. I can't see any code or
open JIRA issues for access logging, which I imagine people will want.


The most commonly used Tomcat -D option is
org.apache.catalina.STRICT_SERVLET_COMPLIANCE=false. When it's
discussed, it always seems to be added for the effect of not enforcing
"any wrapped request or response object passed to an application
dispatcher will be checked to ensure that it has wrapped the original
request or response. (SRV.8.2 / SRV.14.2.5.1)". Undertow enforces that
clause.

A quick search for "ApplicationDispatcher.checkSameObjects" shows people
running into this all over the place. Including
https://issues.jboss.org/browse/RESTEASY-745 (which has a work-around).
Unfortunately a reasonable number of libraries have had or still have
bugs where their wrappers don't derive from the spec one, and it only
break when someone tries to pass it to the dispatcher.


There are a few uses of
org.apache.tomcat.util.http.Parameters.MAX_COUNT, that adjusts the
arbitrary limit on the parameter count which was added to prevent DoS
attacks using hash collisions. Looking at the code, there appear to be
several places where Undertow could suffer similar DoS attacks where
client data is used as HashMap keys: CookieHandler,
HttpServletRequestImpl.getParameterMap() and so on.

Two important things here: what protection does/will Undertow have
against those attacks (such as a limit on the number of parameters, and
is there a way of changing the arbitrary limit. It's not the best idea
to do that, but I've seen at least two people saying they have >2000
hidden parameters in some of their forms.


There are a few options that get used a bit for session cookies. You can
change the cookie name from JSESSIONID on a per-webapp basis, but Tomcat
has a org.apache.catalina.JSESSIONID option to set it globally. This is
probably more of a WildFly integration thing, but is there a plan to
allow it to be changed globally?

org.apache.tomcat.util.http.ServerCookie.ALLOW_EQUALS_IN_VALUE is used
occasionally to allow un-escaped equals signs in the cookie value.

org.apache.tomcat.util.http.ServerCookie.VERSION_SWITCH=false is used
occasionally to not switch v0 cookies to v1 cookies, to deal with some
broken clients. See JBWEB-196.


org.apache.catalina.connector.Response.REWRITE_CONTEXT_CHECK=false is
used primarily in WebLogic migrations. See JBWEB-181, but apparently
when encodeRedirectURL() adds the sessionId to the url, WL will do that
for URLs belonging to other contexts. I'm not sure if this is still
useful.

By default Tomcat un-escapes %2F in a URL to / to prevent security flaws
by something incorrectly doing it later.
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH can be used to
disable that, for example if you want to put %2F inside a path component
of a REST service. Should Undertow to the same automatic un-escaping,
and if so have a way not to do it?

The final option that I've seen used a non-trivial number of times is
org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER. Jasper has
re-sizable buffers which are pooled for performance but may need to grow
arbitrarily large to render some JSPs. By default the enlarged buffers
are kept in the pool like normal ones, which means a bad JSP render
consuming hundreds of mb will not free the extra memory when it
finishes. This option causes it to shrink the buffers back down after
they're finished being used. The moral for Undertow here is if you have
resizable buffers and they get pooled, make sure the is a limit.


-- 
James "Doc" Livingston
JBoss Support Engineering Group