OWASP - User contributions [en]

Talk:OWASP Stinger Version 2

2007-04-27T22:13:35Z

Leiolay: Some suggestions

Hi Eric,

The following classes seemed to be missing from both the jar and project download:

org.owasp.stinger.actions.Sanitize
org.owasp.stinger.actions.ClearCookies

-[[User:Leiolay|Leiolay]] 17:50, 27 April 2007 (EDT)

== Some suggestions ==

It would be nice to be able to load stinger.xml from /WEB-INF or classpath. Just like in SpringMVC.
-[[User:Leiolay|Leiolay]] 18:13, 27 April 2007 (EDT)

Talk:OWASP Stinger Version 2

2007-04-27T21:50:36Z

Leiolay: ClassNotFoundException

Talk:CSRF Guard

2007-04-26T17:52:20Z

Leiolay: /* Having hard time to get it working with Weblogic 8.1 */

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?

<pre>
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)
</pre>

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?
--[[User:Jeff Williams|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:

<pre>
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]
</pre>

So the exception was thrown from the line highlighted above

In the decompiled JspWriterImpl.class:

It shows:
<pre>
public void clear()
throws IOException
{
if(response.isCommitted())
throw new IllegalStateException("response already committed");
if(co != null)
co.clearBuffer();
}
</pre>
--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:
<pre>
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)
</pre>
A couple of other comments:
#I'm still using java 1.4, so I had to change a few things in the source to get it compile.
#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.
--[[User:Leiolay|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!

-[[User:Leiolay|Leiolay]]

Talk:CSRF Guard

2007-04-26T14:41:38Z

Leiolay: /* Having hard time to get it working with Weblogic 8.1 */

Talk:CSRF Guard

2007-04-23T18:55:25Z

Leiolay:

Talk:CSRF Guard

2007-04-23T18:32:23Z

Leiolay:

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?

<pre>
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)
</pre>

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?
--[[User:Jeff Williams|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:

<pre>
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]
</pre>

So the exception was thrown from the line highlighted above

In the decompiled JspWriterImpl.class:

It shows:
<pre>
public void clear()
throws IOException
{
if(response.isCommitted())
throw new IllegalStateException("response already committed");
if(co != null)
co.clearBuffer();
}
</pre>
--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:

<pre>
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)
</pre>

A couple of other comments:

#I'm still using java 1.4, so I had to change a few things in the source to get it compile.
#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.

Talk:CSRF Guard

2007-04-23T16:58:43Z

Leiolay: /* Having hard time to get it working with Weblogic 8.1 */

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?

<pre>
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)
</pre>

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?
--[[User:Jeff Williams|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.

Talk:CSRF Guard

2007-04-20T22:08:13Z

Leiolay:

Talk:CSRF Guard

2007-04-20T21:50:29Z

Leiolay:

Talk:CSRF Guard

2007-04-20T19:25:12Z

Leiolay: Having hard time to get it working with Weblogic 8.1