7 Replies Latest reply on May 31, 2008 10:10 AM by Christian Bauer

    Is Seam Remoting vulnerable to Cross-Site request forgery?

    Raj Tiwari Newbie

      Calls made using seam remoting are kept in the same session using cookies and in the same conversation using a (guessable) conversation id. This would make my seam remote interface vulnerable to Cross-site request forgery (XSRF) where a rogue web page open in a separate tab makes seam remote calls without authorization to a seam site and invokes operations without the user's knowledge.


      One way to get around XSRF is to use a non-guessable canary value that is required in addition to being in the session and conversation to invoke the seam remote operation. I could possibly implement this on my own, but I am curious if this is already part of the framework or planned.


      Thanks.


      -Raj

        • 2. Re: Is Seam Remoting vulnerable to Cross-Site request forgery?
          Christian Bauer Master

          Yes, I think Seam Remoting is vulnerable to XSRF attacks to some extend. It's one of the reasons why we don't support persistent sessions out of the box, mitigating the problem somewhat. A forged GET link or POST form would only work if the current user is logged in - which never happens automatically in a Seam application without customization.


          Having said that, if you want to submit a patch that implements a canary check, please do so.


          But, as I'm not too familiar with the actual Seam Remoting code, Shane might have implemented this already.

          • 3. Re: Is Seam Remoting vulnerable to Cross-Site request forgery?
            Shane Bryzak Master

            Seam Remoting is no more vulnerable to session hijacking than any other type of request.

            • 4. Re: Is Seam Remoting vulnerable to Cross-Site request forgery?
              Raj Tiwari Newbie

              Shane,


              Seam and Seam Remoting are wonderful frameworks and I love using them. That being said, AJAX frameworks are the butt of jokes in security forums. XSRF is a very well known security hole. Most sites that deploy AJAX heavy apps such as Google closely monitor such holes and fix them...no matter how small.




              Seam Remoting is no more vulnerable to session hijacking than any other type of request.

              This is not completely accurate. Direct Web Remoting addresses in the latest release. I will not deploy my Seam application on the open Internet until I take care of this security hole. I can guarantee you this, though: hundreds of others will. Then, they will get hacked with something known for over two years. When that happens, we will wish Seam security had some more upgrades.

              • 5. Re: Is Seam Remoting vulnerable to Cross-Site request forgery?
                Shane Bryzak Master

                What's to stop the same kind of exploit with a standard JSF or web service request?  That's what I'm trying to determine - I just don't see why these are less vulnerable than a remoting request.

                • 6. Re: Is Seam Remoting vulnerable to Cross-Site request forgery?
                  Raj Tiwari Newbie

                  Shane,


                  I cannot comment on JSF security since I don't know JSF too well. As for web services (whether SOAP or Restful), they are stateless by design. The authors of the web services are usually responsible for securing them on a per-invocation basis. This is usually done using access tokens in request parameters or some other means.


                  What AJAX frameworks like Seam Remoting and DWR do is expose server-side functionality through web services that web page authors assume are secured...through the session id/cookie. When these web services are invoked through the browser and a secured and authenticated connection established, any web page running in that browser has access to that secure tunnel.


                  At this point I believe both A4J and Seam remoting are vulnerable.


                  -Raj

                  • 7. Re: Is Seam Remoting vulnerable to Cross-Site request forgery?
                    Christian Bauer Master

                    Shane Bryzak wrote on May 31, 2008 03:50:


                    What's to stop the same kind of exploit with a standard JSF or web service request?  That's what I'm trying to determine - I just don't see why these are less vulnerable than a remoting request.


                    For JSF you have a canary, which is either the identifier of the ViewState (server-side state saving)  or the serialized view state (client-site state saving). The identifier is incremented on every GET request, at least with the JSF RI. A forged JSF request would have to include these values to get past the RESTORE VIEW phase.