Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Boris Zbarsky]

On 12/1/16 1:41 AM, Chris Holland wrote:

I think the devil would be in implementation detail. Slapping a
"rel/noopener" attribute on a specific link is very deterministic and
straightforward from a logic standpoint  Whichever window was created
from this link can't control the parent.


It's a much stronger guarantee.  The guarantee is that the parent and 
the created window have no way to see each other at all.  Neither one 
can read any state from the other, or even know the other one exists.


In particular, the idea is that rel="noopener" allows the new window to 
be opened in a separate process, or even a separate browser if desired. 
The only difference between it and the user copying the link and then 
pasting it into some other tab or other program is that a referrer 
header is sent.


Note that this guarantee makes for fairly simple implementation.

Having a header that opts in all links targeted at anything other than 
_parent, _self, and _top have the noopener behavior would be doable. 
Having a header that opts in some links based on the origin of the link 
href or something would probably be doable.  Having a header that tries 
to add some sort of new mode wherein the two windows _can_ see each 
other but can't do some things that they can normally do would be a 
snake pit of complexity that is best avoided.


-Boris

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Chris Holland]

I guess this issue was discussed at the following thread on chromium.org,
with comment #10 offering the more interesting exploit vector that seems to
happen on sites with user-generated content (UGC):

https://bugs.chromium.org/p/chromium/issues/detail?id=168988#c10

... and Comment 11 right after it:

https://bugs.chromium.org/p/chromium/issues/detail?id=168988#c11 <--
although i guess this would only apply if the link was target="_blank" such
that it does open in a new window, which is pretty common practice on UGC
sites anyway.

... and as Michael pointed out, this bug got closed on the count of
rel="noopener"

I get Michael's point that securing an existing site with UGC content is
going to be a somewhat painful proposition, although one could craft a
one-liner piece of javascript which would use the DOM to add or augment the
"rel" attribute to anchors. This should be easily done on Wordpress sites
as a template footer, or in the header on document ready. This would
alleviate your having to modify the HTML code for every single link, as I
too would hate to liter my anchors with more unsightly attributes.

I remember using window.opener to change a parent's location since the late
90's, this behavior has been around for a *long time*, so i could see why
browser makers would be more than a little reluctant to "deny by default"
and require site makers to add an extra http header to "allow" the behavior.

But if I understand Michael's proposed behavior correctly, we would allow
sites to set a header as such:

X-Child-Context-Control-Allow-Domains: *foo.com , bar.net
 * <-- some sites are allowed
X-Child-Context-Control-Allow-Domains: *none* <-- no sites are allowed
X-Child-Context-Control-Allow-Domains: ** *<-- this header is unnecessary
because it is the default behavior or all browsers

... *XCCCAD *for short (for lack of snazzier acronym)

==> when this header is not present, the current behavior applies, which
means most sites are "insecure by default".
==> sites who do wish to secure themselves could set the above header and
browsers would forbid child windows from controlling parent windows, aside
from listed exceptions.

This would:

0) complement, not replace rel="noopener"
1) retain current backward compatibility
2) allow sites to secure themselves more globally with a simple .htaccess
rule. (instead of having to modify their anchors manually or via the DOM)

The above proposition might remind you of CORS:
Access-Control-Allow-Origin: *
http://enable-cors.org/server.html

However the above proposed behavior would be exactly opposite to that of
the CORS behavior, and I think that it makes perfect sense, because the
situation we're trying to address, is the exact opposite of the situation
that the CORS behavior was looking to address:

- Sites are "secure by default" in that they don't allow their content to
be accessed by a browsing context outside of their host/domain, as this is
every browser's default behavior.
- Adding the CORS header enables sites to make themselves less secure by
instructing browsers that other sites can load their content via, say, an
XmlHttpRequest.

I think the devil would be in implementation detail. Slapping a
"rel/noopener" attribute on a specific link is very deterministic and
straightforward from a logic standpoint  Whichever window was created
from this link can't control the parent.

In the case of an *XCCCAD *header we need to specify when it would be in
effect. And I think it might be as simple as "it applies to all windows
opened from the HTML document which was served with this header in the
response headers".








On Wed, Nov 30, 2016 at 9:33 PM, Michael A. Peters 
wrote:

> On 11/30/2016 06:21 PM, Michael A. Peters wrote:
>
>> On 11/30/2016 05:23 PM, Ian Hickson wrote:
>>
>>> On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters
>>> 
>>> wrote:
>>>
>>>
 Right now the specification for window.opener() is seriously insecure,
 allowing for cross-domain script access by default.


>>> I believe that's a bit of an overstatement. There are certainly risks
>>> involved in window.opener (they're briefly discussed in the spec itself),
>>> but it doesn't remove the origin checks.
>>>
>>>
>>>
>> Actually it does. Site A can link to Site B on a completely different
>> domain and JavaScript on Site B has access to the window for Site A and
>> can change the URL and other things.
>>
>>
> Here is easy demo showing the blatant cross-domain scripting vulnerability.
>
> 
> 
>   
> Test target link
>   
>   
> https://bar.net/b.html; target="_blank">link to different
> domain
>   
> 
>
> 
> 
>   
> Test window.opener
> 
> if (window.opener && !window.opener.closed)
>   opener.location = 'http://www.example.org/'
> 
>   
>   
> The page on foo.com will have changed to http://www.example.org/
> because 

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

On 11/30/2016 06:21 PM, Michael A. Peters wrote:

On 11/30/2016 05:23 PM, Ian Hickson wrote:

On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters

wrote:



Right now the specification for window.opener() is seriously insecure,
allowing for cross-domain script access by default.



I believe that's a bit of an overstatement. There are certainly risks
involved in window.opener (they're briefly discussed in the spec itself),
but it doesn't remove the origin checks.




Actually it does. Site A can link to Site B on a completely different
domain and JavaScript on Site B has access to the window for Site A and
can change the URL and other things.



Here is easy demo showing the blatant cross-domain scripting vulnerability.



  
Test target link
  
  
https://bar.net/b.html; target="_blank">link to 
different domain

  




  
Test window.opener

if (window.opener && !window.opener.closed)
  opener.location = 'http://www.example.org/'

  
  
The page on foo.com will have changed to http://www.example.org/ 
because this page had script access to that window. Obvious very serious 
phishing concern, and probably other concerns

  

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Michael A. Peters]

On 11/30/2016 05:23 PM, Ian Hickson wrote:

On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters 
wrote:



Right now the specification for window.opener() is seriously insecure,
allowing for cross-domain script access by default.



I believe that's a bit of an overstatement. There are certainly risks
involved in window.opener (they're briefly discussed in the spec itself),
but it doesn't remove the origin checks.




Actually it does. Site A can link to Site B on a completely different 
domain and JavaScript on Site B has access to the window for Site A and 
can change the URL and other things.





The reason they refuse to properly address the issue is because it would
break OAuth.



I'm not sure who "they" is here, but since this is the first this topic has
come up on this list, would you mind providing us with some background?


Yes, I apologize, this was written in frustration and I should have 
calmed down.


Browsers are implementing rel="noopener" as a fix. A wrong fix, I have 
never heard of an attribute on an element being used to define script 
security for a window but that's how it is being addressed.


It is a fix that is not ideal. Archived web pages won't have the fix, 
and anchors in web applications are created by many different processes 
and plugins - both when the page is served and via ajax after the page 
the served - sometimes by the main web application and sometimes by a 
plugin. It is simply not realistic to ask web applications to make sure 
each use of an anchor with a target attribute is accompanied by a 
rel="noopener" attribute in order to be secure.


People at browsers I spoke with said they can only implement what the 
WhatWG specifies, and the rel="noopener" is the specified solution.


So I went to the WhatWG github page, found an open issue on noopener and 
contributed my thoughts. Was told I was off topic, and not to derail it.


So I started a new issue asking to deprecate rel="noopener" and replace 
it instead with a header that websites who want to allow window.opener 
to modify them including a whitelist of domains that could use it.


The issue was very quickly closed without any discussion based upon the 
issue of backwards compatibility. That was more important that fixing 
the insecure spec.


When digging to try and find out what was so important, a link to 
another topic was given where it turns out OAuth is the application that 
makes heavy use of window.opener


So I then came up with a different suggestion, one that doesn't break 
backwards compatibility, but instead allows a webmaster to send a header 
specifying what domains (if any) to whitelist. No header and the current 
behavior would be retained, but it would allow sites to secure their 
pages from window.opener() without having to add a rel tag to every link 
- a simply .htaccess directive could serve the header.


Again with absolutely no discussion the issue was immediately closed by 
a Google employee (and I know Google is heavily invested in OAuth) 
claiming that CSP is the right place for that.


But as much as I personally love CSP, virtually every webmaster I have 
talked to who has tried it has abandoned it because it was too difficult 
for them to implement without problems that then take hours to figure 
out. It apparently can be particularly difficult to configure on 
WordPress sites or sites that use Google Adsense or Analytics.


So Content Security Policy isn't the right place.

It is very frustrating to have such a bad security flaw that is being 
kept around because OAuth depends upon the flaw and have any attempt to 
have the specification fixed in a sane reasonable way immediately closed 
on the WhatWG github page.


And I confess, I'm not exactly a people person as it is, but it just 
really felt like they didn't care about the issues and had absolutely no 
interest in a solution that makes the web safer for users.


That's the history.

Something needs to be done, relying upon websites adding rel="noopener" 
to every case of not realistic and even many websites that try will fail.


But a header can be adding in one line to a .htaccess file and served 
with every web page. It's the right solution, the secure solution.


Whether the header is required by sites that want to allow window.opener 
or required by sites that want to block it - I don't really care, but a 
header is the right solution and a rel tag is just so conceptually 
broken I don't know how that even was accepted.


Thank you for your time, I apologize for the tone of my earlier post.

[whatwg] window.opener security issues (Was: WhatWG is broken)

[Ian Hickson]

On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters 
wrote:

>
> Right now the specification for window.opener() is seriously insecure,
> allowing for cross-domain script access by default.
>

I believe that's a bit of an overstatement. There are certainly risks
involved in window.opener (they're briefly discussed in the spec itself),
but it doesn't remove the origin checks.



> The reason they refuse to properly address the issue is because it would
> break OAuth.
>

I'm not sure who "they" is here, but since this is the first this topic has
come up on this list, would you mind providing us with some background?

For example, could you describe the security risk? How does it break OAuth?
Can you give an example of a page affected by this?

If there's a particular github issue where these topics have already been
discussed, then if you would like the broader WHATWG community to be aware
of these issues then I recommend linking to that issue in your e-mail to
the list. Many people following the list don't follow the github repository
closely enough to see every issue.


the browsers will not protect them unless the specification calls for it,
> and the specification will not call for it because the same companies
> that are heavily invested in OAuth run the WhatWG.
>

That's not really how the WHATWG works. I encourage you to read our FAQ:
   https://wiki.whatwg.org/wiki/FAQ

One factor to bear in mind in particular is that the specification has no
power. We could put whatever we want in the spec, but if browser vendors
don't want to implement it, it doesn't really matter, they'll just ignore
it.


If the WhatWG can't put the security of Internet users first, then it
> needs to be disbanded and replaced by a working group that will put the
> security of the users first.
>

There's already plenty too many working groups working on HTML as it is...

Cheers,
-- 
Ian Hickson

[whatwg] WhatWG is broken

[Michael A. Peters]

https://www.w3.org/TR/html-design-principles/#priority-of-constituencies

3.2. Priority of Constituencies

In case of conflict, consider users over authors over implementors over 
specifiers over theoretical purity. In other words costs or difficulties 
to the user should be given more weight than costs to authors; which in 
turn should be given more weight than costs to implementors; which 
should be given more weight than costs to authors of the spec itself, 
which should be given more weight than those proposing changes for 
theoretical reasons alone. Of course, it is preferred to make things 
better for multiple constituencies at once.

3.3. Secure By Design

Ensure that features work with the security model of the web. 
Preferrably address security considerations directly in the specification.


Communicating between documents from different sites is useful, but an 
unrestricted version could put user data at risk. Cross-document 
messaging is designed to allow this without violating security constraints.


-=-=-=-=-=-=-=-

Right now the specification for window.opener() is seriously insecure, 
allowing for cross-domain script access by default.


WhatWG refuses to properly address the issue.

The reason they refuse to properly address the issue is because it would 
break OAuth.


Yup - an alleged security tool requires an insecure Internet. That's the 
most insane logic I have ever heard but that's what the issue is.


The proposed fix - rel="noopener" - is insufficient, it is difficult to 
consistently deploy and there are thousands upon thousands of archived 
web pages that won't have that attribute added.


It is unrealistic to expect the end user to be aware of the issue, the 
end user will be vulnerable to phishing and other attacks made possible 
via window.opener() if the browsers do not protect them, but the 
browsers will not protect them unless the specification calls for it, 
and the specification will not call for it because the same companies 
that are heavily invested in OAuth run the WhatWG.


There is a serious conflict of interest and it is resulting in a web 
that does not put the user first, or the security of the user first, but 
instead is putting first a protocol that has had repeated serious 
security flaws and is broken by design.


If the WhatWG can't put the security of Internet users first, then it 
needs to be disbanded and replaced by a working group that will put the 
security of the users first.

Re: [whatwg] Intent to implement: Background Geolocation for Progressive Web-Apps

[Ian Hickson]

Richard,

The WHATWG mailing list is actually not an appropriate place for either
this kind of e-mail (I'm not even really sure what this e-mail was supposed
to be... are you an implementor?) nor your other recent e-mail (voting for
a feature doesn't help in the WHATWG, all that matters is the quality of
arguments and data presented).

I urge you to read the WHATWG FAQ before sending further e-mails to the
list. Thanks.
https://wiki.whatwg.org/wiki/FAQ

If you wish to respond to this e-mail please do not cc the WHATWG list in
your reply.

Cheers,
-- 
Ian Hickson

On Tue, Nov 29, 2016 at 11:46 PM Richard Maher 
wrote:

Contact emails

mahe...@gmail.com


*Summary*

Secure, user-sanctioned geolocation collection is currently unavailable for
HTML5 Web-Apps when they are not running or in the foreground. This leaves
the browser hosted applications incapable of competing with Native Apps on
an even playing field.


The main goal of background geolocation reporting is to all web-apps, but
in particular, Gaming, Social-Network, and Fleet-Management Apps, to
continue to function even if the device has gone to sleep or another App is
in the foreground.


Additional goals are:

   -

   Power-Saving. By using the existing ServiceWorker paradigm and flexible
   throttle/filter on which geolocation movements are "interesting".
   -

   Single-process (Google Play etc) to monitor all geolocation reports for
   all Apps before deciding if ServiceWorker(s) need to be instantiated.
   -

   Unlike Mozilla's current implementation, stalkers, estranged spouses,
   and marketeers will no longer be allowed to track users covertly.


Here is design overview document:

https://sites.google.com/a/chromium.org/dev/developers/design-documents/
ServiceWorker/TravelManagerEvent
<
https://www.google.com/url?q=https%3A%2F%2Fsites.google.com%2Fa%2Fchromium.org%2Fdev%2Fdevelopers%2Fdesign-documents%2Fsync%2Funified-sync-and-storage-overview=D=1=AFQjCNHwnrvcFIOorADSVqVKlLO-C3dOcQ
>
Ongoing technical constraints

None. See https://w3c.github.io/ServiceWorker/#extensibility
Tracking bug
There is currently no top level bug.

*FOR MORE PLEASE SEE: - *

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/kDq4t93zbpA

[whatwg] Arithmetic coded JPEGs

[Evgeny Vrublevsky]

Hello.

I'm writing about arithmetic coded JPEG support. Historically, it wasn't
supported by browsers due patents. But all of these patents are expired
several years ago, and modern libjpeg, libjpeg-turbo and mozjpeg have
optional support of the arithmetic coding.

Arithmetic coded JPEG support will allow us to recompress all existing
JPEGs losslessly, saving 10-20% of size. I've provided some examples here:
https://bugs.chromium.org/p/chromium/issues/detail?id=669501#c3

Similar ticket exists also in the Mozilla's Bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=680385#c17 . Now, I'm just
following this direction from the ticket:
> For now, the right place to go to move forward with this is on the
standards mailing lists, not in this bug.

Unfortunately, browsers still don't support arithmetic JPEG officially. Is
this a right place to start a discussion if it is possible to change it?

-- 
Best regards, Evgeny

Re: [whatwg] Push API and Endpoints

[Richard Maher]

Personally. I'd vote for endpoint mapping to be done in the Message Service
with Topic based subscriptions. Just like GCM/GCM, Amazon, Apple, and
Microsoft support.