referrer leakage from apps

[diracdeltas]

By default, apps will leak their referrer to embedded resources and links, which can cause users to inadvertently grant capabilities to other parties.

To repro:

• type 'https://example.com' into the etherpad app
• click on the auto-generated hyperlink
• check document.referrer in context of example.com

[diracdeltas]

Also, what is the relationship between the grain URL (the one in the URL bar) and the iframe URL? Are they equivalent in terms of capabilities granted?

[kentonv]

The hostname is based on a session ID, which is different from a grain ID.

Knowing the session ID does not directly grant any capabilities -- the rightful user is additionally authenticated with a cookie. However, knowing another user's session host does mean that you can potentially attempt XSRF, clickjacking, and reflected-XSS attacks that would have been categorically impossible without knowing the host to address them to. So we'd prefer to keep the host secret, but mainly as a risk-management measure. (Note that the grain host is of course also transmitted in cleartext for DNS and SNI purposes, so it will never be a perfect defense.)

The client-side sandbox is not complete. One thing we plan to do is use Content-Security-Policy to prevent the app from embedding external resources or allowing the user to follow external links at all. (For the simple link-clicking case, we can capture policy violation reports and then ask the user if they really intended to open the link.)

[diracdeltas]

Knowing the session ID does not directly grant any capabilities -- the rightful user is additionally authenticated with a cookie.

This might just be semantics, but knowing the hostname seems to grant any capabilties that a non logged-in user who knows the grain ID has.

For instance, someone who has the hostname of the etherpad iframe can read/write to an unprotected etherpad.

[dwrensha]

For instance, someone who has the hostname of the etherpad iframe can read/write to an unprotected etherpad.

If that's true, it's a bug. You should get a 403 if you don't have the proper "sandstorm-sid" cookie.

[diracdeltas]

@dwrensha Oops, you're right. I had been testing on a browser profile that had the cookie. Thanks!

[paulproteus]

Kenton's remark above is quite right.

@diracdeltas , it'd be really great if you'd be willing to write a wiki page called "Client Side Security" that covers some of these issues. If not, that's fine, but I thought I'd at least try asking if you want to. (-:

If we accept Kenton's notion that fixing the client-side sandbox isn't a top priority at the very moment, then I think it's OK to close this bug once the current state is well-documented.

[diracdeltas]

I might have time to write that page.

Closing because this appears to not really be a problem (except with my poor browser session switching skills).