Email app should not open URLs using



Firefox OS
5 years ago
5 years ago


(Reporter: freddyb, Unassigned)


({sec-low, wsec-disclosure, wsec-session})

sec-low, wsec-disclosure, wsec-session

Firefox Tracking Flags



The code that is invoked when clicking on a hyperlink is as follows (in function 
./js/cards/message_reader.js:524:, '_blank');

This will open the URL *within* te email app, allowing potentially malicious URLs (like data URIs that share the same origin with the opener) access the whole DOM, the JS scope and execute arbitrary JavaScript within the email app.

Of course our HTML sanitizer takes care of data URIs and the like (does it? I will test..), but as a defense-in-depth mechanism we shouldn't really open it in the email app:

Aa WebActivity should be fired that opens the URL in the borwser.
:jlebar, your input is appreciated here on the platform issues. :jsicking, your webapi thoughts.

The rationale behind our use of was that it was more webby than our still-proprietary MozActivity implementations and '_blank' has explicit web semantics that would do what we wanted in a desktop browser too.  I forget if I made that decision on my own or asked someone; I don't have an obvious e-mail trail.  I know I primarily audited the system app path and the platform details I audited have likely changed, so there could be dangers related to potentially magic schemes like javascript (although those should be prevented by our sanitizer which should only allow http/https through right now and CSP).

My understanding of how this works is:

- a "mozbrowseropenwindow" event gets fired.

- the system app's popup manager sees our event and that we asked for "_blank" and converts our request into a 'view' activity. (The window_manager ignores the event because we're not talking about the 'remote' magic flag.)  If we hadn't asked for _blank, would trigger and load the URL in an iframe for us.

I don't have a problem with switching to directly opening a web activity since that's really the intent of what we're doing right now, but it seems like we want to make safe for either everyone or privileged/certified apps if it is a risk.  I do think we probably want to get updated so it says something about and so that it explains whether all calls will generate an event or if 'javascript:' would not, etc.

Also, it's not clear to me whether would actually be needed for the new UX paradigm Josh and team demoed the other week?  I think we would definitely want the e-mail app in the URL's "back" trail.  If an activity gets us that, that works.
Based on comment 1, it sounds like is the right thing to do.  If it's not working properly (e.g. if it's opening a frame within the e-mail app), then Gaia isn't doing the right thing.
A misunderstanding on my side. Thanks for the clarification, Justin and Andrew :)
Last Resolved: 5 years ago
Resolution: --- → INVALID
blocking-b2g: koi? → -
Group: b2g-core-security
You need to log in before you can comment on or make changes to this bug.