Open Bug 1895444 Opened 1 year ago Updated 1 year ago

iframe is accessible from parent ("about:blank") during time of HTTP Auth in Iframe (xs leak?)

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Version:
Firefox 125
Type:
defect

Tracking

()

People

(Reporter: jayateertha043, Unassigned)

Details

(Keywords: reporter-external)

Attachments

(2 files)

POC Image
49.41 KB, image/png
Details
reporter's PoC
628 bytes, text/html
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

Steps to reproduce:

Host this POC File -

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="icon" href="https://glitch.com/favicon.ico" />
    <title>Hello World!</title>
  </head>
  <body id="body">
   <iframe id="iframe" src="https://http-me.glitch.me/?body=hi&header=Supports-Loading-Mode:fenced-frame&header=WWW-Authenticate:Basic%20realm=%22myRealm%22&status=401"></iframe>
<script>
window.addEventListener('error', function(event) {
    console.error('Caught an error:', event.message);
    return false;
});
</script>
  </body>
</html>

Without dismissing the HTTP Auth Pop Up, Open Dev Console & Type iframe.contentWindow.document.location.href & iframe.contentWindow.document.location.origin, Notice that till the time the HTTP Auth Pop is dismissed iframe href & origin is set to about://blank & null respectively leading to SOP Bypass.

Actual results:

Till the time IFrame's HTTP Auth Pop Up is dismissed iframe.contentWindow.document.location.href & iframe.contentWindow.document.location.originis set to about://blank & null respectively leading to SOP Bypass.

Expected results:

Proper Origin & href should be set even during Auth Pop Up

Attached image POC Image —

Kindly see this image poc for more info

Another better POC -

  1. Go to https://jayateerthag.in
  2. Open dev console in https://jayateerthag.in tab, type win = window.open("https://http-me.glitch.me/?body=hi&header=Supports-Loading-Mode:fenced-frame&header=WWW-Authenticate:Basic%20realm=%22myRealm%22&status=401")
  3. Now open dev console in https://http-me.glitch.me/?body=hi&header=Supports-Loading-Mode:fenced-frame&header=WWW-Authenticate:Basic%20realm=%22myRealm%22&status=401 tab without dismissing the HTTP Auth Pop Up Dialogue, type window.opener.document.write("Origin is:" + document.origin)
  4. Notice that content of https://jayateerthag.in tab has changed from *.glitch.me origin tab

Note: I tried the same in Chrome I get error like - VM122:1 Uncaught DOMException: Failed to read a named property 'document' from 'Window': Blocked a frame with origin "null" from accessing a cross-origin frame.

Attached file reporter's PoC —

Attaching reporter's PoC from comment 0 so testers don't need a local server

Notice that till the time the HTTP Auth Pop is dismissed iframe href & origin is set to about://blank & null respectively leading to SOP Bypass.
[...]
Expected results:
Proper Origin & href should be set even during Auth Pop Up

I don't know that is specified anywhere. HTTP Auth is a networking thing. Our networking code has not downloaded any content at this point let alone handed it off to HTML. The frame has not navigated to the new location. I imagine you would get the same result if you framed a site that took a really long time to respond. While we were waiting the frame would be about:blank, until either we got a response or the frame error'd out.

There is no "Same Origin Policy" bypass because the frame is not another origin. It's only a security problem if you can read/modify content from another origin and that's not happening here.

Your testcase uses fenced-frame which is a Chrome proposal not yet adopted by other browsers (or a standard). That might be part of the different results you're getting from Chrome.

Hi during http auth, the iframe has already recieved a 401 response successfully even with response body (html), it's only after we dismiss the pop up it's reflected in the iframe.

If you notice my comment 2, that poc will give sop error in chrome but that doesn't happen in Firefox. The poc in comment 2 can be a better poc as this was fixed in chrome earlier.

I don't remember the issue exactly will try to attach the reference if I find it.

Group: firefox-core-security → core-security
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

technically, yes, the networking code has received data from the site, but a 401 response requires additional resolution so that response stays bottled up inside the networking code. To the rest of the browser the load request has not returned any data. As far as the document and the DOM is concerned it's just a very very slow server that hasn't responded yet.

If you notice my comment 2, that poc will give sop error in chrome but that doesn't happen in Firefox.

I don't believe the navigation timing is specified anywhere. Chrome and Firefox differ, but it's not clear to me that one is "more correct". Both prevent access to cross-origin content. What is the security harm of letting scripts access an empty frame?

One advantage of Chrome's approach is that it eliminates the ability to use frame access/error to do timing attacks on how long the load takes. That's definitely worth considering.

Group: core-security → dom-core-security
Component: DOM: Core & HTML → DOM: Navigation
Keywords: csectype-disclosure

Not only timing attack I think, chrome's approach protects against many other forms/variations of xs-leaks attacks in this scenario.
The fix should be not only for iframe but also windows to fix this completely.

Hi team,

Can you attach a appropriate security severity for this issue like sec-low, sec-moderate or sec-high

Just a noob doubt I see csec-disclosure, is this some internal severity keyword.

Hope bounty and advisory is applicable once fixed.

We will evaluate what severity rating it should have. It can take a day or two. csectype- is about what kind of problem it is, not how severe it is. I've set the sec-bounty? flag so it will be considered for a bounty once it is fixed.

Flags: sec-bounty?
Flags: needinfo?(dveditz)

Hi Daniel

needinfo flag is set kindly remove if not required.

dveditz set the needinfo flag on himself because he wanted a reminder to investigate the issue further. There's nothing you need to do related to it.

Hi team,

Similar issue in chrome is already under fix(as it's security report cannot disclose until fix), Kindly let me know if this under fix and severity assigned.

We don't believe this is a security issue -- there is no Same Origin Policy bypass and the parent frame never has access to any cross-origin objects.

There appears to be a detectable browser engine difference in how this is treated which may indicate the spec is incomplete or ambiguous, or that one or more browsers is violating the spec. None of those are security issues however.

Group: dom-core-security
Flags: needinfo?(dveditz)
Keywords: csectype-disclosure
Summary: Security: SOP Bypass during time of HTTP Auth in Iframe → iframe is accessible from parent ("about:blank") during time of HTTP Auth in Iframe
Severity: -- → S4

Hi Daniel,

I think this will also cause xs-leak like cross origin frame able to determine if user is authenticated to another origin or not.

Although not high severity issue, I do feel this as a low-medium severity issue.

Flags: needinfo?(continuation)
Flags: needinfo?(continuation)
Flags: sec-bounty? → sec-bounty-
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: iframe is accessible from parent ("about:blank") during time of HTTP Auth in Iframe → iframe is accessible from parent ("about:blank") during time of HTTP Auth in Iframe (xs leak?)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: