-
1. Re: Is Seam Remoting vulnerable to Cross-Site request forgery?
rituraj_tiwari May 30, 2008 9:24 PM (in response to rituraj_tiwari)Folks,
Can someone comment on this?
-Raj
-
2. Re: Is Seam Remoting vulnerable to Cross-Site request forgery?
christian.bauer May 30, 2008 9:50 PM (in response to rituraj_tiwari)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 May 31, 2008 1:44 AM (in response to rituraj_tiwari)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?
rituraj_tiwari May 31, 2008 3:31 AM (in response to rituraj_tiwari)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 May 31, 2008 3:50 AM (in response to rituraj_tiwari)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?
rituraj_tiwari May 31, 2008 9:01 AM (in response to rituraj_tiwari)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 May 31, 2008 10:10 AM (in response to rituraj_tiwari)
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.