I created a new JIRA issue to remind me to do something about preventing/limiting XSS attacks in Seam Remoting: https://jira.jboss.org/jira/browse/JBSEAM-3482 However I'm still not totally clear how I should be tackling this problem, probably because I don't fully understand the mechanism behind an XSS attack. We already have an incremental call ID value passed with each remote request, so this could possibly be used as our "canary" value. In any case, could you please walk me through the moving parts of an XSS attack step by step just so we're clear on what needs to be protected?

Because it is back on Slashdot again today, I remembered why the "let's automatically build a view if we don't have one in RESTORE VIEW phase" proposal in JSF 2.0 was not sitting right with me. You need a little background on XSRF (Wikipedia or something) and see the older discussion here and especially my last comment: http://www.seamframework.org/Community/IsSeamRemotingVulnerableToCrossSit... I actually now think that we should have a cryptographically strong (and of course mandatory) view identifier for better XSRF protection. There are some other solutions worth discussing but AFAIK most of the good ones involve a token/session mapping of some kind, so we run into the "view has expired" problem again. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

A contact form is another great example. It would be no different than implementing a GET request with a page action. No doubt I am not thinking of some obscure attack, so feel free to cite where my logic is faulty, but I believe there is such a thing as a stateless page.

On Oct 01, 2008, at 15:22 , Shane Bryzak wrote: > I created a new JIRA issue to remind me to do something about > preventing/limiting XSS attacks in Seam Remoting: > > https://jira.jboss.org/jira/browse/JBSEAM-3482 > > However I'm still not totally clear how I should be tackling this > problem, probably because I don't fully understand the mechanism > behind an XSS attack. We already have an incremental call ID value > passed with each remote request, so this could possibly be used as > our "canary" value. In any case, could you please walk me through > the moving parts of an XSS attack step by step just so we're clear on > what needs to be protected? First, it is not an XSS attack although an additional XSS problem could disable any XSRF protection you might implement. The attack is quite simple, this is a more sophisticated variation: You run a website that requires a session cookie and a logged-in user. As soon as the user is logged-in, any request from her browser will send the session cookie along, hence, it's considered a valid request for any operation she has permission on (checked on the server). Any other tab or browser window on her client can also send a valid request to your server. So all the attacker has to do is get her to open his malicious webpage, which runs a little Javascript that sends a POST request to your website. You will execute the operation because there is a valid session cookie in the request. You don't know if the request came from "your" form/window or the attackers Javascript.

Typically you prevent this with a cryptographically strong nonce/token that has to be present in addition to the session cookie - it is internally tied into the session of course, so it can be validated. Think view ID in JSF, the POST fails if the view with the given ID can't be restored.

If you also have an XSS hole on your website, the attacker can read the nonce/token with Javascript and you are back to square one. Same for a simple incremented value, an attacker can guess it.

It's even easier to exploit if you have unsafe GET operations, like ?action=transferMoney&from=123&to=456... that's why <s:link action> is really evil. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Oct 03, 2008, at 02:25 , Shane Bryzak wrote: >> Any other tab or browser window on her client can also send a valid >> request to your server. So all the attacker has to do is get her to >> open his malicious webpage, which runs a little Javascript that >> sends a POST request to your website. You will execute the operation >> because there is a valid session cookie in the request. You don't >> know if the request came from "your" form/window or the attackers >> Javascript. > > So how is this different to having multiple browser tabs/windows open > in the same Seam application? That "same" Seam application is not supposed to give anyone the ability to insert malicious Javascript that can generate POST requests automatically. :) The whole issue is that it works across sites, hence XS request forgery. >> Typically you prevent this with a cryptographically strong >> nonce/token that has to be present in addition to the session cookie >> - it is internally tied into the session of course, so it can be >> validated. Think view ID in JSF, the POST fails if the view with the >> given ID can't be restored. > > How is this token generated and propagated to the client? It's a hidden field in the original form, for example. Think JSF view identifier. So the only valid POST request would be the one submitting that form. Not any other POST request that just happens to get the URI and some of the parameters right. > Couldn't a XSRF attack simply retrieve the token in the very same way? You'd have to retrieve the token value, that means you need to scrape it off the form's hidden field. This is the same challenge as stealing someone's session cookie, i.e. usually done through an XSS attack.

>> If you also have an XSS hole on your website, the attacker can read >> the nonce/token with Javascript and you are back to square one. Same >> for a simple incremented value, an attacker can guess it. > > That makes sense (and actually an incremented value won't really work > anyway for other reasons). Is there really any protection against > XSS attacks though? Besides making an effort to prevent them in the > first place? Protecting against an XSS attack is relatively easy: Never show any data on your website that has been entered by a user. If a user enters data and you want to later on show that data, you need to filter it. Implementing a filter that is valid until the next XSS trick is discovered (browsers these days parse all kinds of sh*t, even if you escape it) is not trivial. Again, XSS is not XSRF. An XSS security hole can make your XSRF protection useless. But you need XSRF protection in the first place.

Can anybody check how strong the view-id in JSF is, that is, how it is generated? Can it be guessed? _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Oct 03, 2008, at 03:20 , Shane Bryzak wrote: > Why couldn't it just request the application's home page and parse > the response to extract the token value? Because it's a random value that is generated for each form instance. A good random. Shane, you know what the JSF view identifier for server-side state saving is and how it is propagated onto the client and validated on the server? That's the XSRF protection. I'm wondering if you have the same in Seam Remoting and if in general, the randomness of the JSF identifier is good enough.

> Ok, so in this case prevention is the best medicine, and if I'm > understanding correctly there's not much that can be done to protect > against/detect an XSS attack once the security hole has been exploited. I don't understand that. Let's forget about XSS for a moment and focus on XSRF.

_______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Oct 03, 2008, at 03:31 , Shane Bryzak wrote: >> Because it's a random value that is generated for each form >> instance. A good random. Shane, you know what the JSF view >> identifier for server-side state saving is and how it is propagated >> onto the client and validated on the server? That's the XSRF >> protection. I'm wondering if you have the same in Seam Remoting and >> if in general, the randomness of the JSF identifier is good enough. > > So, for this token to actually work, it must be propagated with every > single request that is sent to the server - included as a request > parameter with every single link, form submission, basically every > single GET and POST request that is made must include the token, right? Every POST, definitely. GET is supposed to be idempotent and safe, not to modify resource state. So if you abuse it to be non-safe, then yes it needs the same XSRF protection. And sometimes you have POSTs that are also "safe", like a login form. That's the stateless view we were talking about.

_______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev