[whatwg] Dealing with UI redress vulnerabilities inherent to the current web
robert at ocallahan.org
Sat Sep 27 19:39:11 PDT 2008
On Sun, Sep 28, 2008 at 12:41 AM, Michal Zalewski <lcamtuf at dione.cc> 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).
Glad you think so.
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).
> 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).
I'm not sure what you're talking about here. I'm specifically NOT talking
about Content-Restrictions or Site-Security-Policies or any other policies
for controlling what a page may do once it has loaded.
I'm expressing approval for your option 1,
yes", preferably generalized to
"X-I-Do-Not-Want-To-Be-Loaded-Across-Domains: yes" so that it can be used
for scripts and images too. On top of that, I'd add the W3C Access Controls
spec for finer-grained control --- a spec that all the major vendors have
signed on to. (So I'm really suggesting
I think this would be much easier to implement than your option 3. Option 3
requires hooking into layout, rendering, and event handling, and doing
constant ongoing checks and state changes where we currently don't have any
security checks. Furthermore there's an ongoing maintenance burden as every
new layout and rendering feature has to be security-analyzed to see if it
need to participate in the option 3 algorithm, and hooked up if so. OTOH
option 1 requires only checks at load time, where we're already doing a lot
But feel free to ask other implementors what they think.
Bottom line is, I would be very surprised if such a functionality would be
> in a state that can be relied upon by web applications in the next 5-8 years
> (more if the abysmally slow MSIE6 -> MSIE7 migration is bound to repeat with
> next major versions)... and I am not entirely comfortable with UI redress
> attacks being around for so long; I suppose most browser vendors are not
> happy too, given the recent / likely upcoming press attention.
So what? The same goes for all your options --- slow browser migration
delays the uptake of any client-side solution. In fact, a solution that
servers opt in to is likely to see *faster* client uptake because vendors
and users will see a lower risk of Web applications breaking.
The real concern about an opt-in solution is Web apps taking a long time to
use it. But it seems to me that most sites could just add the option 1
header for all pages on the site and the site would Just Work.
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg