Search code examples
javatomcatservlet-filtersthread-localesapi

ThreadLocal sharing data?

By all means I know the following is not possible, but it is occurring in one of our production environments:

SETUP

  • ESAPI 2.01

  • Main servlet filter setting and removing a current request thread local object:

    try {
    ESAPI.httpUtilities().setCurrentHTTP(request, response);

    // filter logic ...
} catch (Exception e) {
    LOG.error(Logger.SECURITY_FAILURE, "Error in ESAPI "
            + "security filter: " + e.getMessage(), e);
    request.setAttribute("message", e.getMessage());
} finally {
    ESAPI.clearCurrent();
}

all requests pass through this filter, and ESAPI.currentRequest() is used throughout the system.

  • Path A (http://server/path_a/)
    • goes through until it reaches method_a, this method is not accessible from path_b
  • Path B (http://server/path_b)
    • goes through until it reaches method_b, not accessible from path_a

Both of these paths go through the servlet filter (mapping "/*")

One of our error mails that I received suggests that path_a is throwing an error, which in turn initiates the error mail, in the mail code, the current request (via ESAPI.currentRequest()) is enumerated for request info.

PROBLEM

In the error mail, request info from path_a correlates with stacktrace info from method_b, to me this seems impossible as both run in separate threads.

QUESTION

How is this possible? I cannot re-create this locally, are their certain precautions I have to take other than setting and clearing the ThreadLocal? Can this be a problem with tomcat setup? I'm lost.

PS: code from the question has been simplified as the code base is to large for an example

error mail

Solution

  • Reading ESAPI code https://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/reference/DefaultHTTPUtilities.java there are some questionable practices regarding thread local.

    The biggest problem I'd say is it uses InheritableThreadLocal. If thread A spawns a thread B, B will inherit A's thread local value; however, when A then clears the thread local, it doesn't affect B, so B's inherited value will stay. ESAPI probably shouldn't use InheritableThreadLocal.

    I can't say how this may produce the problem you see, without knowing more about threads in your app.