google-code-export / webpasswordsafe

Automatically exported from code.google.com/p/webpasswordsafe
0 stars 3 forks source link

on glassfish: SecurityException Blocked request without session header (CSRF attack?) #22

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
when i deploy to a glassfish server, i get a nice exception.
seems the session handling is a bit different to your tomcat-environment.
i got a hack around but what would be the correct generic solution?

What steps will reproduce the problem?
1. build as in install.txt described
2. deploy to glassfish server v 3.0.1

What do you see instead?
Error 500 and the following exception
[#|2010-12-09T19:32:46.541+0100|SEVERE|glassfish3.0.1|javax.enterprise.system.co
ntainer.web.com.sun.enterprise.web|_ThreadID=24;_ThreadName=http-thread-pool-844
3-(1);|WebModule[/webapp/webpasswordsafe]Exception while dispatching incoming 
RPC call
java.lang.SecurityException: Blocked request without session header (CSRF 
attack?)
        at com.joshdrummond.webpasswordsafe.server.CSRFProtectedGileadRPCServiceExporter.onBeforeRequestDeserialized(CSRFProtectedGileadRPCServiceExporter.java:52)
        at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:238)
        at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
        at org.gwtwidgets.server.spring.GWTRPCServiceExporter.handleRequest(GWTRPCServiceExporter.java:389)
        at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:49)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
        at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
        at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
        at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
        at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
        at java.lang.Thread.run(Thread.java:636)
|#]

What version of the product are you using? On what operating system?
trunk@115
os not relevant reproducable on linux and windows

Please provide any additional information below.
commenting the section as in patch helps

Index: 
src/main/java/com/joshdrummond/webpasswordsafe/server/CSRFProtectedGileadRPCServ
iceExporter.java
===================================================================
--- 
src/main/java/com/joshdrummond/webpasswordsafe/server/CSRFProtectedGileadRPCServ
iceExporter.java    (revision 113)
+++ 
src/main/java/com/joshdrummond/webpasswordsafe/server/CSRFProtectedGileadRPCServ
iceExporter.java    (working copy)
@@ -48,10 +48,10 @@
             // Otherwise the client must provide the id of the session in a header.
             if (session != null && !session.isNew()) {
                 String sessionId = servletRequest.getHeader(Constants.HEADER_KEY_CSRF_TOKEN);
-                if (sessionId == null || 
!sessionId.equals(servletRequest.getSession().getId())) {
-                    throw new SecurityException(
-                        "Blocked request without session header (CSRF 
attack?)");
-                }
+//                if (sessionId == null || 
!sessionId.equals(servletRequest.getSession().getId())) {
+//                    throw new SecurityException(
+//                        "Blocked request without session header (CSRF 
attack?)");
+//                }
             }
         }

Original issue reported on code.google.com by m...@shofer.ch on 9 Dec 2010 at 6:40

GoogleCodeExporter commented 9 years ago
I was able to reproduce if i go to the glassfish admin console (localhost:4848) 
then WebPasswordSafe (localhost:8080).  It appears glassfish creates two 
JSESSIONIDs, one for / path (port 4848) and one for /WebPasswordSafe (port 
8080) and the browser sends both of them to WebPasswordSafe confusing it as to 
which to use for CSRF protection.  Need to see if GWT can retrieve cookies 
based on path.  Instead of the code change above, an alternative workaround 
would be a config file change to set all "strongCsrfProtection" values in 
war/WEB-INF/rpc-servlet.xml to "false"

Original comment by joshdrum...@gmail.com on 10 Dec 2010 at 4:40

GoogleCodeExporter commented 9 years ago
Decoupled CSRF cookie from JSESSIONID to be application specific to avoid 
conflicts with other applications such as with Glassfish

Original comment by joshdrum...@gmail.com on 10 Dec 2010 at 9:41

GoogleCodeExporter commented 9 years ago
works fine thanks!

Original comment by m...@shofer.ch on 11 Dec 2010 at 11:09