Issue metadata
Sign in to add a comment
|
Security: window.length reveals frame count, even cross-origin
Reported by
rskans...@gmail.com,
Aug 3 2017
|
||||||||||||||||||||
Issue descriptionVULNERABILITY 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>
,
Aug 3 2017
,
Aug 3 2017
,
Aug 4 2017
,
Aug 4 2017
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.
,
Aug 4 2017
,
Aug 4 2017
,
Sep 22 2017
Issue 767828 has been merged into this issue.
,
Nov 10 2017
,
Feb 15 2018
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?
,
Feb 18 2018
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Aug 3 2017Components: Blink>SecurityFeature>SameOriginPolicy
Labels: Security_Impact-Stable