Re: [whatwg] Clarification for window.opener.location.href
On Mon, Jan 5, 2015 at 11:17 PM, Nicholas C. Zakas standa...@nczconsulting.com wrote: So my question is: is the spec incorrect in that it should reflect reality? Or are browsers incorrect and we should be hounding them to fix this behavior? It depends on compatibility. It seems the Chrome team planned on measuring that, but ended up not doing it? Note that sites can use rel=noreferrer to disable window.opener. Perhaps there should be some CSP or sandbox directive to disable it as well. -- https://annevankesteren.nl/
Re: [whatwg] *** GMX Spamverdacht *** Parsing of meta refresh needs tweaking
On 2014-12-11 09:09, Simon Pieters wrote: The spec's parsing rules of meta refresh causes infinite reloading on some pages. In particular, the spec requires the url= to be present, but there are pages that omit it. IE9 also requires url= apparently. Gecko/Blink/WebKit allow url= to be omitted. For example, there is http://www.only-for-winners.com/ which has meta http-equiv=refresh content=0;http://www.aldanitinetwork.com; / Clearly this is intended to redirect, not reload the current page after 0 seconds. SELECT page, COUNT(*) AS num FROM [httparchive:runs.2014_08_15_requests_body] WHERE page = url AND mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), rmeta\s+[^]*http-equiv\s*=\s*[\']?refresh) AND REGEXP_MATCH(LOWER(body), rmeta\s+[^]*content\s*=\s*[\']?\s*\d+\s*;\s*[^\']) AND NOT REGEXP_MATCH(LOWER(body), rmeta\s+[^]*content\s*=\s*[\']?\s*\d+\s*;\s*url=) GROUP BY page 23 rows. I also noticed that Gecko allows the number to be omitted. I only found one page doing that and it was using meta http-equiv=refresh content=;URL= so it seems we can fail parsing for that case. I hear (a) these pages have been broken in IE for a long time, and (b) only 23 (?) pages in your DB are found. So why not just leave them broken? Best regards, Julian
Re: [whatwg] Clarification for window.opener.location.href
On 1/5/15 5:17 PM, Nicholas C. Zakas wrote: Basically window.opener.location.href = whatever works all the time, regardless of origin restrictions, and pretty much works that way across all browsers. This seems to indicate that this behavior isn't allowed: https://html.spec.whatwg.org/#allowed-to-navigate Why not? Stepping through the allowed to navigate algorithm for this case, assuming window.opener is a toplevel browsing context: 1) B is a toplevel browsing context, so this item does not apply. 2) A is not sandboxed so this item does not apply. 3) A is not sandboxed so this item does not apply. 4) We allow the navigation. Am I just missing something? If B _isn't_ a toplevel browsing context, then we'd still skip step 1 because A is not sandboxed... This issue is pretty big for sites that host user-generated content, as it's easy to create an attack, such as: 1. Go to a UGC site that allows uploading files with embedded links. 2. Upload a file containing a link to an attacker's page. 3. When someone clicks the link So where in this process is the popup window opened? Is that done under the control of the file containing a link to an attacker's page or of the UGC site? Because the current spec mitigation for the problem you describe is that when a site opens a popup it can set its .opener to null to prevent it reaching back into the site that opened it, precisely because of the issue you described. So my question is: is the spec incorrect in that it should reflect reality? Or are browsers incorrect and we should be hounding them to fix this behavior? As far as I can tell, either you're just misreading the spec or I am. -Boris
Re: [whatwg] Clarification for window.opener.location.href
even when the two windows have different domains Basically window.opener.location.href = whatever works all the time Looks like Chrome, Firefox and Opera already differentiate between window origins when the example is changed to window.opener.location.href=javascript:alert(‘Gotcha');” - if they’re on the same origin the alert is displayed, if they’re on different origins it’s not. I guess it’s a logical that the existing restriction should be applied more widely. Mat Carey On 5 Jan 2015, at 22:17, Nicholas C. Zakas standa...@nczconsulting.com wrote: Hi, This bug has been open for Chromium since last year: https://code.google.com/p/chromium/issues/detail?id=168988 It describes the ability of a popup window or other tab to modify the location of it's window.opener even when the two windows have different domains. Basically window.opener.location.href = whatever works all the time, regardless of origin restrictions, and pretty much works that way across all browsers. This seems to indicate that this behavior isn't allowed: https://html.spec.whatwg.org/#allowed-to-navigate This issue is pretty big for sites that host user-generated content, as it's easy to create an attack, such as: 1. Go to a UGC site that allows uploading files with embedded links. 2. Upload a file containing a link to an attacker's page. 3. When someone clicks the link, the attacker page redirects the original window to a page that looks like the UGC site but is actually a phishing site designed to look like it. The user doesn't notice this because focus is on the attacker's page in the new window while the redirect happens. So my question is: is the spec incorrect in that it should reflect reality? Or are browsers incorrect and we should be hounding them to fix this behavior? -- ___ Nicholas C. Zakas http://www.nczonline.net
Re: [whatwg] Clarification for window.opener.location.href
On 1/6/15 3:10 PM, Nicholas C. Zakas wrote: Yes, if we do it with window.open(), then it's possible to set opener to null. However, if you click on a link with target=_blank, window.opener is set as well. Not if you use rel=nofollow, per spec. Browser support there is still spotty but improving. Of course that affects more than just window.opener (e.g. affects whether a referrer is sent) -Boris
Re: [whatwg] Clarification for window.opener.location.href
On 1/5/2015 5:07 PM, Boris Zbarsky wrote: On 1/5/15 5:17 PM, Nicholas C. Zakas wrote: Am I just missing something? Sorry, you're totally right. I was going off the comment in the Chrome bug. If B _isn't_ a toplevel browsing context, then we'd still skip step 1 because A is not sandboxed... This issue is pretty big for sites that host user-generated content, as it's easy to create an attack, such as: 1. Go to a UGC site that allows uploading files with embedded links. 2. Upload a file containing a link to an attacker's page. 3. When someone clicks the link So where in this process is the popup window opened? Is that done under the control of the file containing a link to an attacker's page or of the UGC site? Because the current spec mitigation for the problem you describe is that when a site opens a popup it can set its .opener to null to prevent it reaching back into the site that opened it, precisely because of the issue you described. Yes, if we do it with window.open(), then it's possible to set opener to null. However, if you click on a link with target=_blank, window.opener is set as well. This is really the issue. So my question is: is the spec incorrect in that it should reflect reality? Or are browsers incorrect and we should be hounding them to fix this behavior? As far as I can tell, either you're just misreading the spec or I am. Yup, that's all on me. Thanks for pointing it out. -Boris -- ___ Nicholas C. Zakas http://www.nczonline.net
Re: [whatwg] Clarification for window.opener.location.href
On Tue, Jan 6, 2015 at 12:16 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/6/15 3:10 PM, Nicholas C. Zakas wrote: Yes, if we do it with window.open(), then it's possible to set opener to null. However, if you click on a link with target=_blank, window.opener is set as well. Not if you use rel=nofollow, per spec. Browser support there is still spotty but improving. Of course that affects more than just window.opener (e.g. affects whether a referrer is sent) -Boris rel=noreferrer, right? Charlie
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
On Mon, 10 Nov 2014, Florian Rivoal wrote:
:hover matches on the labeled control of a label element currently
matching :hover.
Similarly, :active interoperably matches on the labeled control of a
label element currently matching :active (and
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27247 is about reflecting
that in the spec)
In addition, IE (tested IE10 and IE11) makes it work the other
direction, making :hover (resp. :active) match on the label of a labeled
control currently matching :hover (resp. :active).
Given that this behaviour sounds reasonable
Why does it sound reasonable? I'd argue it's the other way around. Having
:hover match an element that isn't being hovered is weird.
that authors occasionally ask for by the ability to style the label
based on the state of the labeled control
Can you provide some pointers to such requests?
that this cannot be expressed by css selectors otherwise
I proposed the /.../ combinator long ago which would actually address
this. The idea of that combinator was that it would let you walk
relationships between elements. For example, we could define a for
relationship for labels and controls, so that you could do:
input:hover /for/ label { }
...or some such. This would be a much more generic solution.
and taking IE’s behaviour as evidence of a lack of widespread compat
issues
How recent is IE's behaviour?
I suggest making this propagation of the :hover and :active state
between label and labeled control bidirectional for both :hover and
:active.
On Mon, 10 Nov 2014, Florian Rivoal wrote:
On 10 Nov 2014, at 16:38, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/10/14, 9:23 AM, Florian Rivoal wrote:
that authors occasionally ask for by the ability to style the label
based on the state of the labeled control
The label, or the labels?
The problem of hover the control if the label is hovered is simple:
the label already has a reference to the control it's labeling; when
an element enters hover state you at worst have to deal with one other
element (plus their ancestors) entering hover state.
And even that gets a bit complicated given the ancestors thing.
The backreference, however, is a one-to-many relationship, which makes
things quite complicated, or fairly slow, or both, when multiple
labels label the same form control. So I would be a bit careful here.
You’re right, the relation is one-to-many, making the cost in this
direction greater than in the other one.
That said, the labeled control also maintains a list of references to
the associated labels, so there is no particular difficulty involved in
finding them.
Also, while the relationship is indeed one-to-many, I expect that this
is actually fairly rare for controls to actually have several, let alone
many associated labels. Even when they do, it should be even more rare
for these labels to have long ancestor chains that don’t merge quickly,
and when they do merge the walk up the dom can be cut short, as there’s
no need to continue if you find an ancestor that already has the state
marked as on. Turning it back off is probably a bit more involved at the
point where the ancestor chains merge, but this already has to be solved
to deal with the label's and the control’s ancestor chains merging, and
I don’t think going from 2 to n changes the nature of the problem.
All in all, while I agree this is potentially slower, I don’t think it
will be significantly different in anything but pathological cases. Or
am I missing a common pattern involving a control with many labels in a
deeply nested dom, with mostly distinct ancestor chains?
The problem is that it requires extra cycles every single time you are
trying to check whether a :hover rule matches a control. If we add this,
then a rule like this:
:hover { background: blue; }
...requires O(N*M) extra cycles, where N is the number of controls in the
document and M is the average number of labels per control. Worst case,
you have to pay this cost every frame (60 times a second). It also
increases the size of the browsers, which means higher memory footprints,
more swapping, etc.
It all adds up.
Is the cost of these extra cycles on all pages worth the benefit to the
pages that use it?
On Fri, 14 Nov 2014, Ryosuke Niwa wrote:
Indeed. It appears to me that this use case can be solved by the
proposed :has() relational pseudo class as long as the author has
structured so that the label is an ancestor of the input control it’s
associated with: http://dev.w3.org/csswg/selectors4/#relational
It's even simpler than that. If you limit yourself to containment rather
than the for= attribute, then you can just do:
label:hover input { ... }
On Sat, 15 Nov 2014, Florian Rivoal wrote:
There’s two problems with that:
* You constrain the markup beyond what html normally allows to be able
to achieve some
Re: [whatwg] Clarification for window.opener.location.href
Yes, if we do it with window.open(), then it's possible to set opener to null. However, if you click on a link with target=_blank, window.opener is set as well. Not if you use rel=nofollow, per spec. The spec doesn't mention that `rel=nofollow` should null out `window.opener`. That behavior is only mentioned for `rel=noreferrer`. http://www.w3.org/TR/html5/links.html#link-type-nofollow http://www.w3.org/TR/html5/links.html#link-type-noreferrer http://www.w3.org/TR/html5/browsers.html#noopener (only specifically mentions noreferrer) https://html.spec.whatwg.org/#link-type-nofollow https://html.spec.whatwg.org/#link-type-noreferrer https://html.spec.whatwg.org/#noopener (only specifically mentions noreferrer) Sincerely, James Greene On Tue, Jan 6, 2015 at 2:16 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/6/15 3:10 PM, Nicholas C. Zakas wrote: Yes, if we do it with window.open(), then it's possible to set opener to null. However, if you click on a link with target=_blank, window.opener is set as well. Not if you use rel=nofollow, per spec. Browser support there is still spotty but improving. Of course that affects more than just window.opener (e.g. affects whether a referrer is sent) -Boris
Re: [whatwg] Clarification for window.opener.location.href
On 1/6/15 3:43 PM, James M. Greene wrote: The spec doesn't mention that `rel=nofollow` should null out `window.opener`. That behavior is only mentioned for `rel=noreferrer`. Er, you're right. I meant noreferrer. -Boris
Re: [whatwg] Parsing of meta refresh needs tweaking
On 2015-01-07 08:52, Simon Pieters wrote: ... I hear (a) these pages have been broken in IE for a long time, and (b) only 23 (?) pages in your DB are found. Right. So why not just leave them broken? It's a worse user experience and it's a shorter path to interop to change IE. ... User experience for invalid content is one aspect; sane parsing rules are another one. Not requiring the parameter name will make it harder to introduce new parameters in the future. YMMV. Best regards, Julian
Re: [whatwg] *** GMX Spamverdacht *** Parsing of meta refresh needs tweaking
On Tue, 06 Jan 2015 08:35:54 +0100, Julian Reschke julian.resc...@gmx.de wrote: On 2014-12-11 09:09, Simon Pieters wrote: The spec's parsing rules of meta refresh causes infinite reloading on some pages. In particular, the spec requires the url= to be present, but there are pages that omit it. IE9 also requires url= apparently. Gecko/Blink/WebKit allow url= to be omitted. For example, there is http://www.only-for-winners.com/ which has meta http-equiv=refresh content=0;http://www.aldanitinetwork.com; / Clearly this is intended to redirect, not reload the current page after 0 seconds. SELECT page, COUNT(*) AS num FROM [httparchive:runs.2014_08_15_requests_body] WHERE page = url AND mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), rmeta\s+[^]*http-equiv\s*=\s*[\']?refresh) AND REGEXP_MATCH(LOWER(body), rmeta\s+[^]*content\s*=\s*[\']?\s*\d+\s*;\s*[^\']) AND NOT REGEXP_MATCH(LOWER(body), rmeta\s+[^]*content\s*=\s*[\']?\s*\d+\s*;\s*url=) GROUP BY page 23 rows. I also noticed that Gecko allows the number to be omitted. I only found one page doing that and it was using meta http-equiv=refresh content=;URL= so it seems we can fail parsing for that case. I hear (a) these pages have been broken in IE for a long time, and (b) only 23 (?) pages in your DB are found. Right. So why not just leave them broken? It's a worse user experience and it's a shorter path to interop to change IE. -- Simon Pieters Opera Software
Re: [whatwg] Clarification for window.opener.location.href
In reply to Boris, it looks like the spec has changed its wording since the Chromium bug was filed, and it now sounds like the navigations should be allowed (consistent with existing browser behavior). At the time (Jan 10, 2013), I posted a quote of the spec to https://crbug.com/168988, comment 3: - A browsing context A is allowed to navigate a second browsing context B if one of the following conditions is true: - Either the origin of the active document of A is the same as the origin of the active document of B, or - The browsing context A is a nested browsing context with a top-level browsing context, and its top-level browsing context is B, or - The browsing context B is an auxiliary browsing context and A is allowed to navigate B's opener browsing context, or - The browsing context B is not a top-level browsing context, but there exists an ancestor browsing context of B whose active document has the same origin as the active document of A (possibly in fact being A itself). - This would suggest that navigating a cross-origin opener is not allowed, since none of the conditions apply. However, the spec now reads: - A browsing context A is allowed to navigate a second browsing context B if the following algorithm terminates positively: If A is not the same browsing context as B, and A is not one of the ancestor browsing contexts of B, and B is not a top-level browsing context, and A's active document's active sandboxing flag set has its sandboxed navigation browsing context flag set, then abort these steps negatively. Otherwise, if B is a top-level browsing context, and is one of the ancestor browsing contexts of A, and A's node document's active sandboxing flag set has its sandboxed top-level navigation browsing context flag set, then abort these steps negatively. Otherwise, if B is a top-level browsing context, and is neither A nor one of the ancestor browsing contexts of A, and A's Document's active sandboxing flag set has its sandboxed navigation browsing context flag set, and A is not the one permitted sandboxed navigator of B, then abort these steps negatively. Otherwise, terminate positively! - As you mention, this indicates that navigating a cross-origin opener is allowed, since it now defaults to true. Anne, you're right that we did not get around to measuring the compatibility impact of changing the behavior at the time. Personally, I wouldn't mind seeing cross-origin opener navigations disallowed, though I don't have time to study the compatibility impact at the moment. Hope that helps clarify things, Charlie On Tue, Jan 6, 2015 at 9:22 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/5/15 8:14 PM, Mat Carey wrote: even when the two windows have different domains Basically window.opener.location.href = whatever works all the time Looks like Chrome, Firefox and Opera already differentiate between window origins when the example is changed to window.opener.location.href=javascript:alert(‘Gotcha');” - if they’re on the same origin the alert is displayed, if they’re on different origins it’s not. This is a totally different issue. This case basically does an eval in window.opener, and has to be blocked if the setter is not same-origin to prevent cross-site scripting exploits. You can see this in the spec in https://html.spec.whatwg.org/ multipage/browsers.html#navigating-across-documents step 15 the javascript: case, substep 1, which says: If the origin of the source browsing context is not the same origin as the origin of the active document of the browsing context being navigated, then act as if the result of evaluating the script was the void value, and jump to the step labeled process results below. Importantly, this is absolutely required to prevent XSS, as I said, and all browsers already do this and have since time immemorial, so no sites depend on this working. I guess it’s a logical that the existing restriction should be applied more widely. The wider application doesn't resolve immediate XSS issues, and is very likely to cause web compat problems. It's worth thinking about, but data on how serious the web compat issues are is key. And as noted sites have a way to opt in to more protection here already; the only thing we're discussing is the default behavior. -Boris
Re: [whatwg] Clarification for window.opener.location.href
On 1/5/15 8:14 PM, Mat Carey wrote: even when the two windows have different domains Basically window.opener.location.href = whatever works all the time Looks like Chrome, Firefox and Opera already differentiate between window origins when the example is changed to window.opener.location.href=javascript:alert(‘Gotcha');” - if they’re on the same origin the alert is displayed, if they’re on different origins it’s not. This is a totally different issue. This case basically does an eval in window.opener, and has to be blocked if the setter is not same-origin to prevent cross-site scripting exploits. You can see this in the spec in https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents step 15 the javascript: case, substep 1, which says: If the origin of the source browsing context is not the same origin as the origin of the active document of the browsing context being navigated, then act as if the result of evaluating the script was the void value, and jump to the step labeled process results below. Importantly, this is absolutely required to prevent XSS, as I said, and all browsers already do this and have since time immemorial, so no sites depend on this working. I guess it’s a logical that the existing restriction should be applied more widely. The wider application doesn't resolve immediate XSS issues, and is very likely to cause web compat problems. It's worth thinking about, but data on how serious the web compat issues are is key. And as noted sites have a way to opt in to more protection here already; the only thing we're discussing is the default behavior. -Boris
