Blob URLs are considered unsafe

[taparkins]

I was attempting to redirect window.location to a result from createObjectURL from blob data returned in the body of an XMLHttpRequest's response, and found that setLocationHref was failing an assertion when I attempted to do so. After poking around a bit, I was able to narrow it down to a simpler reproduction case:

let blob = new Blob(["hello world"]);
let objectUrl = createObjectURL(blob); // something similar to "blob:http://<MY_DOMAIN>/5780a9e9-ac37-49fb-9f1e-dbb813b092b2"
let sanitized = goog.html.SafeUrl.sanitize(objectUrl);
sanitized;
> {
    SAFE_URL_TYPE_MARKER_GOOG_HTML_SECURITY_PRIVATE_: {}
    privateDoNotAccessOrElseSafeHtmlWrappedValue_: "about:invalid#zClosurez"
}

From my understanding, this output of sanitize is suggesting that the blob: URL is inherently unsafe. Based on this similar story from Lighthouse, I'm assuming this is an oversight.

It seems like the fix here is just updating SAFE_URL_PATTERN_ to account for blob along with http(s), mailto, and ftp.

[taparkins]

Follow-up: I discovered after opening this issue that there other SafeUrl functions for creating URLs for blobs directly, but these ended up not working for me either. I am attempting to download a binary file generated by our server's API, and it seems that the options for creating SafeUrls from Blobs reject if the MIME type is not one of a handful of specific audio, video, or image formats (which my data is definitely not).

Is there perhaps a way for me to manually create a SafeUrl when I know the location is coming from a trusted source? It seemed like TrustedResourceUrls also had stringent requirements that my blob: urls were unable to satisfy directly.

[xtofian]

Blob URLs have the origin of the context that called createObjectUrl, which is typically your application. Hence, calling createObjectUrl on blob contents that are not trustworthy (provided by a potential attacker; e.g. different user of your application) is potentially dangerous - it creates a URL that's same-origin with your app, but whose contents are attacker-controlled. This can result in XSS vulnerabilities if the URL gets navigated to by your app on purpose, or the attacker can arrange for that to happen; potentially by guessing what the URL is (unfortunately, blob URLs are not required to be hard to guess by the spec, see w3c/FileAPI#74 (comment)).

If you're sure from context that the content of the blob is trustworthy, you can use goog.html.uncheckedconversions.safeUrlFromStringKnownToSatisfyTypeContract to "bless" the blob URL into a SafeUrl.

If the content of the blob is not trustworthy, you can do the whole thing inside a sandboxed iframe, where the blob URL origin will be the sandboxed origin of the iframe.

[taparkins]

Ah... safeUrlFromStringKnownToSatisfyTypeContract was what I was looking for. Thanks for info, @xtofian :)