[Esapi-user] ESAPI ClickjackFilter and Spring 3 MVC

Kevin W. Wall kevin.w.wall at gmail.com
Tue Jan 28 04:59:31 UTC 2014


On Mon, Jan 27, 2014 at 5:20 PM, Michael Weber
<michael.weber35 at gmail.com> wrote:
> I am working on implementing the ESAPI ClickjackFilter using a Spring 3 MVC
> application. However, the filter does not add the header even though the
> call is being made. See the following code from the ESAPI ClickjackFilter:
>
>                public void doFilter(ServletRequest request, ServletResponse
> response, FilterChain chain) throws IOException, ServletException
>
>                {
>
> HttpServletResponse res = (HttpServletResponse)response;
>
> chain.doFilter(request, response);
>
> res.addHeader("X-FRAME-OPTIONS", mode );
>
>                }
>

What other filter (or specifically output filters) do you have
getting invoked before the ESAPI ClickjackFilter?

> I created a local copy of the ESAPI ClickjackFilter and modified my local
> version to verify the header will not add after the "doFilter" call returns
> from spring and it does not. I verified that that Spring had already
> committed the HTTP Response which is why the header cannot be added. I also
> verified that if the header is added before the "doFilter" call then the
> header is added successfully. I am emailing to ask if anyone knows a way to
> make the ESAPI ClickjackFilter work before I recommend using a custom filter
> or spring interceptor? Any help is appreciated.

As I mentioned, I'd recommend that you simply alter the order of your
various servlet filters so that the ClickjackingFilter is at least the
first output servlet filter in the chain.

But I don't recommend making the change that you did, at least in the
manner that you seemed to have tried it. Generally, if you want an output
servlet filter to do something that affects response headers, you should
modify those filters AFTER the call to chain.doFilter().

>From <http://docs.oracle.com/javaee/5/api/javax/servlet/Filter.html#doFilter%28javax.servlet.ServletRequest,%20javax.servlet.ServletResponse,%20javax.servlet.FilterChain%29>:

  A typical implementation of this method would follow the following pattern:-
  1. Examine the request
  2. Optionally wrap the request object with a custom implementation
to filter content or headers for input filtering
  3. Optionally wrap the response object with a custom implementation
to filter content or headers for output filtering
  4. a) Either invoke the next entity in the chain using the
FilterChain object (chain.doFilter()),
  4. b) or not pass on the request/response pair to the next entity in
the filter chain to block the request processing
  5. Directly set headers on the response after invocation of the next
entity in the filter chain.

The ESAPI ClickjackFilter adds the filter at step 5 above. You may be able to
wrap the response header and padd the wrapped request into chain.doFilter().
That is, something like this:

    public void doFilter(ServletRequest request,
                         ServletResponse response,
                         FilterChain chain)
        throws IOException, ServletException
    {
        HttpServletResponse wrappedResp = new
HttpServletResponseWrapper( (HttpServletResponse)response );
        wrappedResp.addHeader("X-FRAME-OPTIONS", mode );
        chain.doFilter(request, wrappedResp);
    }

which takes the approach for step #3 above.

This likely has more chance of succeeding, but is not guaranteed.
The reason is that if an earlier servlet filter has "committed"
the output, either by writting some output to response.getWriter()
or by adding a Content-Length response header, it probably won't work.
(You might be able to work around the latter, by trying to rewrite
the Content-Length, but that would be a bit more complicated.)
In such cases, the only recourse I've seen is to reorder the
servlet filters.

Anyway, hope this helps,
-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.


More information about the Esapi-user mailing list