On Sat, 27 Sep 2008 13:41:06 +0200, Michal Zalewski <[EMAIL PROTECTED]>
wrote:
On Sat, 27 Sep 2008, Robert O'Callahan wrote:
Default permission of cross-domain loads is responsible for *a lot* of
problems. Allowing sites to escape that would address a lot of
problems, even if it is opt-in. Eventually we could hope to reach a
state where all browsers support it, and most sites request it --- a
much saner Web IMHO.
Yup, by all means, it solves a lot of other problems - and devising a
*comprehensive* solution (not a new specialty HTTP header to deal with
IFRAMEs and OBJECT/EMBED/APPLETs specifically), even if opt-in, has the
benefit of actually reducing complexity for web app developers (in terms
of custom XSRF / script inclusion checks, etc, that they could ditch).
The issue is, a considerable implementation effort is involved in most
of these comprehensive designs (given how current same-origin checks,
and code taking cross-domain actions with no same-origin checks, is
typically scattered), lots of open questions (e.g., there are some
important performance trade-offs depending on the granularity of
resources, the types of requests we want to run checks on; site-wide
policies and per-URL policies; etc).
Could you list these comprehensive designs perhaps?
On top of that, there seem to be several incompatible proposals from
various groups, with vendors seemingly not willing to back off.
Microsoft is pursuing their proposal for cross-domain policies in MSIE8,
Mozilla devs had another (and every other security researcher has
probably their "own and better" design in the drawer, about to bring it
out the moment they are asked for advice).
Are you talking about cross-site requests here? FWIW, for that particular
problem I believe all vendors agree on the same server protocol, but not
on the request mechanism. That is, non-Microsoft will do that by evolving
XMLHttpRequest (see XMLHttpRequest Level 2) and Microsoft does it through
XDomainRequest.
However, that's an opt _in_ API as such requests are by default not
allowed.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
