Talk:CSRF Guard

Should this be in the Countermeasure category and listed on https://www.owasp.org/index.php/Category:Countermeasure?

Absolutely - fixed

Having hard time to get it working with Weblogic 8.1

I tried it out. For some reason, I always get this following statck trace. Could you please help?

java.lang.IllegalStateException: response already committed
        at weblogic.servlet.jsp.JspWriterImpl.clear(JspWriterImpl.java:85)
        at jsp_servlet.__welcome._jspService(__welcome.java:2310)
        at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
        at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run
(ServletStubImpl.java:996)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
pl.java:419)
        at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.ja
va:27)
        at org.owasp.csrf.CSRFGuard.doChain(CSRFGuard.java:96)
        at org.owasp.csrf.CSRFGuard.doFilter(CSRFGuard.java:71)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.ja
va:27)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.run(WebAppServletContext.java:6458)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate
dSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:
118)
        at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe
rvletContext.java:3661)
        at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm
pl.java:2630)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)

This exception occurs when your application tries to write to a response that
has already been committed. In this case, we use a MutableHttpRequest, which
should capture all these writes and allow us to change them later in the filter.
However, there may be a few methods - like addHeader perhaps - that aren't handled
in the MutableHttpRequest. This is just a guess.  Can you share what's happening
in your JSP (welcome.jsp) that causes this error?
--Jeff Williams 17:22, 20 April 2007 (EDT)

In welcome.jsp:

It does the following:

<jsp:forward page="/foo.jsp" />

and this line translates to the following java code by the weblogic jsp compiler:

          if (true) { //forwarding request //[ /welcome.jsp; Line: 289]
            out.clear(); // clear current output buffer //[ /welcome.jsp; Line: 289]
            String __thePage =  //[ /welcome.jsp; Line: 289]
            //[ /foo.jsp; Line: 289]
            "/foo.jsp"; //[ /welcome.jsp; Line: 289]
            pageContext.forward(__thePage); //[ /welcome.jsp; Line: 289]
            return; //[ /welcome.jsp; Line: 289]
          } //[ /welcome.jsp; Line: 289]

So the exception was thrown from the line highlighted above

In the decompiled JspWriterImpl.class:

It shows:

    public void clear()
        throws IOException
    {
        if(response.isCommitted())
            throw new IllegalStateException("response already committed");
        if(co != null)
            co.clearBuffer();
    }

--leiolay

Leiolay,

After reviewing your stacktrace, my initial response was the same as Jeff's: there is a clear() method that the MutableHttpResponse
object does not override. Unfortunately, I am unable to locate this method in neither HttpServletResponse nor ServletResponse. I have,
however, been working on an updated version of the OWASP CSRFGuard. This version does a much better job of overriding only
the appropriate servlet methods. I would be interested if you run into the same problems with this newer version. You can grab the
project here - https://www.owasp.org/index.php/Image:CSRFGuard2-RC1.tar. In the tar file, under dist, is a compiled version of the
latest CSRFGuard. The following are the installation steps:

1. Untar the download
2. Copy ./dist/CSRFGuard-2.0.jar and ./lib/htmlparser.jar to the appropriate library location in WebLogic (./common/lib?)
3. Copy ./config/CSRFGuard.xml and ./config/CSRFGuardSchema.xsd to the appropriate WEB-INF directory.
4. Modify the entries in CSRFGuard.xml to contain only the pages that you wish to protect.

Please keep me informed of any troubles you run into when using this version. I would find your input very valuable in deciding what
needs to be addressed before releasing a final version of CSRFGuard 2.0. Hopefully your issue can be resolved with this release.

-Eric Sheridan

Eric/Jeff,

Thanks for you responses. I tried the 2.0 version of the Guard but I'm still getting the same error. In addition, another error showed
up:

 java.lang.IllegalStateException: strict servlet API: cannot call getOutputStream
 () after getWriter()
         at weblogic.servlet.internal.ServletResponseImpl.getOutputStream(Servlet
 ResponseImpl.java:158)
         at org.owasp.csrf.CSRFGuard.doResponse(CSRFGuard.java:130)
         at org.owasp.csrf.CSRFGuard.doFilter(CSRFGuard.java:82)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.ja
 va:27)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
 n.run(WebAppServletContext.java:6458)
         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate
 dSubject.java:321)
         at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:
 118)
         at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe
 rvletContext.java:3661)
         at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm
 pl.java:2630)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
 

A couple of other comments:

1. I'm still using java 1.4, so I had to change a few things in the source to get it compile.
2. In CSRFGuard.xml, I need to list all the pages that need to be protected. In our application, there are hundreds if not thousands of pages. It's impossible to manually include them all. Also people will forget to do this if they add new pages.

--Leiolay 14:55, 23 April 2007 (EDT)

Hi Eric, haven't heard from you, any luck on fixing the bug?

Leiolay,

I've been very busy with work and other Aspect projects (see OWASP Spring of Code). After a discussion with Jeff,
we've resolved the "IllegalStateException: response already committed" exception that you got with the old and
new version of the CSRF Guard. I've also resolved the issue you mentioned about having to define hundreds or thousands
of pages to project. Instead, you can define regular expressions instead of single pages. For example, to protect all
JSP pages, you simply add something like <Page>.*.jsp</Page>. The only remaining issue is the recent 

java.lang.IllegalStateException: strict servlet API: cannot call getOutputStream

issue that you got with the new version of CSRFGuard. Once I think I have this
resolved (hopefully on Saturday), I'll upload a new version for testing.

-Eric

Eric,

Excellent! I'm excited about your fixes. Looking forward to trying them out. Thank you so much!

-Leiolay

Leiolay,

I've pushed the latest version of CSRFGuard 2 here - https://www.owasp.org/index.php/Image:CSRFGuard2-RC2.tar.
Please let me know if you still run into the same issues. The "IllegalStateException - response already
committed" error should go disappear. I would be interested if you still get the
"IllegalStateException: cannot call getOutputStream" error. Note that this version uses regular expressions
in the CSRFGuard.xml file. You can specify a simple reg-ex to protect most of your pages. Let me know
what issues you run across. Thanks again for taking the time out of your schedule to test these newer versions.

-Eric