Closed Bug 670328 Opened 13 years ago Closed 5 years ago

drive-by podcast subscription possible for users of both Fx and iTunes

Categories

(Core :: DOM: Navigation, defect, P5)

Product:
Core
Component:
DOM: Navigation
Version:
5 Branch
Platform:
All
Other
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1517368

People

(Reporter: pb-dsp_bugzilla, Unassigned)

References

(
URL
)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0 Build ID: 20110615151330 Steps to reproduce: Placed an img tag pointing to an iTunes-compatible podcast with an itpc: address in the src. For example: <img src="itpc://faif.us/feeds/cast-mp3/"> Actual results: iTunes launched an automatically subscribed me to the Free as in Freedom podcast. Expected results: Had I clicked a link to the same address, then what did happen should have. But, given that I didn't do anything between changing an image's source to aforementioned URL and being subscribed to the feed, in this case either the reference should've been ignored or I should've been prompted. I don't think websites should be able to trigger subscription to a podcast without any positive user intervention. To my knowledge, the itpc: scheme never returns content to the browser; it exists simply as a convenience to enable iTunes users to subscribe to a podcast from whichever browser by clicking a link. I could see this being used to deliver a new form of spam, and perhaps as a means to target vulnerabilities in iTunes through Firefox. For comparison, if this is attempted in Safari, it causes an "unsupported URL" error. (However, clicking a link to such an address in Safari does of course work as intended.)
Component: File Handling → General
Product: Firefox → Core
QA Contact: file.handling → general
Sounds like a duplicate of the bug on not doing anything with unknown schemes outside very restricted contexts...
Whiteboard: DUPEME
Should we add some sort of whitelist or other ability for protocols to opt-in here?
it seems like the problem is auto launching an external app via HTML with no user interaction. are you thinking about a whitelist of protocols its ok to use as src of html elements ? i'm not sure we would want things to be able to opt into this auto launch behavior ? a whitelist for external helpers on click would make some sense, although depending on the protocol and the external app it seems hard to make guarantees about it behaving 'safely'
To be clear, the "drive by" nature of this is not really fixable in general without breaking the web, without a whitelist. For example, consider this HTML file: <!DOCTYPE html> <script> window.location = "itpc://faif.us/feeds/cast-mp3/"; </script> When I load this in Safari, the podcast is added to iTunes automatically. Not surprising, since this does exactly what clicking a link would do... So I assumed the bug was specifically about the <img> vector, which might matter in places that allow image uploads but not script. And for <img>, we just want to block all schemes not returning data in general, and there are bugs on that already last I checked.
And in fact, the image loader checks URI_DOES_NOT_RETURN_DATA already. And the external protocol handler checks that flag. Now that I check, this has been the case since Firefox 2, and continues to be the case. This was fixed in bug 181860. And a testcase constructed per comment 0 doesn't show the reported problem for me. So David, what is this bug about, exactly?
Strangely, the test case URL I provided worked for me immediately before I posted this; in light of comment 5, I'm not sure why it worked then, and doesn't now. The means by which I originally encountered this still works for me (see below), and I doubt it is the only such case (even without using JS). I was referring to the spontaneous launching of an external application, i.e., launching one without any user interaction, regardless of how that is accomplished. I don't know why it didn't occur to me to try assigning window.location through JS before I posted this bug; I guess I was just tired, but I wanted to get this done since I had told someone I would after it came up in conversation. I actually stumbled onto this accidentally (because I hadn't yet noticed that one can manually subscribe to a podcast in iTunes): I right-clicked the "Audio MP3" link on http://faif.us/ and selected Firebug's "Inspect Element" option, and, noticing the link used a relative href, right-clicked the link (on the page, not in Firebug) again and copied its fully qualified location, and then absentmindedly pasted the URL (in Firebug) into the |img src| instead of the |a href| and replaced the "http" part with "itpc". Like I said, I was tired. So, now that I'm awake enough to think clearly, what this bug is about is this: I would suggest that (without reducing any other restrictions which may already be present), except perhaps in certain white-listed use cases, a page should only be able to cause an external application to be launched under the same sort of conditions as would allow it to open another browser window.
Priority: -- → P5
Yeah, that's an interesting idea. Jonas, what do you think of allowing loads in a docshell to trigger external protocols only when popups are allowed?
Assignee: nobody → bzbarsky
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: DUPEME
Component: General → DOM: Navigation
Blocks: 566893

Ehsan and/or Edgar were going to look into this.

Assignee: bzbarsky → nobody
Flags: needinfo?(ehsan)
Flags: needinfo?(echen)

See bug 566893 comment 14. I believe what has been proposed here around comment 6 has already been done in bug 1517368 and its follow-ups, so I'm inclined to dupe this against that bug.

It doesn't completely fix the issue that this bug was complaining about... but experience e.g. in bug 1514547 showed that idea isn't web compatible. Another potential solution which we could look at which Safari uses is to show a content area prompt instead telling the user the page is trying to open an external application first without doing so.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(ehsan)
Flags: needinfo?(echen)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.