Open Bug 371923 (bookmarklet-warning) Opened 17 years ago Updated 2 years ago

Show a warning when a user tries to bookmark a javascript: url

Categories

(Core :: Security, enhancement)

x86
Windows XP
enhancement

Tracking

()

People

(Reporter: martijn.martijn, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: blocked-ux, sec-want, Whiteboard: [sg:want?])

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?
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.
Whiteboard: [sg:want?]
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.
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 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
For data: URLs, fixing bug 656823 would be better.
Summary: Show a warning when a user tries to bookmark a javascript:/data: url → Show a warning when a user tries to bookmark a javascript: url
I filed bug 774065 for comment 1.
Blocks: self-xss
No longer blocks: self-xss
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. :)

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

Assignee: dveditz → nobody
Type: defect → enhancement
Alias: bookmarklet-warning

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.

Depends on: 1725487
Keywords: blocked-ux
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.