[whatwg] Please disallow "javascript:" URLs in browser address bars

On Thu, Jul 22, 2010 at 5:48 PM, Mike Shaver <mike.shaver at gmail.com> wrote:
> No, I mean like the prompts for geolocation, popup windows, first-use
> helper applications, first-use URL protocols, and similar. ?But my
> question is more about what you propose to disallow, and why you
> choose "disable" as the requirement.
>
>> It's not unreasonable to guess that the number of people
>> inconvenienced by the easy exploitability of the current behavior
>> numbers in the millions, given that Facebook has 500M users and these
>> viruses continue to spread like wildfire. ?The number inconvenienced
>> by having these URLs disabled by default (and re-enableable via a
>> developer option the first time they hit this limitation)
>
> That is only helpful against the specific case of direct paste in the
> URL bar, though, and bookmarklets aren't just a developer-only
> feature. ?They're widely used by URL-shortening services, blogging and
> micro-blogging services, and Amazon's universal wish list.

If the bookmarklets feature is important, and it has security
implications, which it does -- then the addition of bookmarklets
should be tied into the browser's whitelist/blacklist mechanisms for
protection from phishing.  In fact it would seem to be a major
omission if bookmarklets aren't already being checked against phishing
blacklists.

That may also suggest a way to handle javascript URLs typed straight
into the addressbar: all javascript URLs that don't have a known
source (being dragged from a web page) should be blacklisted by
default, and whitelist/blacklist rules should be applied to URLs that
have a known source on a webpage.

On Thu, Jul 22, 2010 at 5:39 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> I'll note that you didn't actually answer my question, which was whether
> changing the behavior here would actually have tangible security benefits.

Answer: yes, changing the behavior of the addressbar will have
tangible security benefits.  (1) Blacklisting typed javascript URLs
will close the current security hole -- otherwise that hole will
continue to be exploited for perpetuity.  (2) Yes, it's clear that
asking a user to drag a link to their addressbar to bookmark it, and
then click on it, adds additional complexity that will weed out some
users -- it's harder to exploit this.  (Asking them to open the js
console and paste code in there is definitely in the "too hard to be
worth it" category.)  And, separately from tie-in with the
anti-phishing system, Mike's solution to warn the user about
bookmarklets the first time they drag one to the address bar or
bookmarks bar is a good one (perhaps it should be done per-site?)

> ?I can see the security benefits of disallowing all cross-origin application
> of javascript: (if you don't know where it came from, don't apply it).

Yes, that is actually a really good way to put things -- javascript
typed into the URL bar is cross-origin.  (And dragging bookmarklets to
the address bar or bookmarks bar is also cross-origin, that's the
reason that a security check should be applied and/or user warning
given.)

Facebook already disallows the execution of arbitrary js code on a fan
page, of course, which is why these viruses require you to manually
copy/paste into the addressbar.

> Now if we really think the other attack is harder to carry out, that's a
> different kettle of fish, as I said. But I see no evidence of that....

No, I appreciate you bringing up the bookmarklets example.  I think
both holes should be closed.  The point is that disabling js URLs in
the addressbar by default (re-enablable with a developer option) is a
nobrainer that will only adversely impact a very small number of
people, and only until they re-enable the option.  People who would
want this enabled should be knowledgeable enough not to paste rogue js
code into their own browser.  As for bookmarklets, I think the
anti-phishing system should fix that.  The starting point would be to
blacklist all of facebook.com for javascript:* cross-site js code...

Luke

Received on Thursday, 22 July 2010 15:35:59 UTC