Charlie, could you triage please? Thanks!

Ah, missed this when triaging  issue 863069 .  I'm less certain about this one, since Chrome doesn't support server redirects to data URLs and it's not clear to me whether open redirectors that use client redirects (like JS, meta refresh, etc) are actually common.  Do you know of any in practice, other than test pages?  

Things like https://www.google.com/url?q=... use server redirects, I believe, and don't support redirects to data URLs anyway.  (The Google redirector rejects it as invalid.)

I'm hesitant to require process swaps for all data URLs (to avoid unnecessary subframe processes on a lot of pages), but doing process swaps for redirects to data URLs could be an option if it looks like real sites are affected.

Examples:
1. http://eaip.caa.gov.tw/eaip/history/2017-12-31/html/index-en-TW.html?target=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
2. https://test.shhnjk.com/iframer.php?url=//mail-1.atlantis.sk/horde/util/go.php?url=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
3. http://test.shhnjk.com/iframer.php?url=//tracking.shopsmart.xyz/id_blanja.php?url=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==

Note that attacker can also abuse site allows Data URL links.

If you want, you can ask Google AppSec guys (e.g. @sirdarckcat, @kkotowicz) to see if Site Isolation should take care of Data URL or not. They should have better idea on Web app security around Data URL.


But even if this is decided as intended design, I think you should at least educate developers to not to allow redirects/links to Data URL for better protection against Spectre.

In general, we want to keep data URLs in the same process as the site that creates them, under the assumption that it has control over the data URL's contents and in the interest of keeping the process count and memory overhead low.  This means that most explicit navigations or iframe creations to data URLs will stay on the site that created them.

I think it may make sense to make an exception for client redirects as a compromise for this case.  It's probably not great security practice for a site to allow open client redirects to data URLs, but it's also probably rare enough that it wouldn't be a big deal for the process count if we swap to a new process for them.  Some quick testing suggests we can probably fix this in RenderFrameHostManager::CanSubframeSwapProcess, perhaps by not using the source_instance's site URL in the case of a client redirect.

I'm hesitant to do this for all navigations, though, such as the case of a site allowing users to post links to data URLs.  Swapping on all navigations to data URLs seems more likely to impact the process count (though I guess we could still exclude the case where a parent frame navigates a subframe to a data URL, which is probably the most common use of data URLs out there).

evn@ or koto@, do you have a sense for whether that (or the "open client redirect to data URL" case mentioned above) is something that many sites are going to allow in practice, or if it's something that existing security advice discourages?  I'm hoping to use unique processes for data URLs as little as possible, while still avoiding cases where an attacker can get a data URL into a victim's process.

One more note on the topic of links to data URLs-- we already disallow renderer-initiated navigations to data URLs in the main frame, so it would specifically be a question of how many sites are likely to allow users to post untrusted links to data URLs that target subframes.  That seems like it may be sufficiently small risk to keep them in process, but I'm open to data or counterexamples.

>so it would specifically be a question of how many sites are likely to allow users to post
>untrusted links to data URLs that target subframes
Any link without target or target which aren't `_top` or `_blank` would work. Assuming that the victim page is framable. 

Of course, site that allows iframe with data URL even with sandbox attribute set would have an issue too.

We would possibly consider redirecting to data: URLs as vulnerabilities in Google because old Firefox treated them as same origin (ESR iirc), and because usually if we allow data: we forgot to forbid javascript: too.

Comment 6: Yes, the iframe sandbox case is separate-- we're likely to move that to an OOPIF in issue 627781.  

For the case of an attacker iframing a page that has untrusted data URL links, that seems like it would be relatively low severity in practice.  The links wouldn't work at all when visiting the site in the main frame (given interventions that both Chrome and Firefox have deployed, like https://blog.mozilla.org/security/2017/11/27/blocking-top-level-navigations-data-urls-firefox-59/), so sites might already be inclined to block them (like comment 7).  Sites have incentives to disallow them anyway to prevent them from being used for phishing.  Even if they did allow them, the attacker would still have to iframe the site and wait for the user to click on the malicious data URL.  So far I'm not too concerned about that case, unless it proves to be widespread.

I'll plan to proceed with the client redirect process swap when I get back, unless Alex beats me to it.

creis: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm focusing on the case in  issue 863069  at the moment and running into test issues there.  Nasko and I are chatting about this one, though.

Nasko, can you help come to a resolution on this one, since I will be OOO for a bit?  Forcing a process swap on client redirects is one option, or we could choose to recommend against redirecting and linking to untrusted data URLs (per comment 7).

Either way, I might consider this one Low rather than Medium severity, given the mitigating factor that not many sites are likely to allow untrusted redirects/links to data URLs (especially since they apparently used to be considered same origin with the source page by other browsers).

nasko: Uh oh! This issue still open and hasn't been updated in the last 35 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I think client redirects to data: URLs is not a safe pattern to use. I am hesitant to make more exceptions in the already complex code that is determining process/site placement. I think keeping an invariant - "a data: URL bears the same security principal as the document that created it" is going to be very useful. Additionally, comment #7 eludes to already problematic behavior with other browsers and would consider this to be a bug in the web property.

Therefore I'm resolving this as WontFix and it will be good to find an appropriate way to document that web developers should not be allowing open client redirects to data: URLs.

In the platform, data: urls are in opaque origin, they are not same origin as the page that uses them (e.g. redirect to them, or embed them). Taking Spectre-aside, redirecting to data: URL is just as safe for a web application, as redirecting to https://cross.origin/, so following that logic, redirection to any cross origin URL should be treated as a bug. 

There used to be a case in FF, where data: URLs were same-origin, but it's fixed in FF57, and in the HTML spec.  

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot