Re: [whatwg] Placeholder option for text input boxes

[Kristof Zelechovski]

I do not like this idea at all.  That is what LABEL is for, and disappearing
"it's so kewl" text is as annoying as BLINK and BGSOUND.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy Lyttle
Sent: Tuesday, September 30, 2008 2:20 AM
To: whatwg@lists.whatwg.org
Subject: [whatwg] Placeholder option for text input boxes

Re: [whatwg] Placeholder option for text input boxes

[Garrett Smith]

On Mon, Sep 29, 2008 at 5:20 PM, Andy Lyttle <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> I would like to see Apple's  adopted as an official
> standard, but there's one particular feature that would be easy to adopt
> without supporting the rest, and that's the "placeholder" option.
>  Currently, lots of sites are implementing placeholder text through a
> combination of creative CSS and JavaScript hacking, but each site has to
> reinvent the wheel, and very often the wheel gets reinvented badly (examples
> below).  Making it a standard feature of HTML would eliminate the need for
> all the extra scripting and improve accessibility, and consistent behavior
> would make a better user experience.
>
> The desired behavior is for the placeholder text to appear in the field with
> a gray color when the field is not focused and the value is empty.  Of
> course the meaning of "gray" is up to the browser.  The placeholder option
> was originally intended for search fields, but it's useful for other input
> types as well, and Safari already supports it on all text input fields.  The
> HTML simply looks like:
>
> 
>
> Here are a bunch of examples of sites that currently use JavaScript and CSS
> tricks in an attempt to simulate this behavior, to varying degrees of
> success:
>
> These use black placeholder text that disappears on focus but does not
> reappear on blur:


>
> As you can see, that's seven different behaviors, some of which are clearly
> not ideal, and all of which require JavaScript, which takes time to
> implement, test in multiple browsers, and debug.  Supporting the placeholder
> attribute (which is already implemented in one major browser) would solve
> all of these problems.
>
> Comments?
>

|placeholder| sounds a little like |alt|. Alt is a property and an
attribute on INPUT.

How to specify alternate text:
http://www.w3.org/TR/html401/struct/objects.html#adef-alt


> --
> Andy Lyttle
> [EMAIL PROTECTED]
>
>

Re: [whatwg] WebSocket websocket-origin

[Shannon]

Anne van Kesteren wrote:
What is the reason for doing literal comparison on the 
websocket-origin and websocket-location HTTP headers? Access Control 
for Cross-Site Requests is currently following this design for 
access-control-allow-origin but sicking is complaining about so maybe 
it should be URL-without- comparison instead. (E.g., then 
http://example.org and http://example.org:80 would be equivalent.)



I think the temptation to standardise features like access control 
defeats the point of websockets. Since things like access control and 
sessions can be readily implemented via CGI interfaces it seems implied 
that the whole point of websockets is to provide "lightweight" services. 
If the service actually needs something like this then the author can 
perform the check post-handshake using any method they feel like. I 
don't really feel strongly one way or the other about this particular 
header but I'm concerned about the slippery-slope of complicating the 
HTTP handshake to the point where you might as well be using CGI. Maybe 
the standard should simply recommend sending the header but make no 
requirement about how it is parsed. That way the service itself can 
decide whether the check is even necessary and if so whether it should 
be strict or loose or regex-based without the client automatically 
hanging up the connection.


Shannon

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Ian Hickson]

On Mon, 29 Sep 2008, Maciej Stachowiak wrote:
> On Sep 28, 2008, at 3:32 AM, Robert O'Callahan wrote:
> > 
> > I'm suggesting just reusing the Access Controls spec for that.
> > 
> > So for example, the server could say: 
> > Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes 
> > Access-Control-Allow-Origin: http://example.com
> 
> I think this is a really good proposal. It would allow Web sites to 
> place all content under a single uniform policy for access control, as 
> opposed to the state today where cross-site access depends on how the 
> resource is embedded.

I don't think this would really work for Google. Many widgets (e.g. the 
mapping widget) are expected to be placed on any site, but how could the 
widget provider know who is evil and who isn't? What about if an otherwise 
not evil site is compromised? (This happens regularly, especially with, 
e.g., sites with forum software or blog software.) We don't want a 
vulnerability in a widget host site to immediately allow this kind of 
attack on all the widgets that that site hosts.

Secondly, consider Google Image Search, or Reddit with its "open link with 
reddit toolbar" option, or any other site that allows arbitrary Web 
navigation in a frame or iframe while hosting some sort of toolbar content 
from its own page in another frame or container page. This option would 
mean that many sites would stop working with these containers, despite 
these containers not doing anything evil (there's no overlapping content, 
the user is fully aware of what's going on, etc).

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Maciej Stachowiak]

On Sep 28, 2008, at 2:15 PM, Robert O'Callahan wrote:

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  
major security changes making it into MSIE8 or Firefox 3.


As one of the people who makes these decisions, I can tell you that  
I'd be a lot more comfortable cramming option 1 into Firefox 3 or  
3.1 than option 3. Apart from the other reasons I've already raised,  
option 1, being much simpler and with few degrees of freedom, would  
take a lot less time to analyze and converge on a spec.


As one of the people who helps decide for Safari, I would agree that  
option 1 is a lot more likely to make it into a security update than  
option 3.


Regards,
Maciej

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Maciej Stachowiak]

On Sep 28, 2008, at 3:32 AM, Robert O'Callahan wrote:

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: http://www.w3.org/TR/access-control/


Now consider that "I-Do-Not-Want-To-Be-Loaded-Across-Domains" is  
also inherently incompatible with mashups, content separation,  
gadgets, etc, and there is a very vocal group of proponents and  
promotors for these technologies (which is why browser vendors are  
implementing cross-domain XMLHttpRequest to begin with). So we would  
probably rather want to say "I-Want-To-Be-Loaded-Only-By:  
".


I'm suggesting just reusing the Access Controls spec for that.

So for example, the server could say:
Same-Origin-Only-Unless-Access-Controls-Says-Otherwise: yes
Access-Control-Allow-Origin: http://example.com


I think this is a really good proposal. It would allow Web sites to  
place all content under a single uniform policy for access control, as  
opposed to the state today where cross-site access depends on how the  
resource is embedded.


Would "Require-Access-Control" be an adequate synonym for "Same-Origin- 
Only-Unless-Access-Controls-Says-Otherwise", on the assumption that  
same-origin access always satisfies access control?


Regards,
Maciej

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Maciej Stachowiak]

On Sep 26, 2008, at 2:19 PM, Elliotte Rusty Harold wrote:


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 major security issues.


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.


I am curious what issues you see with same origin content. They  
certainly exist, but I tend to feel those are orthogonal to the  
issues at hand, and subject for a separate discussion.


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 1.0 beta 1. (1.0 alpha 1 wasn't quite strict  
enough.) I have seen no security design flaws exposed in Java  
applets in over ten years. That's why I suspect duplicating Java's  
security policy in HTML is a safe way forward. I'm skeptical that  
anything less will suffice.


Java's security policy is also looser in some ways. For example, it  
allows the applet to connect to any port on the origin server. This  
has at times caused Java applets to be subject to vulnerabilities that  
did not affect plain HTML+JS+CSS (more recently than in the past 10  
years). The general Web same-origin policy considers the port as well  
as the host to be part of the origin.


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  
being secure in practice.


And finally, the key question for whether strict same-origin can work  
it not one of security but of functionality and usability. The trend  
in recent years has been for browsers to punch more controlled holes  
in the same-origin policy to fulfill the frequent desire of Web  
application developers to communicate with other servers from the  
client side. This is desirable so that "AJAX" apps (where most of the  
logic and functionality is client-side) can make use of third-party  
Web services APIs, in the same way that native apps can, without  
having to round-trip through their own server. I do not see this trend  
reversing any time soon.


In conclusion I think limiting the Web to 100% strict same-origin  
would not be desirable even in an ideal world where compatibility  
issues are not a concern.


I don't expect this to happen, however, because many large players  
are exploiting existing security design flaws in the web to do  
things they shouldn't be allowed to do in the first place,  
especially tracking users. Any scheme that limits the ability of  
advertisers and others to track users will be strenuously resisted.


For the record, neither Apple nor the WebKit project have any strong  
commercial interest in the ability of advertisers or others to track  
users.


Regards,
Maciej
 

Re: [whatwg] Placeholder option for text input boxes

[Maciej Stachowiak]

On Sep 29, 2008, at 5:20 PM, Andy Lyttle wrote:


Hi all!

I would like to see Apple's  adopted as an  
official standard, but there's one particular feature that would be  
easy to adopt without supporting the rest, and that's the  
"placeholder" option.  Currently, lots of sites are implementing  
placeholder text through a combination of creative CSS and  
JavaScript hacking, but each site has to reinvent the wheel, and  
very often the wheel gets reinvented badly (examples below).  Making  
it a standard feature of HTML would eliminate the need for all the  
extra scripting and improve accessibility, and consistent behavior  
would make a better user experience.


[... snip examples ...]

As you can see, that's seven different behaviors, some of which are  
clearly not ideal, and all of which require JavaScript, which takes  
time to implement, test in multiple browsers, and debug.  Supporting  
the placeholder attribute (which is already implemented in one major  
browser) would solve all of these problems.


Comments?


I would love to see the placeholder="" attribute (and, independently,  
) become standard parts of HTML5. We invented  
these extensions originally for non-Web content, but they seem useful  
for the Web and of interest to Web content authors.


Regards,
Maciej

[whatwg] Placeholder option for text input boxes

[Andy Lyttle]

Hi all!

I would like to see Apple's  adopted as an  
official standard, but there's one particular feature that would be  
easy to adopt without supporting the rest, and that's the  
"placeholder" option.  Currently, lots of sites are implementing  
placeholder text through a combination of creative CSS and JavaScript  
hacking, but each site has to reinvent the wheel, and very often the  
wheel gets reinvented badly (examples below).  Making it a standard  
feature of HTML would eliminate the need for all the extra scripting  
and improve accessibility, and consistent behavior would make a  
better user experience.


The desired behavior is for the placeholder text to appear in the  
field with a gray color when the field is not focused and the value  
is empty.  Of course the meaning of "gray" is up to the browser.  The  
placeholder option was originally intended for search fields, but  
it's useful for other input types as well, and Safari already  
supports it on all text input fields.  The HTML simply looks like:




Here are a bunch of examples of sites that currently use JavaScript  
and CSS tricks in an attempt to simulate this behavior, to varying  
degrees of success:


These use black placeholder text that disappears on focus but does  
not reappear on blur:

http://www.bestbuy.com/ top left, "Keyword or Item #"
http://www.blockbuster.com/ top right corner, "Movies, Actors,  
Directors"

http://www.cisco.com/ top right corner, "Search"
...and countless others (army.mil, navy.mil, af.mil, weather.com,  
weather.gov, kfc.com, dennys.com, napaonline.com, etc.)


These use gray placeholder text which reappears on blur, but text  
entered by the user is also gray:

http://www.myspace.com/ on the right, "Find Friends on MySpace" box
http://wordpress.com/ top right corner, "Search WordPress.com Blogs"

These use gray placeholder text, but text entered by the user is also  
gray, and the placeholder does not reappear on blur:

http://www.fedex.com/us/ top center, "Search"
http://www.cnet.com/ top center, "Search"
http://www.safeway.com/ top right, "Enter Keyword"

These use black user-entered text and gray placeholder text that  
reappears on blur, but user-entered text turns gray on blur too:

http://www.mapquest.com/ top right corner, "Search the Web"
http://digg.com/ top right corner, "Search Digg..."
http://www.gateway.com/ top right corner, "Search" (gray text is also  
italic)


This uses black user-entered text and gray placeholder text, but the  
placeholder text does not reappear on blur and user-entered text  
disappears on focus:

http://www.lenovo.com/us/en/index.html top right corner

These behave as I would expect, with black user-entered text and gray  
placeholder text that reappears on blur:

http://www.mapquest.com/beta left side, "Find a Business"
http://www.mcafee.com/us/ top right corner, "Search"
http://www.britannica.com/ top center, "Search Site..." (also has a  
cancel button)
http://www.filemaker.com/ top center, "Search FileMaker.com" (also  
has a cancel button)
http://www.apple.com/ top right corner, "Search" (also has a cancel  
button, uses AJAX for live searching)


These use black placeholder text, but otherwise behave as expected:
http://www.adobe.com/ top right corner, "Search Adobe.com..." (uses  
AJAX for live searching)

http://www.nbc.com/ top left corner, "search"
https://www.cia.gov/ top right corner, "Search"
http://us.blizzard.com/support/ top center, "Enter a word, phrase or  
solution ID"


As you can see, that's seven different behaviors, some of which are  
clearly not ideal, and all of which require JavaScript, which takes  
time to implement, test in multiple browsers, and debug.  Supporting  
the placeholder attribute (which is already implemented in one major  
browser) would solve all of these problems.


Comments?

--
Andy Lyttle
[EMAIL PROTECTED]

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Robert O'Callahan]

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 wouldn't want to disclose it. That's a risk that the chat
>> system developers might very well be willing to accept.
>>
>
> Assume you are logged in with Facebook, Google, or any other "common" party
> that provides general chat / calendar services or anything of that kind; and
> let's say this party permits site operators embed a gadget that shows every
> visitor a schedule of events advertised on a page overlaid on top of
> visitor's schedule (with the option to add these to your calendar, or edit
> your calendar data - it does not have to be read-only);


I don't see what's so terrible about showing the user's calendar and the
overlaid events inline, and having the "Add to Calendar" button open a new
page for confirmation. Note that GMail's "add to Google Calendar"
functionality already takes me to a new tab for confirmation, even though
presumably Google could avoid that if they wanted to.

or gives you the opportunity to chat, review and annotate documents, or
> otherwise collaborate with site owners using similar facilities provided by
> gadget operator in their third-party domain, in your capacity as the user
> logged in with said services.


If these services are limited to specific chat channels or documents that
are associated with the site owner (which can be ensured by the gadget
operator), then I don't see a problem; site owner "UI redress" would be
pointless.


>  That's a terrible user experience, by most accounts, and goes against the
>>> concept of a gadget; I believe it is often avoided at all costs except
>>> when
>>> absolutely necessary (e.g., login, where the user needs the opportunity
>>> to
>>> verify URL, SSL status, etc).
>>>
>>
>> Maybe we can make it a better user experience, for example, by allowing
>> the new window/tab to appear as a new pane at the top or bottom of the
>> existing tab. That would nicely handle your chat example, IMHO.
>>
>
> Possibly.
>

Think it over :-)

Rob
-- 
"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
53:5-6]

Re: [whatwg] Canvas performance issue: setting colors

[Oliver Hunt]

I think the canvas api should get 2 new methods:

 CanvasColor createRGBAColor(in float r, in float g, in float b, in  
float a)
 CanvasColor createHSLAColor(in float h, in float s, in float l, in  
float a)




WebKit already has a non-standard function -- setFillColor(r, g, b, a)  
-- that provides a faster mechanism to set the colour, however we  
believe we can rather easily improve the performance of the standard  
fillStyle, strokeStyle properties and just have not yet gotten round  
to it.  Until we have improved this I would be hesitant to go around  
adding entirely new object types (especially canvas specific ones).


--Oliver

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Michal Zalewski]

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 very well be willing to accept.


Assume you are logged in with Facebook, Google, or any other "common" 
party that provides general chat / calendar services or anything of that 
kind; and let's say this party permits site operators embed a gadget that 
shows every visitor a schedule of events advertised on a page overlaid on 
top of visitor's schedule (with the option to add these to your calendar, 
or edit your calendar data - it does not have to be read-only); or gives 
you the opportunity to chat, review and annotate documents, or otherwise 
collaborate with site owners using similar facilities provided by gadget 
operator in their third-party domain, in your capacity as the user logged 
in with said services.


[If the visitor is not logged in, such a gadget would not display, or 
would offer a login link that pops up a new https:// window.]


This is not a very far-fetched scenario - I've seen designs of this type - 
and they are very much possible and safe to arrange without disclosing any 
user-specific information to the page that embeds said gadgets. The only 
security problem arises with UI redress flaws; so it would be nice to 
offer viable alternatives for such applications, too.



That's a terrible user experience, by most accounts, and goes against the
concept of a gadget; I believe it is often avoided at all costs except when
absolutely necessary (e.g., login, where the user needs the opportunity to
verify URL, SSL status, etc).


Maybe we can make it a better user experience, for example, by allowing 
the new window/tab to appear as a new pane at the top or bottom of the 
existing tab. That would nicely handle your chat example, IMHO.


Possibly.

/mz

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Robert O'Callahan]

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 this achieved? If I have a chat ("talk to site owner using your $foo
> chat account")


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 very well be willing to accept.

or calendar overlay ("see scheduled events overlaid on your calendar")
> gadget that is to be embedded freely by third-parties,


If it's read-only, again, what's the risk? The user might want to interact
with the IFRAME to scroll and search, but even if those are spoofed, there's
no way for the container to abuse this, as far as I can tell.

I understand there are more interesting examples, but these ones don't seem
to make your case.


>  c) spawn new windows/tabs to perform or confirm privileged operations
>>
>
> That's a terrible user experience, by most accounts, and goes against the
> concept of a gadget; I believe it is often avoided at all costs except when
> absolutely necessary (e.g., login, where the user needs the opportunity to
> verify URL, SSL status, etc).
>

Maybe we can make it a better user experience, for example, by allowing the
new window/tab to appear as a new pane at the top or bottom of the existing
tab. That would nicely handle your chat example, IMHO.

Rob
-- 
"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
53:5-6]

[whatwg] Canvas performance issue: setting colors

[Sjoerd Visscher]

Hi,

With the increasing speed of javascript engines, some other  
performance issues are starting to become apparent. Take this demo for  
example:


http://playground.q42.nl/animatie/blobs/sjoerd/blobscolor.html

A large percentage of the time goes into building color strings for  
setting the strokeStyle, which the browser then has to take apart  
again. This is a very unnecessary performance hit. (Btw, on my Mac  
this runs faster under Google Chrome in VMware than natively in the  
latest Webkit nightly.)


I think the canvas api should get 2 new methods:

  CanvasColor createRGBAColor(in float r, in float g, in float b, in  
float a)
  CanvasColor createHSLAColor(in float h, in float s, in float l, in  
float a)


CanvasColor objects could be opaque, or maybe they have a toString  
method that returns the CSS serialization. The strokeStyle, fillStyle  
and shadowColor attributes should accept these objects, and probably  
the addColorStop method as well. Using CSS color strings should still  
work obviously. On getting these attributes the serialization must  
still be returned like it is now.


greetings,
--
Sjoerd Visscher
[EMAIL PROTECTED]

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Michal Zalewski]

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") or calendar overlay ("see scheduled events overlaid on 
your calendar") gadget that is to be embedded freely by third-parties, and 
offers a "privileged" UI - even if I require sites to pre-register or 
otherwise build a whitelist of these untrusted domains, I have no 
assurance they would play nice.



b) privileged gadgets can be offered to the world as long as the IFRAME's
own UI is not trusted. For example, gadgets whose purpose is to offer a
postMessage API to untrusted container pages would be just fine.


Sure, but then it makes the model drastically different, and suitable for 
different uses (many privileged gadgets may specifically not want to 
disclose any presented information to the top level page).



c) spawn new windows/tabs to perform or confirm privileged operations


That's a terrible user experience, by most accounts, and goes against the 
concept of a gadget; I believe it is often avoided at all costs except 
when absolutely necessary (e.g., login, where the user needs the 
opportunity to verify URL, SSL status, etc).


Cheers,
/mz

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Robert O'Callahan]

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 Referer header to be suppressed a non-trivial
> fraction of the time.
>

This is why it would be helpful to also support a "don't load me across
origins" header sent by the server.

Rob
-- 
"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
53:5-6]

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Robert O'Callahan]

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 - and pretending that the problem does not
> exist while people continue to depend on the unsafe logic (because
> whether we like it or not, seems that gadgets, mashups, and other
> methods of tightly integrating various applications and data sources
> on client side is here to stay),
>

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
b) privileged gadgets can be offered to the world as long as the IFRAME's
own UI is not trusted. For example, gadgets whose purpose is to offer a
postMessage API to untrusted container pages would be just fine.
c) spawn new windows/tabs to perform or confirm privileged operations
d) mix of strategies ... for example, gadgets could offer privileged UI to
trusted container pages, but for untrusted containers, attempts to use the
privileged UI would spawn a separate window/tab to perform the operation

We might also be able to help by extending the browser UI, for example by
supporting extra panes like the old Netscape sidebar UI (but better). But to
explore that further, I'd want to better understand the use cases that are
not served by a) b) c) or d) above.

I honestly think that, compared to an extremely complex, mysterious and
ever-changing set of UI threat mitigation strategies, which will inevitably
diverge across browsers and across browser versions and will constantly
interfere with the user experience, the above approach will be actually end
up more attractive to developers.

Rob
-- 
"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
53:5-6]

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Adam Barth]

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 header could be a list of all the origins that
> are ancestors of the frame that triggered the request. If the site
> decides it does not like the ancestor frame origin it could reject the
> request. This could be added as a property of MessageEvent as well to
> detect client-side UI redress attacks.

This proposal blocks the attack after the user clicks the bad button
(instead of when the bad site tries to load the good site in a frame).
 The proposal works in the cases below because the attacker's frame is
one of the ancestor frames when the "clickjack" click occurs.  (The
proposal is the visual analog of "stack inspection" in other systems.)

Adam


On Mon, Sep 29, 2008 at 1:52 PM, Adam Barth <[EMAIL PROTECTED]> wrote:
> 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 reveals the intranet server name?
>
> The query string and the path are probably the most privacy-sensitive.
>  Yes, the concern is revealing the name of an intranet server.  Most
> names are probably innocuous (like www, hr, or wiki), but there are
> others that might be an issue (like secretproject).  It's hard for me
> to evaluate how concerning this privacy leak is.
>
>> On the other hand, for the
>> not-link following case how common is it for intranet applications to load
>> images and resources cross-site?
>
> I don't have numbers to back this up, but my guess is that hyperlinks
> are far-and-away the most predominant.
>
> For CSRF, it doesn't make sense to send the Origin header for some
> kind of GET requests but not for others (the attacker will just use
> the method that doesn't send the header).  For UI redress /
> clickjacking, the attacker can make the request using hyperlinks also.
>  For example:
>
> 1) http://attacker.com/ embeds a frame to http://attacker.com/ready
> 2) http://attacker.com/ready has a hyperlink to http://victim.com/
> that gets clicked by JavaScript (say via the click() method).
>
> Keep in mind, that the attacker can often launder the IFRAME request
> through a respected third-party.  For example, the image search
> features offered by Live.com, Google, and Yahoo all happily create
> IFRAMES to a URL of the attacker's choice.
>
> Adam
>

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Adam Barth]

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 reveals the intranet server name?

The query string and the path are probably the most privacy-sensitive.
 Yes, the concern is revealing the name of an intranet server.  Most
names are probably innocuous (like www, hr, or wiki), but there are
others that might be an issue (like secretproject).  It's hard for me
to evaluate how concerning this privacy leak is.

> On the other hand, for the
> not-link following case how common is it for intranet applications to load
> images and resources cross-site?

I don't have numbers to back this up, but my guess is that hyperlinks
are far-and-away the most predominant.

For CSRF, it doesn't make sense to send the Origin header for some
kind of GET requests but not for others (the attacker will just use
the method that doesn't send the header).  For UI redress /
clickjacking, the attacker can make the request using hyperlinks also.
 For example:

1) http://attacker.com/ embeds a frame to http://attacker.com/ready
2) http://attacker.com/ready has a hyperlink to http://victim.com/
that gets clicked by JavaScript (say via the click() method).

Keep in mind, that the attacker can often launder the IFRAME request
through a respected third-party.  For example, the image search
features offered by Live.com, Google, and Yahoo all happily create
IFRAMES to a URL of the attacker's choice.

Adam

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Anne van Kesteren]

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 Referer header to be suppressed a non-trivial
fraction of the time.

Sending the Origin header more often is better for security, but it is
a gamble.  If we decide to send it too often, users/network operators
will just suppress the header and we won't have improved the
situation.  Sending the header for  POSTs seems like a clean
design point because sites don't POST to untrusted sites nearly as
often as they hyperlink to them.


Hmm, we went through this before I believe. 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? On the other hand, for  
the not-link following case how common is it for intranet applications to  
load images and resources cross-site?



--
Anne van Kesteren

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Adam Barth]

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.

Sending the Origin header more often is better for security, but it is
a gamble.  If we decide to send it too often, users/network operators
will just suppress the header and we won't have improved the
situation.  Sending the header for  POSTs seems like a clean
design point because sites don't POST to untrusted sites nearly as
often as they hyperlink to them.

Adam


On Mon, Sep 29, 2008 at 5:20 AM, Michal Zalewski <[EMAIL PROTECTED]> wrote:
> 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  POST
>> requests.
>
> Yup, I mean the non-XMLHttpRequest "Origin" header as proposed / implemented
> by Adam Barth and Collin Jackson for generic POSTs (though I might be not
> doing the implementation justice, so it's probably best for them to chime
> in).
>
> /mz
>

[whatwg] WebSocket websocket-origin

[Anne van Kesteren]

What is the reason for doing literal comparison on the websocket-origin  
and websocket-location HTTP headers? Access Control for Cross-Site  
Requests is currently following this design for  
access-control-allow-origin but sicking is complaining about so maybe it  
should be URL-without- comparison instead. (E.g., then  
http://example.org and http://example.org:80 would be equivalent.)



--
Anne van Kesteren

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Michal Zalewski]

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 thought over the weekend, my conclusion
is that this basically isn't doable - simply because it is a UI issue,
UI is all about communicating to end users and the likelyhood of
finding a solution that communicates the complexity of this in a way
users will understand is practcally 0.


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 - and pretending that the problem does not
 exist while people continue to depend on the unsafe logic (because
 whether we like it or not, seems that gadgets, mashups, and other
 methods of tightly integrating various applications and data sources
 on client side is here to stay),

...and...

  2) Implementing a kludge that does not severely and inherently degrade
 user experience, whilst giving developers at least some security
 that they should have in the first place (most of the security
 problems they are dealing with these days can be tracked back to
 poor or uncoordinated security design decisions in the early days
 of the Web),

I would be kinda willing to side with 2, which is why we came up with the 
kludgy proposal #3 to begin with. It's ugly, it's not perfect, it may 
require multiple workarounds to account for various scenarios, but it's 
the only way to tackle the UI problem we could think of. It also has a 
chance of working in a reasonably seamless manner if carefully reviewed 
and done right, although it might be a bumpy ride.


Not presenting users with overly complex choices or failure scenarios is a 
noble goal, but realistically, it's not how web browsers work these days, 
and so when applied selectively, it might be not the strongest argument 
possible.


As of now, understanding browser settings and error / warning / prompt 
messages requires a fair dose of expertise and experience, and it is 
extremely difficult to operate these applications without this knowledge. 
Some of the ongoing efforts improve this a bit (for example, browsers 
moving away from cryptic SSL security prompts to cryptic interstitials), 
other efforts take us a step back (for example, yellow "security 
notification" bars that are fully spoofable by web pages, and not properly 
anchored into browser chrome).


The idea I liked most was a sort of "automatically raise IFRAMEs to 
topmost z-index when focused" combined with some way to temporarily 
flash the address - but IMO it's not doable because we'll mess up the UI 
of existing solutions in unexpected ways, and users don't understand 
URLs and have a quite fuzzy understanding of the basic "different site" 
concept.


Yup. Plus, it leaves some open questions. Do we simply raise an IFRAME 
when clicked? If yes, the harm might be already done. Do we require 
Eolas-patent-style click-to-activate? If yes, we might seriously annoy 
operators of some IFRAME-based advertisement systems. Do we raise the 
frame just on mouseover? This would result in confusing flickering and 
page layout changes, would mess up drop-down menus expanded over 
different-origin document windows, etc.


Cheers,
/mz

Re: [whatwg] Dealing with UI redress vulnerabilities inherent tothe current web

[Kristof Zelechovski]

I am not sure I have understood Robert correctly but it seems obvious to me
that if a site does not want to reveal its origin it cannot apply for a
tighter cooperation; it will just be treated as any other site in the wild.
And it is better not to rely on the user agent to do the right thing if
possible.

Chris

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan
Sent: Monday, September 29, 2008 11:33 AM
To: Hallvord R M Steen
Cc: whatwg@lists.whatwg.org; Michal Zalewski; Smylers
Subject: Re: [whatwg] Dealing with UI redress vulnerabilities inherent tothe
current web

 

That's good to have and we should definitely do it, but there are a couple
of reasons "Same-Origin-Only-Unless-

Access-Controls-Says-Otherwise" would be useful as well:
-- a bit simpler to implement on the server
-- for privacy reasons some UAs in some situations might not want to expose
the origin to the IFRAME's server; allowing the origin check to happen on
the client would handle that

 

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Hallvord R M Steen]

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 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 thought over the weekend, my conclusion
is that this basically isn't doable - simply because it is a UI issue,
UI is all about communicating to end users and the likelyhood of
finding a solution that communicates the complexity of this in a way
users will understand is practcally 0. The idea I liked most was a
sort of "automatically raise IFRAMEs to topmost z-index when focused"
combined with some way to temporarily flash the address - but IMO it's
not doable because we'll mess up the UI of existing solutions in
unexpected ways, and users don't understand URLs and have a quite
fuzzy understanding of the basic "different site" concept.

I know where you are coming from and hope a UI genius proves me wrong. :)

-- 
Hallvord R. M. Steen

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Michal Zalewski]

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  POST requests.


Yup, I mean the non-XMLHttpRequest "Origin" header as proposed / 
implemented by Adam Barth and Collin Jackson for generic POSTs (though I 
might be not doing the implementation justice, so it's probably best for 
them to chime in).


/mz

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Anne van Kesteren]

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  
probably need to be modified to include "Origin" header on SRC= GET  
requests on IFRAME / EMBED / OBJECT / APPLET.


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  
 POST requests.



--
Anne van Kesteren

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Michal Zalewski]

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 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 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, so I think we need - or well, should - tackle this aspect 
separately if this is the consensus for now.


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 probably 
need to be modified to include "Origin" header on SRC= GET requests on 
IFRAME / EMBED / OBJECT / APPLET.


Extending the scheme to include SCRIPT would also cover script-inclusion 
attacks; extending it to all automated navigation (SRC=, REL=, scripted 
form submissions and location updates, etc) would prevent a broader set of 
XSRF and XSS attacks than the original proposal, but that's purely 
optional. But the bottom line is, there are some extra birds we could hit 
with that stone.



Sites may want to use any of several policies in a "somebody framed
me" situation. For example, these are all policies a site may want to
deploy:

1. nobody may frame my content
2. selected sites only may frame my content
3. anyone may frame my content but not re-use an existing session
4. anyone may frame my content


As noted, one important scenario which we do not account for is "5. anyone 
may iframe my content, but I want my UI not to get clobbered". This would 
realistically be the expectation for almost any privileged / authenticated 
gadget to be embedded on third-party pages.


Cheers,
/mz

Re: [whatwg] WebSocket support in HTML5

[Philipp Serafin]

On Sat, Sep 27, 2008 at 12:58 PM, Kristof Zelechovski
<[EMAIL PROTECTED]> wrote:
> If you are in control of the server, you can simulate datagram sockets with
> one-shot controlled sockets

I do not agree with Richard at all, but I have to play devil's
advocate here because I think such a simulation would be pretty
useless.
After all, more or less the only situation you'd want to use UDP
outside a LAN is when TCP doesn't fit your needs, e.g. because the
flow control does more harm than good to your use-case or because your
peers have not enough processing power for a full TCP implementation.
Simulating UDP via TCP would pretty much combine the disadvantages of
both protocols.
Also, you already need a full roudtrip to initiate a TCP connection, a
second one to perform the WS handshake and a third one to close the
connection. Data not taken into account. You can hardly repeat that
for every datagram you want to send.

That out of the way, I think the "structure in content" approach is
preferable because in the end it makes the whole feature easier to use
and accessible to a much broader range of web authors. Because a WS
stream has standardized metadata and delimiters, you can easily build
a generic framework that processes those parts for you.
This is especially important if you DON'T have full control over the
server, which I believe is the case for the majority of smaller sites
that use a shared hosting solution. Those hosters usually don't give
their clients access to the underlying processes at all. All the
clients can do is upload static files and script files that get
executed in a restricted environment. It's really hard to integrate
pure, persistent connections into such a setup. With WS, a hoster
could for example have a demon listen to all incoming WS connections
and call the client's scripts whenever a data frame has been received.
In short, it's much easier for them to manage persistent connections
if there is a standardized structure. And if it's easier for them,
hopefully the support for this feature will grow.

As for the restriction of unicode data, of course we could just use an
octet counting mechanism like HTTP does instead of a fixed delimiter.
This would allow arbitrary data inside the WS frames. On the other
hand, this might make it easier to spoof existing protocols. Would the
benefits of this outweigh the risks?

Note that it was a conscious design decision to make WS incompatible
with existing protocols, because the risk for misuse is too great.

If you need your web app to inerac with a specific service, it should
be easy to write a generic proxy that does the handshake, strips out
the frame marks and transforms the data.

Also, it's not like the other technologies would vanish all of a
sudden. If you have sufficient control over your server, you can STILL
use Java or Flash sockets.

Regards,
Philipp Serafin

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Robert O'Callahan]

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:
>
> Sites may want to use any of several policies in a "somebody framed
> me" situation. For example, these are all policies a site may want to
> deploy:
>
> 1. nobody may frame my content
> 2. selected sites only may frame my content
> 3. anyone may frame my content but not re-use an existing session
> 4. anyone may frame my content
>
> Giving the site an "Origin: http://www.example.com"; HTTP header in the
> intial request lets the backend implement any of these policies.
> Instead of responding with a payload that always includes some variant
> of the proposed "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes"
> header, the site can send or redirect to a framebreaking "embedding
> forbidden" page for policy #1. It can do so selectively based on
> origin site and/or requested content for policy #2. It can kill
> existing cookies, void session and set new origin-specific cookies for
> policy #3.)
>

That's good to have and we should definitely do it, but there are a couple
of reasons "Same-Origin-Only-Unless-Access-Controls-Says-Otherwise" would be
useful as well:
-- a bit simpler to implement on the server
-- for privacy reasons some UAs in some situations might not want to expose
the origin to the IFRAME's server; allowing the origin check to happen on
the client would handle that

IMO the only UI precaution we can/should do if possible is to make
> transparent IFRAMEs "transparent to events" - basically un-focusable.
>

If you check for opacity:0, I can use opacity:0.01. At what level of opacity
would the IFRAME become transparent to events? And it would leave a whole
lot of other attacks wide open. So I don't think it's worth doing anything
here.

Rob
-- 
"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
53:5-6]

Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Hallvord R M Steen]

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 of an IFRAME is to blend in seamlessly
with the rest of the parent site's content. I think it is just about
impossible to come up with a UI that will violate this "meshability"
of the IFRAME in a non-intrusive way AND signal clearly to Mr. Newbie
User that this part of the page comes from another site than the rest
and should be given a different level of "trust".

Plainly: I believe there are no acceptable UI solutions to this problem.

What follows is my personal opinion which I've also explained on
internal Opera mailing lists (I've seen some people agree but I want
to make it clear that I'm not expressing any developer consensus or
expressing "Opera's point of view" just yet).

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:

Sites may want to use any of several policies in a "somebody framed
me" situation. For example, these are all policies a site may want to
deploy:

1. nobody may frame my content
2. selected sites only may frame my content
3. anyone may frame my content but not re-use an existing session
4. anyone may frame my content

Giving the site an "Origin: http://www.example.com"; HTTP header in the
intial request lets the backend implement any of these policies.
Instead of responding with a payload that always includes some variant
of the proposed "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes"
header, the site can send or redirect to a framebreaking "embedding
forbidden" page for policy #1. It can do so selectively based on
origin site and/or requested content for policy #2. It can kill
existing cookies, void session and set new origin-specific cookies for
policy #3.)

IMO the only UI precaution we can/should do if possible is to make
transparent IFRAMEs "transparent to events" - basically un-focusable.


-- 
Hallvord R. M. Steen