Security/Reviews/crossoriginAttribute

Items to be reviewed:

• https://bugzilla.mozilla.org/show_bug.cgi?id=664299 - Add crossorigin attribute
• https://bugzilla.mozilla.org/show_bug.cgi?id=685518 - Shouldn't taint the canvas when drawing images with @crossorigin into it
  • http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element

Introduce Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

• Due to the webGL cross-origin issues discovered in Firefox 5 - https://bugzilla.mozilla.org/show_bug.cgi?id=655987 - we had to disable most cross-domain images from being used in WebGL.
• This feature allows sharded or cooperating sites to use cross-origin images for WebGL.
  • Possibly going through canvas2d first? (CORS-approved images not “taint” the canvas in Firefox 9.)
• This feature allows pairs of web sites a way to indicate that an image should be allowed to be read (rather than only displayed).
  • A new kink in the “allow-display vs allow-read” mess.

What solutions/approaches were considered other than the proposed solution?

• Allow CORS to be specified on images without requiring an attribute.
  • That would require including the Origin header on all requests, which would have perf and privacy problems?

Why was this solution chosen?

• CORS already existed, mostly used for XMLHttpRequest.
• Adding the “crossorigin” attribute to the img element fit with CORS.
• Interaction with Origin header?

Any security threats already considered in the design and why?

• reintroducing the "cross-domain image theft" problem
• fingerprinting my malicious sites <-- ??

Threat Brainstorming

Threats specific to images/crossorigin

• Caching (http cache, image cache, proxies)
  • Is there an implicit "Vary: Origin"? ooh, good point
  • Could any of these caches cause the data from one response to be mixed with the approval from another response?
    • Especially before the second request completes.
• What if the crossorigin attribute is added after the img was loaded? [ No effect. The CORS mode used during the load is stored directly on the imgIRequest, so changes to the crossorigin attribute after the image started loading have no effect. --bz ]
  • or changed among {not present, anonymous, use-credentials}? [ Again, no effect, see above. --bz ]
• What if the crossorigin attribute is added while the img is loading? [ See above. --bz ]
• What about images loaded via new Image() and then added to the document? [ These are no different from images created by the parser. --bz]
• What happens if a CORS approved image is added to a tainted canvas/context? (e.g. can you somehow untaint it) [ No, a canvas can never be untainted. --bz ]
• What exactly is associated with the CORS approval, e.g. the exact URL of the image? [ The approval is associated with the triple (Image URL, CORS mode, loading principal). Good question! --bz ]
• How comprehensive are our regression tests for this feature?
  • http://hg.mozilla.org/mozilla-central/file/6cd262091470/content/canvas/test/crossorigin
  • http://hg.mozilla.org/mozilla-central/file/6cd262091470/content/canvas/test/crossorigin/test_webgl_crossorigin_textures.html
  • We don't have more tests covering image cache behavior. Need more.
  • What general CORS / networking tests do we have?

Threats that have more to do with CORS than images/crossorigin

• Redirects
  • Redirect from same-origin to cross-origin: do we forget to set the Origin header?
  • Redirect from cross-origin to same-origin: does this allow the cross-origin server to trick the first server somehow?
  • Redirect from cross-origin to cross-origin: here, you almost want the Origin to be both the original requestor and the redirector

[We have tests for all of the above -- sicking]

• In requests, is the Origin header based on the principal or the URL of the document?
  • What happens if we don't have a principal that would be meaningful to the image server? (e.g. a data: URL with no inherited origin)

[We use the principal of the .ownerDocument of the <img>. If the pricipal doesn't have a meaningful origin we'll use "null". This is per CORS spec. -- sicking]

• DNS rebinding

[We have no protection for this. Needs support from necko. It's a general problem not just in CORS, but in HTML in general]

• Site causing Firefox to make an "anonymous" request to site B. Ignoring the response for now, what CSRF and cookie poisoning opportunities does that open? Especially if there's an insane proxy in the middle? (see also xmlhttprequest withCredentials property)

[We ignore any cookie headers in the response from Anonymous requests, so this isn't a problem -- sicking]

Threats that have more to do with draw-image-into-canvas than crossorigin

• Animated images -- gain timing information, or information about whether the image was already animating?
• Transparent images -- gain information about what's behind the image?
• SVG "images" -- foreignObject, visited links (cf bug 147777), ...
• Drawing from an image before the image has fully loaded -- uninitialized memory?

Conclusions / Action Items

• [benoit/QA] Regression test: ensure we have regression tests for everything mentioned in the "Threats specific to images/crossorigin" section, and edit this wiki page so each item points to the relevant test. (Hint: write pairs of tests, one "should be disallowed" and one "should be allowed".)
  • XHR cross-origin tests may cover some of this - ask jonas
• [who?? jonas/smaug?] Ensure we have regression tests for "Threats that have more to do with CORS than images/crossorigin" section
• [who?? bz?] Ensure we have regression tests for "Threats that have more to do with draw-image-into-canvas than crossorigin" section
• [curtis]^^ ask jonas/smaug/bz about the above items