Bug 20527 - [sg:low] Cross-domain access to stylesheet text should not be allowed
: [sg:low] Cross-domain access to stylesheet text should not be allowed
Status: RESOLVED FIXED
: Security
Security
: 525.x (Nightly build)
: All All
: P2 Normal
Assigned To:
:
: InRadar
:
:
  Show dependency treegraph
 
Reported: 2008-08-26 12:11 PST by
Modified: 2012-05-10 08:15 PST (History)


Attachments
Patch (4.10 KB, patch)
2009-10-31 04:26 PST, Adam Barth
no flags Review Patch | Details | Formatted Diff | Diff
Patch (6.59 KB, patch)
2009-10-31 16:52 PST, Adam Barth
sam: review+
Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-08-26 12:11:12 PST
The following HTML raises security exceptions in Firefox and Opera (IE7 does not appear to support these APIs). Webkit nightly runs the code fine:

<html>
<head>
<link rel="stylesheet" href="https://mail.google.com/mail">
<script>
function func() {
 var sheet = document.styleSheets[0];
 try {
   var len = sheet.cssRules.length;
   alert(len);
   alert(sheet.cssRules.item(0).cssText);
 } catch (e) {
   alert("Error name: " + e.name + ". Error message: " + e.message);
 }
}
</script>
</head>
<body onload="func()">
<div id="blah" class="show">
</body>
</html>

It's not a huge security hole because cross domain CSS property values can be accessed via e.g.
window.getComputedStyle(ele, null).getPropertyValue('blah')

I can think of a couple of minor threat scenarios this would protect against:

- If a paranoid site wanted to hide sensitive property values (a customized background-url perhaps?) it would use randomized style names.

- Any over-tolerance in the CSS parser would expose less of the HTML page.

It's certainly worth bringing into line with Firefox in case there is some future attack I haven't thought about.
------- Comment #1 From 2008-08-26 13:03:20 PST -------
<rdar://problem/6176957>
------- Comment #2 From 2008-08-26 13:05:57 PST -------
I don't understand what this would be protecting against if all the values are accessible by other means.  I am not sure there is much value in changing this if the only reason is to be brought in line with Firefox.  
------- Comment #3 From 2008-08-26 17:49:06 PST -------
The values are accessible but ONLY if you know the style name. Some web site out there may well use unpredictable style names to protect against this.
Other threats may pop up in the future; I'd rather just be safe rather than waiting for a problem.
------- Comment #4 From 2009-01-27 14:44:49 PST -------
Some minor frameworks do seem to randomize CSS style name (although the reason is not clear) so this may be worth fixing.
------- Comment #5 From 2009-04-08 15:06:15 PST -------
Hmm... this would actually permit cross-domain theft of this (and related constructs):

{} hexadecimal_or_ascii_security_token {}

Because the lax CSS parser will pull that selector name (plus empty selector) out of the middle of some non-CSS target cross domain resource.
------- Comment #6 From 2009-09-10 01:05:33 PST -------
This seems low cost and a slight improvement.  I, for one, would welcome a patch that changed our behavior to match Firefox.
------- Comment #7 From 2009-10-31 04:04:36 PST -------
Patch forthcoming.
------- Comment #8 From 2009-10-31 04:26:46 PST -------
Created an attachment (id=42250) [details]
Patch
------- Comment #9 From 2009-10-31 15:17:26 PST -------
Nice patch Adam :)

I had some random q's:

1) Does this prevent access at the same place in the object tree as FF? i.e., getting cssRules object as opposed to the actual stylesheet object?

2) We've had trouble in this area where we didn't account for any redirects in the security check. Is that taken care of?

3) It just occurred to me that Firefox had an interesting bug where it would expose the eventual redirect destination (including sensitive URL params :) of the "href" attribute on a stylesheet. Hopefully we're good here?
------- Comment #10 From 2009-10-31 15:22:02 PST -------
(In reply to comment #9)
> 1) Does this prevent access at the same place in the object tree as FF? i.e.,
> getting cssRules object as opposed to the actual stylesheet object?

Yes.  Firefox throws an exception here.  We just return null, but the mediation point is the same.

> 2) We've had trouble in this area where we didn't account for any redirects in
> the security check. Is that taken care of?

We should add a test for that case!  My understanding is that this code is checking against the final URL, just like access to an iframe is based on the final URL of the content loaded in the frame.

> 3) It just occurred to me that Firefox had an interesting bug where it would
> expose the eventual redirect destination (including sensitive URL params :) of
> the "href" attribute on a stylesheet. Hopefully we're good here?

No idea.  I recommend writing a test.  If we pass the test, great!  We can check it in and we won't regress.  If we fail the test, that's the first step towards fixing the problem.
------- Comment #11 From 2009-10-31 15:39:42 PST -------
Ok. I'll be writing a test for some CSS issues I'm working on, so I can work these cases in.
------- Comment #12 From 2009-10-31 16:52:01 PST -------
Created an attachment (id=42263) [details]
Patch
------- Comment #13 From 2009-10-31 16:55:10 PST -------
> We should add a test for that case!

Added.
------- Comment #14 From 2009-11-01 16:27:54 PST -------
This doesn't really seem like the correct layer to be doing this check.  All the other same-origin checks exist in the JS bindings layer, so that other bindings are not changed.
------- Comment #15 From 2009-11-01 16:33:57 PST -------
(In reply to comment #14)
> This doesn't really seem like the correct layer to be doing this check.  All
> the other same-origin checks exist in the JS bindings layer, so that other
> bindings are not changed.

I modelled this check after similar checks that we do in WebCore for XMLHttpRequest, XSL style sheets, and external XML entities.

I actually had the check in the bindings layer in my original patch (not posted).  I can move it back if you like.
------- Comment #16 From 2009-11-01 16:36:07 PST -------
Oh, there's another instance in the canvas code somewhere that does similar things for cross-origin images.
------- Comment #17 From 2009-11-04 14:40:23 PST -------
Pinging reviewer :)
------- Comment #18 From 2009-11-05 22:57:16 PST -------
http://trac.webkit.org/changeset/50587
------- Comment #19 From 2010-04-23 16:30:32 PST -------
This breaks a technique where a site:

    1) Puts its CSS on a different server.

    Putting subresources in a separate domain can be useful so that the HTTP GET does not include any cookies and also so you can do different types of caching and network acceleration.

    2) Uses JavaScript to iterate the CSS so it can wait for all the CSS images to load before doing something.

The Safari welcome screen webpage at http://www.apple.com/safari/welcome/ makes use of this technique.
------- Comment #20 From 2010-04-23 16:34:44 PST -------
> The Safari welcome screen webpage at http://www.apple.com/safari/welcome/ makes
> use of this technique.

How does the Safari welcome page work in Firefox?  We're aiming to match FF here.
------- Comment #21 From 2010-04-23 16:36:09 PST -------
> How does the Safari welcome page work in Firefox?  We're aiming to match FF
> here.

"Download Safari 4 to view this page."

I guess that page doesn't work in other browsers.