371923 - (bookmarklet-warning) Show a warning when a user tries to bookmark a javascript: url

Status: NEW

(Core :: Security, enhancement)

Description

[Martijn Wargers (dead)]

This is basically a reprise from bug 28387, we might want to reconsider this.
I opened this bug, because of the discussion in bug 371179.
IE gives a confirm dialog when you want to add a bookmarklet to your bookmarks, so maybe we want to do something similar as IE?

Comment 1

[Jesse Ruderman]

I think we should come up with a new UI for "user-script buttons" to replace the concept of bookmarklets.  Mixing these buttons with bookmarks is suboptimal and constraining in many ways.

Comment 2

[Brandon Sterne (:bsterne)]

Before I file a new bug, I wanted to check if this would be an appropriate bug to hijack.  We want to add UI that would require more explicit action by a user before they can install or execute a bookmarklet.

One option is to add a checkbox per bookmark in the Bookmarks Manager that would be required to be checked before the bookmark is permitted to run script.

Another option is to require a bookmarklet be "installed" before it can run, and to make the bookmarklet installation appear similar or identical to the add-on installation flow.

Let me know if you want a new bug for this, or if we can do the work here.

Comment 3

[Justin Dolske [:Dolske]]

Given the recent social-engineering aspects of this (and the general suckyness of user warnings, in general), I think we should just disable/ignore attempting to bookmark such URIs (are there other cases? Should we whitelist to just http/https/ftp?) I'd probably be ok with allowing existing bookmarklets to work if it's not a hassle.

One thing I'm not sure of is how successful an attack would be that asks users to modify an existing bookmark to use a js URL. [EG "nice hack to look anyone's facebook page! Just bookmark facebook, blah blah edit it to js:// blah blah, now visit FB and click the special bookmark!"] I suspect that would still work well enough. :( Given that bookmarklets are already kind of an edge-case use (although semi-popular), killing them entirely is something we should consider.

Comment 4

[Brendan Eich [:brendan]]

Comment 1 is asking for a different bug to be filed and fixed. Whatever we do for user scripting, bootkmarklets are out there and they won't go away quickly.

/be

Comment 5

[Jesse Ruderman]

For data: URLs, fixing bug 656823 would be better.

Comment 6

[Jesse Ruderman]

I filed bug 774065 for comment 1.

Comment 11

[Muaz Bin Abdus Sattar]

Very old bug and many reporters already reported it. :o
By the way, although it's an one kind of Self-XSS, but I think it need to be RESOLVE. Cause I see it with another angle. There are a lot of cyber cafes, libraries in every countries where everyone can use public computer. Any malicious user can create a bookmark with JS payload with attractive name so that victim can click on it.

In my opinion, it need to be RESOLVE. But thank you for mention me here. :)

Comment 13

[Luigi Gubello]

In my private ticket 1567780 I have attached a proof-of-concept video where you can see that there are situations where this bug is not a self XSS and it becomes an universal XSS. My ticket was closed and classified as Duplicate, and it is ok, but this bug is not a self XSS. So my question is: if you consider this bug a self XSS and you don't think to fix it, can I make public disclosure?

Best regards, Luigi

Comment 18

[Marco Bonardo [:mak]]

In Bug 1725487 we'll open the bookmark dialog when the user drops a javascript url to a bookmarks view, rather than just creating the bookmark immediately.
What's left to do here is adding some warning/notification text close to the location field when it points to a javascript url, potentially explaining it may be dangerous and source of that code should be trusted.
That requires some UX.