- From: John Daggett <jdaggett@mozilla.com>
- Date: Thu, 30 Jun 2011 16:15:35 -0700 (PDT)
- To: Glenn Adams <glenn@skynav.com>
- Cc: John Hudson <tiro@tiro.com>, liam@w3.org, StyleBeyondthePunchedCard <www-style@w3.org>, public-webfonts-wg@w3.org, www-font@w3.org, "Martin J." <duerst@it.aoyama.ac.jp>, Sylvain Galineau <sylvaing@microsoft.com>, Vladimir Levantovsky <Vladimir.Levantovsky@monotypeimaging.com>
Glenn Adams wrote: > if EvilCompany does not include an Origin header in its request, then > BigCompany could not distinguish that request as coming from a > pre-HTML5 UA (i.e., current conditions), in which this case devolves > to the current read scenario; > > if BigCompany does not respond to fetches not containing an Origin, > then again EvilCompany can guess an origin that permits access, > resulting in a fetch; There's no "origin header" here, the origin is the site where a given piece of content originated. In the example below, BigCompany content originates from a BigCompany origin, EvilCompany from a popular site origin (or some ad network origin). The origin is the same in either an older UA or a "HTML5 UA" (not sure how you're drawing this distinction). > EvilCompany does not need to use a UA, but can construct their own > HTTP client to accomplish this; Sure, but getting an employee of BigCompany to use a UA constructed by EvilCompany is an entirely different attack vector, one that would be a *much* more difficult task compared to getting that employee to navigate to a popular site. > the scenario you offer only prevents access if *every* HTTP client, > whether UA or not, respects SOR; Sure, just as security updates can only fix problems for those users who update, they can't magically make the problems just disappear. Regards, John On Thu, Jun 30, 2011 at 3:59 PM, John Daggett <jdaggett@mozilla.com> wrote: Glenn Adams wrote: > Regarding the last, please show me an attack based on font access that > SOR prevents. One possible attack scenario: BigCompany decides to design a new logo. They commission a font containing a special glyph with that logo in it. An access-restricted site is created using that custom font. EvilCompany, a competitor, would like to know about that logo before it is released publicly. They insert script in web ads on popular sites that systematically attempt to guess possible access-restricted URLs for the custom font. An employee of BigCompany hits one of the pages on an external site containing one of EvilCompany's webads. If no origin restriction exists, the web ad code can access the font as long as they guess the right access-restricted URL and an employee of BigCompany happens to have access. The script inserted in a webad by EvilCompany accesses the custom logo glyph and sends it back to an EvilCompany-controlled site. If font loads are restricted to same origin and the BigCompany hasn't explicitly enabled cross-origin loading via CORS, the web ad code will *never* be able to load the font even if their code guesses the right access-restricted URL, since it's origin is different. The scenario is the same one as in the WebGL example I noted earlier, without same origin restrictions content can be accessed via means that are not immediately obvious to the naive author. Regards, John Daggett
Received on Thursday, 30 June 2011 23:16:06 UTC