On 12/8/12 6:04 PM, Jesper Kristensen wrote:
My web application displays some sensitive information to a logged in user. The user visits another site without explicitly logging out of my site first. How do I ensure that the other site can not access the sensitive information without accept from me or the user?
For most sorts of sensitive information, browsers prevent access to it. Exceptions are as follows:
1) Loading a cross-site file that can be decoded as an image allows access to the width and height of the image. 2) Loading a cross-site file with a text/css MIME type as a stylesheet allows a site to examine the effects of that stylesheet on elements of the page (e.g. by looking at their computed style). 3) Loading a cross-site file as a script allows a site to examine its effects on the script environment and DOM of the site (but does NOT allow access to things like line text information of exceptions from that script). 4) In some browsers, loading a cross-site file as a font will (if the data is actually font data) allow the loading site access to whatever aspects of that data they can extract from layout information. The spec forbids this behavior, and Gecko doesn't do this. 5) Loading data cross-site in an <object> may allow determination of what category its server-provided MIME type falls into (at least far enough to tell apart "image", "document", and "not supported").6 6) Using a <link rel="stylesheet"> it's possible to test whether a cross-site resource is served with a text/css MIME type.
I believe this should be all the exceptions to the same-origin policy... In addition to those, there are two ways I know off to extract information from cross-origin resources via timing attacks:
7) Loading resources cross-site typically allows a site access to timing information about how long the load took, though the access may be somewhat coarse-grained. 8) Loading resources cross-site may well allow a site access to timing information about how long it takes to paint the resources (or parse them or various other kinds of processing) via examining how long the painting or whatever blocks the event loop. This sort of thing is very hard to close off completely.
I know of other examples, but I don’t like to build my own blacklist. Is there some documentation somewhere that describes when my data is safe?
I'm not sure there's a clear and unambiguous list anywhere. :( -Boris _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
