Socket to servlet, through Tomcat

01The full path

Every class named here exists in your installation. Verify with unzip -Z1 lib/catalina.jar 'org/apache/catalina/core/Standard*Valve.class'.

02Where the trust boundary sits

Step 04 is the line. Before it, the request is bytes in a recycled buffer; after it, it is an object graph your code reads. Everything on the far side is attacker-controlled, including fields that feel structural:

Only the last two are genuinely container-derived. X-Forwarded-For is worth dwelling on: it is trusted only if a reverse proxy overwrites it, and only if the application reads it through RemoteIpValve with internalProxies configured. Reading the raw header and taking the first entry is a rate-limit and ACL bypass.

03Three views of the URI

The Servlet specification defines several path accessors with different decoding rules, and the difference is exploitable.

// Filter: looks at the raw URI
if (req.getRequestURI().startsWith("/app/admin/")) {
    requireAdmin(req);          // never matches /app/./admin/ etc.
}
chain.doFilter(req, resp);       // mapper already resolved it to the admin servlet

// Use the container's own decoded, normalised view...
String path = req.getServletPath()
           + (req.getPathInfo() == null ? "" : req.getPathInfo());
if (path.startsWith("/admin/")) requireAdmin(req);

// ...or better: let the container do the matching, declaratively.
<filter-mapping>
  <filter-name>AuthFilter</filter-name>
  <url-pattern>/admin/*</url-pattern>
</filter-mapping>

The one-character gap

/admin/* matches /admin/ and /admin/x. It does not match /admin. If a servlet is also mapped at exactly /admin, it is reachable with the filter skipped entirely. Map both, or map the filter to /* and decide inside it.

04Filter chains and dispatcher types

Ordering

Filter order comes from <filter-mapping> declaration order in web.xml. For @WebFilter annotations the order is not specified — it depends on classpath scan order, which can change between builds.

// Two annotated filters. Which runs first? Undefined.
@WebFilter("/*") public class AuthFilter      implements Filter { … }
@WebFilter("/*") public class AuditLogFilter implements Filter { … }

If ordering matters — and for security filters it always does — declare the mappings in web.xml even when the filter classes use annotations. An annotated filter can have its mapping overridden by a matching <filter-mapping>.

Dispatcher types — the forward bypass

A filter mapping applies to REQUEST only, unless it says otherwise. The other types are FORWARD, INCLUDE, ERROR and ASYNC.

// Auth filter, default dispatcher = REQUEST only
<filter-mapping>
  <filter-name>AuthFilter</filter-name>
  <url-pattern>/admin/*</url-pattern>
</filter-mapping>

// A public servlet forwards based on a parameter:
req.getRequestDispatcher("/admin/" + req.getParameter("view"))
   .forward(req, resp);     // FORWARD -> AuthFilter does NOT run

The request reaches the admin servlet having never passed the authentication filter. The attacker needs no header manipulation — just the public endpoint.

<filter-mapping>
  <filter-name>AuthFilter</filter-name>
  <url-pattern>/admin/*</url-pattern>
  <dispatcher>REQUEST</dispatcher>
  <dispatcher>FORWARD</dispatcher>
  <dispatcher>INCLUDE</dispatcher>
  <dispatcher>ERROR</dispatcher>
</filter-mapping>

And separately: never build a forward target from a parameter. That is path traversal into your own application, and WEB-INF is reachable by forward even though it is not reachable by URL.

// WEB-INF is protected from direct requests but NOT from forwards
req.getRequestDispatcher("/WEB-INF/" + p).forward(req, resp);
// ?p=web.xml renders your deployment descriptor

Forward vs redirect, on one line

forward() is server-side: one HTTP transaction, the browser never learns, the request object is reused, filters re-run only for FORWARD. sendRedirect() is a 302: the browser makes a new request, which runs the full chain from step 01 — and carries no request attributes, which is why data has to go through the session or the query string, and why putting it in the query string is how it ends up in logs and Referer headers.

05Lazy parameter parsing

Request.parseParameters() runs on the first call to getParameter, getParameterMap or getParameterNames — not when the request arrives. It merges the query string with, for application/x-www-form-urlencoded POSTs, the body.

String body = new String(req.getInputStream().readAllBytes());
String name = req.getParameter("name");   // null for a form POST

maxParameterCount

Tomcat 10.1 ships with an explicit guard in conf/server.xml:

$ grep maxParameterCount ~/tools/tomcat/conf/server.xml
               maxParameterCount="1000"

This caps parameters per request. Without it, a POST containing a very large number of keys costs the server hash-map work and memory per request — the HashDoS class of attack. It applies to the merged query-plus-body set, and exceeding it causes the excess to be dropped silently rather than rejected, which can itself be a logic bypass if your code assumes a parameter it does not find is absent rather than discarded.

06One servlet instance, many threads

The container creates one instance of each servlet and calls service() on it from many request threads at once. An instance field is therefore shared mutable state across concurrent users.

public class ProfileServlet extends HttpServlet {
    private User currentUser;          // shared by every thread

    protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
        currentUser = lookup(req.getRemoteUser());
        // another thread can overwrite currentUser between these lines
        resp.getWriter().write(currentUser.getEmail());
    }
}

Under concurrency this serves one user's email to another. It is not a race that needs an attacker to win a narrow window — ordinary load triggers it, and it is reported as an intermittent data-leak bug rather than as a vulnerability.

protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
    User currentUser = lookup(req.getRemoteUser());   // local = per-thread
    resp.getWriter().write(currentUser.getEmail());
}

The review rule: any non-final instance field on a servlet, filter or listener is suspect. final references to immutable or thread-safe objects are fine; everything else needs justification. SingleThreadModel was the old escape hatch and was removed from the specification — do not expect to find it, and do not reach for it.

Struts differs here: it creates a new Action instance per request, so Action fields are safe. Spring controllers are singletons by default, so they have the servlet problem, not the Struts one.

07Security consequences

Watch the pipeline run

# Every request, with the matched servlet and the time taken
$ ./scripts/run/tomcat.sh log

# Breakpoints worth setting when a request goes somewhere unexpected:
org.apache.catalina.connector.CoyoteAdapter#postParseRequest   # normalisation
org.apache.catalina.mapper.Mapper#map                          # target selection
org.apache.catalina.core.ApplicationFilterChain#internalDoFilter # chain contents

Breaking on internalDoFilter and inspecting the filters array answers "did my filter run?" definitively, which no amount of logging inside the filter can — a filter that was never added to the chain cannot log that it was skipped.

Container settings that are findings

# Parse, do not grep — the shipped users are commented out
$ python3 -c "import xml.etree.ElementTree as E,sys;\
print(len(E.parse(sys.argv[1]).getroot().findall('user')),'active users')" \
    ~/tools/tomcat/conf/tomcat-users.xml
0 active users

Error pages leak the stack

Without an <error-page> declaration, Tomcat's default error page renders the exception type, message and sometimes a stack trace, disclosing internal paths, library versions and SQL fragments. Declare catch-all handlers:

<error-page>
  <exception-type>java.lang.Throwable</exception-type>
  <location>/WEB-INF/views/error.jsp</location>
</error-page>
<error-page>
  <error-code>500</error-code>
  <location>/WEB-INF/views/error.jsp</location>
</error-page>

Put the target under WEB-INF so it cannot be requested directly, and remember that the ERROR dispatcher type means your filters will not run for it unless you listed ERROR in the mapping.