Ian Hickson wrote, On 18/02/2009 12.43:
3) Add an on-by-default mechanism that prevents UI actions to be taken
when a document tries to obstruct portions of a non-same-origin frame.
By carefully designing the mechanism, we can prevent legitimate uses
(such as dynamic menus that overlap
On Thu, 25 Sep 2008, Michal Zalewski wrote:
1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of
X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes that permits a web
page to inhibit frame rendering in potentially dangerous situations.
Pros:
- Super-simple
Cons:
Boris Zbarsky wrote on 2/18/2009 9:27 AM:
On Thu, 25 Sep 2008, Michal Zalewski wrote:
1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of
X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes that permits a web
page to inhibit frame rendering in potentially dangerous
Bil Corry wrote, On 18/02/2009 21.31:
Boris Zbarsky wrote on 2/18/2009 9:27 AM:
And really no different from:
script
if (window != window.top)
window.top.location.href = window.location.href;
/script
in effect, right? This last already works in all browsers except IE,
which
Richard Maher
- Original Message -
From: Maciej Stachowiak [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: whatwg@lists.whatwg.org; Michal Zalewski [EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 12:22 PM
Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to
the current
Collin Jackson wrote:
6) New cookie attribute: The httpOnly cookie flag allows sites to
put restrictions on how a cookie can be accessed. We could allow a new
flag to be specified in the Set-Cookie header that is designed to
prevent CSRF and UI redress attacks. If a cookie is set with a
On Sat, Oct 11, 2008 at 11:29 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Collin Jackson wrote:
[snip]
If a cookie is set with a
sameOrigin flag, we could prevent that cookie from being sent on
HTTP requests that are initiated by other origins, or were made by
frames with ancestors of other
On Tue, Sep 30, 2008 at 10:33 PM, Michal Zalewski [EMAIL PROTECTED] wrote:
On Tue, 30 Sep 2008, Robert O'Callahan wrote:
If I understand correctly, with Michal's option 3, those sites would also
stop working as soon as the user scrolled down in the framed page (so that
the top-left of the
On Wed, 1 Oct 2008, Robert O'Callahan wrote:
I don't think that's secure. The outer page can set the IFRAME's URL to
contain a #xyz fragment identifier
That's really covered in the original proposal. Honest :P In a kludgy
manner, of course (permitting fragments, but not permitting onload
Kristof Zelechovski wrote:
If you set up a mirror with the same host name as the content provider has,
you will probably get sued for identity theft, cybersquatting, forgery or
whatever.
No, only the content provider (really the domain name owner) can set up
these mirrors. This is nothing
.
Chris
-Original Message-
From: Elliotte Harold [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 5:03 PM
To: Kristof Zelechovski
Cc: 'WHAT WG List'
Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to
the current web
Kristof Zelechovski wrote:
If you set up
On Sep 29, 2008, at 23:52, Adam Barth wrote:
On Mon, Sep 29, 2008 at 1:40 PM, Anne van Kesteren
[EMAIL PROTECTED] wrote:
I thought the issue with Referer
was that it exposed path information, but I guess the problem with
Origin is
that it reveals the intranet server name?
The query
Elliotte Harold writes:
Smylers wrote:
That's a sometimes convenient feature for site developers, but
there's nothing you can do with content loaded from two sites you
can't do with content loaded from one.
Here's some I can think of:
* Many sites are funded by displaying
Elliotte Harold writes:
Large content providers already move their content closer to the end
user. They do this by physically locating boxes with the same host
name and fancy DNS and router tricks.
Yup. But those are _large_ content providers. We shouldn't design HTML
5 such that smaller
On Tue, Sep 30, 2008 at 9:31 AM, Henri Sivonen [EMAIL PROTECTED] wrote:
This could be addressed by sending a cryptographic hash of the origin (using
an algorithm that is commonly available in libraries used by server-side
programmers).
Interesting idea. So you're suggesting something like:
On Tue, 30 Sep 2008, Adam Barth wrote:
This could be addressed by sending a cryptographic hash of the origin (using
an algorithm that is commonly available in libraries used by server-side
programmers).
Interesting idea. So you're suggesting something like:
Origin-SHA1:
Michal Zalewski wrote:
More importantly, since the dictionary of possible inputs is rather
limited, it would be pretty trivial to build a dictionary of site -
hash pairs and crack the values. May protect
xyzzy2984.eur.int.example.com, but would still reveal to me you are
coming from
On Tue, 30 Sep 2008, Edward Z. Yang wrote:
More importantly, since the dictionary of possible inputs is rather
limited, it would be pretty trivial to build a dictionary of site -
hash pairs and crack the values. May protect
xyzzy2984.eur.int.example.com, but would still reveal to me you are
Michal Zalewski wrote:
Not really? I just need to rebuild my dictionary for that salt, but to
check against say a million or ten million of common domains, it
wouldn't be very expensive. And it's not very expensive to build such a
list of domains, too.
In that case, you are certainly correct;
On Tue, 30 Sep 2008, Edward Z. Yang wrote:
In that case, you are certainly correct; adding a salt only hinders an
attacker. But if we're worried about Origin giving away a secret
intranet website, I think things should be reasonable. Of course, they
can still dictionary brute-force it...
I
On Sep 30, 2008, at 7:57 AM, Elliotte Harold wrote:
Maciej Stachowiak wrote:
More generally, I am on Apple's internal incoming security bug
list, and I see Java applet security bugs all the time, so I think
whatever the strength of the model may be, it does not lead to Java
applets
2008/9/25 Toby A Inkster [EMAIL PROTECTED]:
3) Add an on-by-default mechanism that prevents UI actions to be taken
when a document tries to obstruct portions of a non-same-origin frame.
Something like focus-follows-mouse plus autoraise for IFRAMEs might work.
Not likely. The entire point
On Mon, Sep 29, 2008 at 9:54 PM, Hallvord R M Steen [EMAIL PROTECTED]wrote:
To give webmasters more ways to deal with this situation, I think we
should implement the Access Control Origin HTTP-header only
(assuming that it should refer to the top site in the frameset
hierarchy).
Reasoning:
On Mon, 29 Sep 2008, Hallvord R M Steen wrote:
To give webmasters more ways to deal with this situation, I think we
should implement the Access Control Origin HTTP-header only (assuming
that it should refer to the top site in the frameset hierarchy).
I definitely like the Origin proposal the
On Mon, 29 Sep 2008 13:41:59 +0200, Michal Zalewski [EMAIL PROTECTED]
wrote:
Note that the current implementation proposals for Origin headers
(which I believe are limited to non-GET, non-HEAD requests) would not
prevent this attack, nor some other potential attack vectors; they would
On Mon, 29 Sep 2008, Anne van Kesteren wrote:
A cross-site XMLHttpRequest request would always include Origin. I
haven't really seen other specifications start using it yet, but I
believe there are some experimental implementations for including it in
cross-site form POST requests.
Yup, I
2008/9/29 Michal Zalewski [EMAIL PROTECTED]:
I definitely like the Origin proposal the most of all the opt-in schemes,
simply because it permits trusted domains to be whitelisted for many
applications that rely on same-origin separation to implement security
sandboxes.
It still completely
On Mon, 29 Sep 2008, Hallvord R M Steen wrote:
It still completely ignores the question of how we protect gadgets / mashups
/ whatever that are *designed* to be embedded on potentially untrusted
sites, but depend on having the integrity of their UIs preserved
After giving this quite some
The current proposal is to sent the Origin header for non-GET,
non-HEAD requests. The main reason not to send the header all the
time is that it raises similar privacy concerns as the Referer header,
which have caused the Referer header to be suppressed a non-trivial
fraction of the time.
On Mon, 29 Sep 2008 16:06:09 -0400, Adam Barth [EMAIL PROTECTED]
wrote:
The current proposal is to sent the Origin header for non-GET,
non-HEAD requests. The main reason not to send the header all the
time is that it raises similar privacy concerns as the Referer header,
which have caused the
On Mon, Sep 29, 2008 at 1:40 PM, Anne van Kesteren [EMAIL PROTECTED] wrote:
Hmm, we went through this before I believe.
Yeah, we talked about this in the context of CSRF.
I thought the issue with Referer
was that it exposed path information, but I guess the problem with Origin is
that it
Incidentally, these issues are why Collin's proposal at the start of
this thread was to list send the origin of all the ancestor frames:
On Thu, Sep 25, 2008 at 12:57 PM, Collin Jackson
[EMAIL PROTECTED] wrote:
make it an X-Ancestor-Frame-Origin: http://www.evil.com; HTTP
request header. This
On Tue, Sep 30, 2008 at 2:44 AM, Michal Zalewski [EMAIL PROTECTED] wrote:
Well, so I agree. Yet, given the choice between:
1) Telling developers that they can't do any privileged gadgets safely
at all, not theirs, and for reasons that are hard to explain to
regular developers too -
On Tue, Sep 30, 2008 at 9:06 AM, Adam Barth [EMAIL PROTECTED] wrote:
The current proposal is to sent the Origin header for non-GET,
non-HEAD requests. The main reason not to send the header all the
time is that it raises similar privacy concerns as the Referer header,
which have caused the
On Tue, 30 Sep 2008, Robert O'Callahan wrote:
We can easily offer these developers the following options:
a) developers of privileged gadgets can whitelist domains that they trust to
not subvert the UI
How is this achieved? If I have a chat (talk to site owner using your
$foo chat account)
On Tue, Sep 30, 2008 at 11:14 AM, Michal Zalewski [EMAIL PROTECTED] wrote:
On Tue, 30 Sep 2008, Robert O'Callahan wrote:
We can easily offer these developers the following options:
a) developers of privileged gadgets can whitelist domains that they trust
to
not subvert the UI
How is
On Tue, 30 Sep 2008, Robert O'Callahan wrote:
If the chat gadget is configured to only talk to the site owner, how can it
be abused? I suppose the site owner can discover the chat nick of a visitor
who otherwise wouldn't want to disclose it. That's a risk that the chat
system developers might
On Tue, Sep 30, 2008 at 12:09 PM, Michal Zalewski [EMAIL PROTECTED] wrote:
On Tue, 30 Sep 2008, Robert O'Callahan wrote:
If the chat gadget is configured to only talk to the site owner, how can
it
be abused? I suppose the site owner can discover the chat nick of a
visitor
who otherwise
On Sat, 27 Sep 2008, Jim Jewett wrote:
uhm... that is exactly when involuntary actions are *most* likely.
It's not about merely clicking something accidentally - it's about
clicking at a very specific place, as intended by the attacker, to trigger
a very specific functionality on a targeted
On Sat, 27 Sep 2008, Jim Jewett wrote:
Yet opt-in proposals expect content authors to immediately add security
checks everywhere, which is considerably less realistic than having a
handful of webpages adjust their behavior, if we indeed break it (which I
don't think would be likely with the
On Sun, 28 Sep 2008, Michal Zalewski wrote:
If you have faith that all these places can be patched up because we
tell them so, and that these who want to would be able to do so
consistently and reliably - look at the current history of XSRF and XSS
vulnerabilities.
...and consequently, the
On Sun, 28 Sep 2008, Robert O'Callahan wrote:
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,
On Sun, Sep 28, 2008 at 10:52 PM, Michal Zalewski [EMAIL PROTECTED] wrote:
other browsers are getting cross-domain XMLHttpRequest headers
Using the W3C Access Controls spec, which I am suggesting to reuse here. If
you're not familiar with that spec, it's here:
On Sun, 28 Sep 2008, Robert O'Callahan wrote:
There is no way in the world that Microsoft would implement your option
3 in a security update to IE6.
Sure, I'm not implying this. I simply have doubts about any other major
security changes making it into MSIE8 or Firefox 3.
Cheers,
/mz
, September 28, 2008 11:53 AM
To: Robert O'Callahan
Cc: whatwg@lists.whatwg.org; Smylers
Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to
the current web
On Sun, 28 Sep 2008, Robert O'Callahan wrote:
Not really; minor versions usually have better uptake rates, thanks
On Mon, Sep 29, 2008 at 12:17 AM, Michal Zalewski [EMAIL PROTECTED] wrote:
On Sun, 28 Sep 2008, Robert O'Callahan wrote:
There is no way in the world that Microsoft would implement your option 3
in a security update to IE6.
Sure, I'm not implying this. I simply have doubts about any other
Elliotte Harold writes:
People want to get pictures, text, and other media from the web.
People want to play games and use some apps. Users don't care where
the media is loaded from. If it can be loaded form a single server,
then the users' needs are met.
I see no genuine user use cases
Kristof Zelechovski wrote:
In order to store guest media:
1. The mirror host would need a broadcasting licence.
2. The mirror host would have to support the encoder (if it supports dynamic
resolution adjustment).
3. If it is Flash, the player might refuse to play if loaded from a
different URL
Zelechovski
Cc: 'WHAT WG List'
Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to
the current web
Kristof Zelechovski wrote:
In order to store guest media:
1. The mirror host would need a broadcasting licence.
2. The mirror host would have to support the encoder
On Sun, Sep 28, 2008 at 12:41 AM, 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.
On Thu, 25 Sep 2008, Maciej Stachowiak wrote:
I meant, corner of the container, rather than actual document rendered
within.
Then can't you work around the restriction by scrolling the contents
inside the iframe and sizing it carefully? (One way to scroll an iframe
to a desired position is
On Thu, 25 Sep 2008 22:17:00 +0200, Collin Jackson [EMAIL PROTECTED]
wrote:
6) New cookie attribute: The httpOnly cookie flag allows sites to
put restrictions on how a cookie can be accessed. We could allow a new
flag to be specified in the Set-Cookie header that is designed to
prevent CSRF and
with UI redress vulnerabilities inherent to
the current web
6) Admit that iframes and 3rd party embedded content are broken by
design. Eliminate the iframe element completely, and set browsers to
*never* load content or communicate with any site except the primary URL
of the page. No 3rd party cookies
Kristof Zelechovski wrote:
Prohibiting third-party embedded content would disable media embedded in
blogs.
Absolutely false. The media simply needs to be served from the same host
the blog itself is. This is how almost all the media in my blogs works
today. What little content comes from a
On Fri, 26 Sep 2008, Maciej Stachowiak wrote:
Maybe I didn't read very well, but I don't see how the clause for UI action
optimizations would prevent what I described. Could you spell it out for me
please? It seems to me that the embedded iframes for iGoogle gadgets (or
similar) will indeed
Ozob the Great wrote:
The bandwidth cost of hosting video makes this option unworkable for
some blogs.
And yet someone's hosting that bandwidth today. This need not involve
any net increase in bandwidth. It would just involve a rejiggering of
hosting models.
--
Elliotte Rusty Harold
Harold
Sent: Friday, September 26, 2008 11:10 PM
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent to
the current web
Ozob the Great wrote:
The bandwidth cost of hosting video makes this option unworkable for
some blogs.
And yet someone's hosting
Michal Zalewski wrote:
I kinda assumed this suggestion was tongue-in-cheek, but if not -
banning cross-domain IFRAMEs to fix one flaw, without providing viable
methods for sandboxing untrusted same-origin content, would leave web
developers with no tools to deal with quite a few classes of
On Sat, Sep 27, 2008 at 9:19 AM, Elliotte Rusty Harold
[EMAIL PROTECTED] wrote:
I do think we have an existence proof that security in this realm is
possible. That's Java. Modulo some outright bugs in VMs (since repaired) the
default Java applet security model has worked and worked well since
On Fri, 26 Sep 2008, Elliotte Rusty Harold wrote:
It's tongue-in-cheek that I don't expect it to be adopted or seriously
considered (this year). It's not tongue-in-cheek in that I very much
wish it were adopted. That is, I think it's in the realm of the
desirable, not the possible.
Oh yup,
Robert O'Callahan wrote:
On Sat, Sep 27, 2008 at 9:19 AM, Elliotte Rusty Harold
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
I do think we have an existence proof that security in this realm is
possible. That's Java. Modulo some outright bugs in VMs (since
repaired) the
On Sat, Sep 27, 2008 at 11:55 AM, Elliotte Rusty Harold
[EMAIL PROTECTED] wrote:
As I said, it's an existence proof. Sun's inability to provide decent
developer tools (unlike Adobe) doesn't reflect on the capability of the
model.
That has nothing to do with it.
You're saying Java's
Robert O'Callahan wrote:
You're saying Java's security model is adequate for what people want to
do on the Web. I say that is unproven since people are not using Java on
the Web. *Why* they are not using Java on the Web is irrelevant.
Java's security model is absolutely adequate for what
Michal Zalewski wrote:
3) Add an on-by-default mechanism that prevents UI actions to be taken
when a document tries to obstruct portions of a non-same-origin
frame.
Something like focus-follows-mouse plus autoraise for IFRAMEs might
work.
--
Toby A Inkster
mailto:[EMAIL PROTECTED]
On Thu, Sep 25, 2008 at 10:24 AM, Michal Zalewski [EMAIL PROTECTED] wrote:
Other quick fixes are easy to come up with, but in general prove problematic
in many usage scenarios. Based on our internal conversations, we have a
number of proposals for approaches to how to address the issue, along
On Thu, 25 Sep 2008, Collin Jackson wrote:
6) New cookie attribute: The httpOnly cookie flag allows sites to
put restrictions on how a cookie can be accessed. We could allow a new
flag to be specified in the Set-Cookie header that is designed to
prevent CSRF and UI redress attacks. If a cookie
On Thu, Sep 25, 2008 at 1:46 PM, Michal Zalewski [EMAIL PROTECTED] wrote:
7) New HTTP request header: Browser vendors seem to be moving away from
same origin restrictions towards verifiable origin labels that let the
site decide whether two security origins trust each other. Recent examples
On Sep 25, 2008, at 10:24 AM, Michal Zalewski wrote:
3) Add an on-by-default mechanism that prevents UI actions to be taken
when a document tries to obstruct portions of a non-same-origin
frame.
By carefully designing the mechanism, we can prevent legitimate uses
(such as dynamic
On Sep 25, 2008, at 1:17 PM, Collin Jackson wrote:
On Thu, Sep 25, 2008 at 10:24 AM, Michal Zalewski [EMAIL PROTECTED]
wrote:
Other quick fixes are easy to come up with, but in general prove
problematic
in many usage scenarios. Based on our internal conversations, we
have a
number of
On Thu, 25 Sep 2008, Maciej Stachowiak wrote:
C) Treat a case where top-left corner of the IFRAME is drawn out of
a visible area (CSS negative margins, etc) as a special case of
being obstructed by the owner of a current rendering rectangle
(another IFRAME or window.top) and carry
On Fri, Sep 26, 2008 at 7:33 AM, Toby A Inkster [EMAIL PROTECTED]wrote:
Something like focus-follows-mouse plus autoraise for IFRAMEs might work.
I actually like this idea quite a lot. It would have to allow the IFRAME to
escape clipping (and other graphical effects) as well (except for
Other than sliding content over the top of the IFRAME, there are fun ways to
get exactly the appearance the attacker wants ... keep in mind when
designing a solution:
-- make the IFRAME opacity:0 (or 0.01) and draw whatever you want underneath
it
-- use SVG filter effects (in conjunction with SVG
On Fri, Sep 26, 2008 at 10:23 AM, Michal Zalewski [EMAIL PROTECTED] wrote:
I meant, corner of the container, rather than actual document rendered
within. If deals strictly with the frame beginning outside the current
viewport to hide some of its contents, but leave small portions of the UI
On Fri, 26 Sep 2008, Robert O'Callahan wrote:
Seems like this will create a really bad user experience. The user
scrolling around in the outer document will make IFRAMEs in it
mysteriously become enabled or disabled.
Well, to put this in perspective - we are talking about cross-domain
On Fri, Sep 26, 2008 at 12:27 PM, Michal Zalewski [EMAIL PROTECTED] wrote:
On Fri, 26 Sep 2008, Robert O'Callahan wrote:
Seems like this will create a really bad user experience. The user
scrolling around in the outer document will make IFRAMEs in it mysteriously
become enabled or disabled.
On Thu, Sep 25, 2008 at 4:08 PM, Ian Hickson [EMAIL PROTECTED] wrote:
form of experimental implementations. Personally I think the idea of
disabling the contents of a cross-origin iframe that has been partially
obscured or rendered partially off-screen is the best idea, but whether we
can
On Sep 25, 2008, at 3:23 PM, Michal Zalewski wrote:
On Thu, 25 Sep 2008, Maciej Stachowiak wrote:
C) Treat a case where top-left corner of the IFRAME is drawn out of
a visible area (CSS negative margins, etc) as a special case of
being obstructed by the owner of a current rendering
On Sep 25, 2008, at 8:07 PM, Maciej Stachowiak wrote:
On Sep 25, 2008, at 3:23 PM, Michal Zalewski wrote:
On Thu, 25 Sep 2008, Maciej Stachowiak wrote:
C) Treat a case where top-left corner of the IFRAME is drawn out of
a visible area (CSS negative margins, etc) as a special case of
78 matches
Mail list logo
