New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 752190 link

Starred by 6 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security



Sign in to add a comment

Security: window.length reveals frame count, even cross-origin

Reported by rskans...@gmail.com, Aug 3 2017

Issue description

VULNERABILITY DETAILS
cross site frame count leak

This bug describes a SOP bypass much similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1315203
but does not use the .history.length but instead a ref to either iframe.contentWindow.length or ref to a window.length

The length of a reference to a iframe or window object contains the number of frames on the remote page and can be polled to deduce state.

Applications are vulnerable if the same url or a redirected url returns a different number of frames depending on victims state. This can by used by an attacker to make bi-directional CSRF and other similar issues to XSHM.

 - https://www.owasp.org/index.php/Cross_Site_History_Manipulation_(XSHM)
 - https://www.netsparker.com/blog/web-security/bruteforce-wordpress-local-networks-xshm-attack/

If the target has a x-frame-options policy the window object reference methods must be used. 
Without the policy that attack can be run much more subtle inside a iframe. 

No POC provided for the second iframe vector, it is almost the same, with document.querySelector("iframe").length

For reproduction I added a POC similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1315203 reproducing the "Am I logged into Facebook?". The POC is not for displaying another fingerprinting method, but just to show that the length can be used to infere much the same as xshm. Another more complicated POC could be bi-directional CSRF login attack, intranet weak credentials checking etc. 


VERSION
Chrome Version: 58.0.3029.110 (64-bit)
Operating System: Ubuntu 16.04 

REPRODUCTION CASE
# window object (example at http://159.203.190.123/00100010-poc-2aovnht7sqmxjfg28f87fnisjfpnlfzzyxufne.html)

- poc tested on desktop pc

<p class="status">
  Click on the page. This text will update
</p>
<script>
  var t = "https://www.facebook.com/messages/"
  var s = document.querySelector(".status")

  window.addEventListener("click", (e) => {
    e.preventDefault()
    l = window.open(t);
    alert("Pull back focus. Press OK and wait 4 seconds");
    setInterval( () => {
      if(l.length > 1) {
        s.innerText = "You are logged into Facebook"
      } else {
        s.innerText = "You are not logged into Facebook"
      }
      l.location.href = t
    }, 4000)
  });
</script>
 
Cc: mkwst@chromium.org
Components: Blink>SecurityFeature>SameOriginPolicy
Labels: Security_Impact-Stable
Indeed, this is one of the "side-channels" baked into the standard (see https://html.spec.whatwg.org/multipage/browsers.html#crossoriginproperties-(-o-) ) and unfortunately it's not something that browsers can change by default for compatibility reasons (Meaning this Issue will almost certainly be resolved as WontFix, working-as-intended).

http://2013.zeronights.org/includes/docs/Krzysztof_Kotowicz_-_Hacking_HTML5.pdf page 8 lists a few others.

For subframes, X-Frame-Options prevents the attack from working, but that won't help if the attacker opens the victim site as a top-level window as shown here.

mkwst@-- is there any way for a document to "Emancipate" or "Isolate" itself (e.g. the complement of "rel=noopener"), such that all inbound cross-origin method calls would fail? (This seems to be similar to what https://github.com/w3c/webappsec/issues/517 asks for). 
Labels: -Restrict-View-SecurityTeam allpublic Security_Severity-Low
Summary: Security: window.length reveals frame count, even cross-origin (was: Security: (SOP) Cross site frame count leak)
Labels: OS-All
Status: Untriaged (was: Unconfirmed)

Comment 5 by mkwst@chromium.org, Aug 4 2017

Cc: andypaicu@chromium.org
https://w3c.github.io/webappsec-csp/#disown-opener is a WIP to address this. Got bogged down in discussions around whether it should be bidirectional or not. Maybe I can get Andy to take the lead on the design/discussion? :)

I agree that this is something we should address, and I also agree that we're unlikely to be able to address it by default, given that it's implemented this way in every browser, and relied upon by folks to navigate their sibling frames in other windows. We'd need to do a good deal of research into the way that usage works, and how willing we'd be to break it.
Project Member

Comment 6 by sheriffbot@chromium.org, Aug 4 2017

Labels: Pri-2
Status: Available (was: Untriaged)

Comment 8 by tsepez@chromium.org, Sep 22 2017

Issue 767828 has been merged into this issue.

Comment 9 by est...@chromium.org, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt
Cc: elawrence@chromium.org
Have we made any progress on DisownOpener? Do we have any plan to do anything else here other than implement that? If not, can we either close this issue or re-title it to scope our plan?
Labels: -Hotlist-EnamelAndFriendsFixIt

Sign in to add a comment