1227617 - It should not be possible to add non-http(s) urls to the reading list via the ShareTo extension

Status: RESOLVED DUPLICATE of bug 1263624

(Firefox for iOS :: Reading List, defect)

Description

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

The reading list should only accept http and https urls. We have no UI or strings to tell people that the item cannot be added so for a first iteration I think we will start by simply silently failing.

Comment 1

[Daniel Veditz [:dveditz]]

Does the "ShareTo" extension actually share this with other people? How? (sorry for being unfamiliar) If it's just seen by the user adding the link there's not a lot of potential damage (even if there's privilege escalation). If it's sent to other users what's the context in which it's received? Links sent in mail probably aren't too harmful -- the mail client needs to sanitize. If a web page can force or lure a user into sharing something that could be worse, too.

Trying to set an appropriate security rating here.

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

How this works is as follows:

1) User sees a link in their Twitter app
2) User selects 'Share to Firefox'
3) User selects 'Add to my Bookmarks' and 'Add to my Reading List'

Everything happens on device and everything is a manual action. But, we take the URL as-is. So if it is a javascript: URL then that goes to your bookmarks and reading list.

I am not entirely sure if it makes sense to block certain types of URLs to be shared actually. I would rather let people share whatever they want to Firefox and then in the app itself where the URL is used, take the right action.

Comment 3

[Al Billings [:abillings - ex-MoCo]]

What are the security implications here for this issue? Critsmash wants a security rating on this unrated security bug.

Comment 4

[Daniel Veditz [:dveditz]]

This is a fairly severe spoofing risk then. At the very least if the shared URL is a data: url then it could end up being a perfect spoof of some site. If the shared URL is a javascript: url it's a "bookmarklet", which can be a powerful tool but is more likely a footgun for the average user. We have already seen, in browsers, attacks on popular social sites like Facebook that try to get people to bookmark javascript: urls to give them "extra powers", but which really hack their account.

Given a competent social engineer some number of people will do so despite obstacles, but we shouldn't make it easy. Legitimate shared bookmarklets are rare enough that if users have to manually copy and then create a bookmark from them it's not the end of the world.

Other schemes could be dangerous depending on what is powerful or allowed in iOS (I have no idea what powerful internal schemes they support, but I know Gecko and Chrome have a few). At the very least you should blacklist javascript: and data:, but it would be safer to whitelist http/https until people present a case for adding to that list.

Comment 5

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I agree with sec-moderate

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1263624 to get this fixed

Comment 6

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Just a quick note that we have a patch in the works:

https://www.dropbox.com/s/f7uizhtzewk2z2y/Screenshot%202016-04-13%2014.01.18.png?dl=0

Not just for the Share extension but also for Send Tab and View Later.

Probably scheduled for 5.0.