Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 1:46 PM, Adam Barth wrote: > On Thu, Jul 22, 2010 at 1:41 PM, Aryeh Gregor > > > wrote: > > On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison > wrote: > >> There is no legitimate reason that non-developers would need to paste > >> "javascript:" URLs into the addressbar, and the ability to do so > >> should be disabled by default on all browsers. > > > > Sure there is: bookmarklets, basically. javascript: URLs can do lots > > of fun and useful things. Also fun but not-so-useful things, like: > > > javascript:document.body.style.MozTransform=document.body.style.WebkitTransform=document.body.style.OTransform="rotate(180deg)";void(0); > > > > (Credit to johnath for that one. Repeat with 0 instead of 180deg to > > undo.) You can do all sorts of interesting things to the page by > > pasting javascript: URLs into the URL bar. Of course, there are > > obviously security problems here too, but "no legitimate reason" is > > much too strong. > > We could allow bookmarklets without allowing direct pasting into the > URL bar. That would make the social engineering more complex at > least. > > Adam > Would a pop-up warning be sufficient, rather than disallowing it? For example, if I write the following URL into Firefox... http://char...@49research.com/ ... Firefox will pop-up a modal dialog box with the following message... > You are about to log in to the site "49research.com" with the username > "charles", but the website does not require authentication. This may be an > attempt to trick you. > > Is "49research.com" the site you want to visit? > > [yes] [no] > Perhaps a modal dialog box could pop-up for copy-and-pasted JavaScript URLs to (after the user presses enter). -- Charles Iliya Krempeaux, B.Sc.
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, 22 Jul 2010, Luke Hutchison wrote: > > There has been a spate of facebook viruses in the last few months that > have exploited social engineering and the ability to paste arbitrary > javascript into the addressbar of all major browsers to propagate > themselves. Typically these show up as Facebook fan pages with an > eye-catching title that ask you to copy/paste a piece of javascript into > the addressbar to show whatever the title is talking about. However > doing so scrapes your facebook friends list, and the virus mails itself > to all your fb friends. [...] > > There is no legitimate reason that non-developers would need to paste > "javascript:" URLs into the addressbar, and the ability to do so should > be disabled by default on all browsers. (Of course this would not > affect the ability of browsers to successfully click on javascript > links.) This seems like a UI issue, so I haven't changed the spec (it doesn't really talk about the location bar -- indeed it doesn't even require that one be visible at all). However, should anyone want to discuss this further, e.g. to organise browser vendor plans, you are welcome to do so. On Thu, 22 Jul 2010, Boris Zbarsky wrote: > On 7/22/10 5:03 PM, Mike Shaver wrote: > > What should the URL bar say when the user clicks a javascript: link > > which produces content?five! > > This part the spec actually covers, I think; the url bar is supposed to say > the url of the page that link was on, iirc. Which is what I think everyone > but Gecko does already; we actually show the javascript: url in the url bar in > this case. Well, the requirement (search for "override URL" to see what we're talking about here) isn't on the location bar per se -- it's just on what "the document's address" is, which is used in some of the APIs. You don't have to show that, indeed you could show both, or something else, or nothing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On 24.07.2010 02:33, Bjartur Thorlacius wrote: Wrong. Plain wrong. Kids who like to test stuff do things like this. I do agree though that the urlbar isn't the right place, there should be a different prompt for this kind of stuff. Probably disabled at compile time by default and accessible by recompile (or addon). Not everybody who executes JavaScript Code using the address bar is a Linux freak who knows how to compile a browser. This mustn't be a hard-accessible configuration option. I really don't like the idea of disallowing it totally. It should suffice to prompt the user whether he is sure he want's to execute the script.
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
> 99.% of people have never manually entered a javascript: URL > into a browser addressbar in their life -- unless duped by a social > engineering virus. Wrong. Plain wrong. Kids who like to test stuff do things like this. I do agree though that the urlbar isn't the right place, there should be a different prompt for this kind of stuff. Probably disabled at compile time by default and accessible by recompile (or addon).
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
I second that call. While your suggestion seems to prevent some existing social engineering, you must realize that HTML5 isn't going to be recommended until ~2020. By that time, everything we talk about social engineering today will be completely obsolete. Things like this are best left to be taken care by UA vendors. I suggest that you write a formal request and send it to major UA vendors such as Apple, Google, Microsoft, Opera, etc... On Fri, Jul 23, 2010 at 8:26 AM, João Eiras wrote: > On Thu, 22 Jul 2010 21:32:39 +0100, Luke Hutchison > wrote: > > [snip] >> >> Comments, please? >> > > This is entirely out of scope of any specification and 100% an user agent > UI issue. > >
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, 22 Jul 2010 21:32:39 +0100, Luke Hutchison wrote: [snip] Comments, please? This is entirely out of scope of any specification and 100% an user agent UI issue.
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
I should add that to complicate things, not all the social engineering directions make it clear to the user that they will be pasting stuff into the addressbar: e.g. I got one called "World's Hardest Riddle" that selected the text in the box for you somehow and then told the user that to see the riddle they had to type Ctrl-C, Alt-D, Ctrl-V, Enter. (i.e. copy, go to addressbar, paste, enter -- but how many users even know what Alt-D does?? Most users would just think this was some magic key sequence used to unlock the riddle...) Thanks for the link to the Firefox bug, Daniel -- looks like you came across the same trick as described in your comment.
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On 7/23/2010 6:35 AM, Luke Hutchison wrote: On Thu, Jul 22, 2010 at 5:39 PM, Boris Zbarsky wrote: 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. In whatever security mechanism is worked out, besides preserving the ability for people to be able to use the URL bar for potentially privileged bookmarklets if they wish (even if they must give permission after receiving a specific warning), I would actually like to see the privileges available to bookmarklets expanded, upon explicit warnings and user permission. For example, it would be of enormous use to be able to link someone to a specific site, while manipulating the view of that page such as to mash over the data with tooltips mash down some data from it to a smaller set, mash up the data with additional notes/sources (whether from other sites or text found on the source page), or mash under the data with semantic markup changes or highlighting of specific text. I know this is absolutely dangerous, but if people can install extensions which can wipe out hard-drives with a two clicks and a restart (and thank God that such power exists in browsers like Firefox so people can make extensions which do access the file system for positive uses), there should be a way, such as with dead-serious warnings (and I'll concede disallowing https), that people can mash an existing source and still work in its scope (just as I think there should be the ability to run cross-domain Ajax after getting user permission). Greasemonkey is great, but it would be nice for there to be a standard, especially for uses as referring people immediately to a specific subset of content on another page. Brett
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
If javascript URI entry support/execution in my address field went away, I'd be very pissed! A JS console in the dev tools is not the same usability-wise. I might get over it *after a while* if it was off by default with an option to re-enable it though. For example, I could imagine having separate "support bookmarklets" and "support javascript URIs in the address field" options that were both unchecked by default. However, javascript URI support in the address field has never been a problem for me, so I don't like this idea myself. (But, I'm often willing to sacrifice for the greater good) -- Michael
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
Note that for Mozilla this is basically bug 305692: https://bugzilla.mozilla.org/show_bug.cgi?id=305692 I mentioned Facebook in comment 9. Daniel Cater. On 22 July 2010 21:32, Luke Hutchison wrote: > There has been a spate of facebook viruses in the last few months that > have exploited social engineering and the ability to paste arbitrary > javascript into the addressbar of all major browsers to propagate > themselves. Typically these show up as Facebook fan pages with an > eye-catching title that ask you to copy/paste a piece of javascript > into the addressbar to show whatever the title is talking about. > However doing so scrapes your facebook friends list, and the virus > mails itself to all your fb friends. > > Frequently these viruses will redirect to a legit-looking page after > propagating themselves, so the user doesn't know they have been duped > until one of their friends ask why they sent out the link. In most > cases nobody says anything because it looks like a legitimate shared > link (and there's so much junk shared on facebook anyway that nobody > can tell the difference!) -- as a result these viruses have been > wildly successful, accumulating tens of thousands of "Like"s before > anybody even reports the page as spam. > > An example: > > http://code.google.com/p/chromium/issues/detail?id=44796 > > There is no legitimate reason that non-developers would need to paste > "javascript:" URLs into the addressbar, and the ability to do so > should be disabled by default on all browsers. (Of course this would > not affect the ability of browsers to successfully click on javascript > links.) > > The above bug report was closed with the following suggestion: "to get > traction on this, I'd suggest looping in other browser vendors. The > WHATWG list might be appropriate. These sorts of changes work best > when all browser vendors move in unison." > > Comments, please? > > -- > Luke Hutchison >
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 7:17 PM, Paul Ellis wrote: > This seems to be the wrong venue for this discussion but it is worth noting > that IE8 doesn't allow drag-and-drop of javascript: links to the favorites > bar. If you do right-click->Add to Favorites for a javascript: link it > prompts "You are adding a favorite that might not be safe. Do you want to > continue?" So clearly they think there is some security risk there. It > doesn't impede a user from copying the link though and pasting it in the URL > bar though. All the browsers do this for extensions, and Chrome does it for its pure-JS extensions as well as for Greasemonkey scripts. It's actually quite surprising that none of the browsers other than IE8 protect against bookmarklets the way they protect against extensions. On Thu, Jul 22, 2010 at 7:17 PM, Paul Ellis wrote: > Even though I regularly type JavaScript in the URL bar I think it would be a > smart change to make that disabled by default. There are already other > things I go into about:config for. :) > > Paul Ellis I'm happy to move the discussion to another venue if somebody can suggest a venue that the idea may have sufficient traction with the different browser vendors. (Or are they all here on this list and they're not really gathered in one place on a list anywhere else? Should there be another list on this site for issues outside the WHATWG spec discussion, maybe?) Luke
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 2:48 PM, Mike Shaver wrote: > On Thu, Jul 22, 2010 at 5:32 PM, Luke Hutchison > wrote: > > On Thu, Jul 22, 2010 at 5:03 PM, Mike Shaver > wrote: > >> Would a UA that asked for the > >> user's permission the first time a bookmarklet is used (like some > >> prompt the first time a given helper app or URL scheme is used) be > >> compliant? > > > > You mean like Windows User Account Control? ;) > > 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. > This seems to be the wrong venue for this discussion but it is worth noting that IE8 doesn't allow drag-and-drop of javascript: links to the favorites bar. If you do right-click->Add to Favorites for a javascript: link it prompts "You are adding a favorite that might not be safe. Do you want to continue?" So clearly they think there is some security risk there. It doesn't impede a user from copying the link though and pasting it in the URL bar though. Even though I regularly type JavaScript in the URL bar I think it would be a smart change to make that disabled by default. There are already other things I go into about:config for. :) Paul Ellis
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 5:48 PM, Mike Shaver 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 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
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 5:32 PM, Luke Hutchison wrote: > On Thu, Jul 22, 2010 at 5:03 PM, Mike Shaver wrote: >> What is the proposed change to which specification, exactly? URL-bar >> behaviour, especially input permission, seem out of scope for the >> specs that the WHATWG is working on. > > Is there a better venue to discuss this then? (It seems like even if > UI issues are out of the scope of what WHATWG is working on, all the > right people are signed up to this list...) I'm not sure of a better venue off-hand. I don't think that there's anyone from Microsoft participating in this list, though, and I expect that a lot of the users affected by the Facebook viruses are using their browser. >> Would a UA that asked for the >> user's permission the first time a bookmarklet is used (like some >> prompt the first time a given helper app or URL scheme is used) be >> compliant? > > You mean like Windows User Account Control? ;) 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. > Given the success of these exploits so far, it is also reasonable to > suggest that the sophistication of attack will only increase with > time. Yes, which I think is why so many of us are suggesting that making the social engineer say "drag this link to your bookmark bar, and use it when you Really Like something!" is not going to be much of a mitigation. It's not that I don't believe it's a problem, to be clear; it's that I don't think you're proposing a meaningful solution to it! Mike
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 1:46 PM, Adam Barth wrote: > On Thu, Jul 22, 2010 at 1:41 PM, Aryeh Gregor > wrote: >> On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison wrote: >>> There is no legitimate reason that non-developers would need to paste >>> "javascript:" URLs into the addressbar, and the ability to do so >>> should be disabled by default on all browsers. >> >> Sure there is: bookmarklets, basically. javascript: URLs can do lots >> of fun and useful things. Also fun but not-so-useful things, like: >> javascript:document.body.style.MozTransform=document.body.style.WebkitTransform=document.body.style.OTransform="rotate(180deg)";void(0); >> >> (Credit to johnath for that one. Repeat with 0 instead of 180deg to >> undo.) You can do all sorts of interesting things to the page by >> pasting javascript: URLs into the URL bar. Of course, there are >> obviously security problems here too, but "no legitimate reason" is >> much too strong. > > We could allow bookmarklets without allowing direct pasting into the > URL bar. That would make the social engineering more complex at > least. That was my initial thought too, but I'm not sure that would help very much since that would just change the social engineering attack from "copy this text and paste it in the url bar" to "create a bookmark with this url and then go there" or "bookmark this url, then visit facebook and load it". / Jonas
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On 7/22/10 5:32 PM, Luke Hutchison wrote: Well, is it the simplest one, though? If closing it will do nothing for security but just inconvenience people, what's the point? I'd really rather not have us doing security theater just to look like we're doing something. 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) would be several orders of magnitude smaller than that number. Given the success of these exploits so far, it is also reasonable to suggest that the sophistication of attack will only increase with time. I'll note that you didn't actually answer my question, which was whether changing the behavior here would actually have tangible security benefits. 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). But it doesn't sound like you're suggesting that... and what you're suggesting seems to only close one of at least two equally easy to target social-engineering attacks. In other words, its usefulness as a security measure relies on its not being implemented yet; the moment it's implemented the virus writers will switch to the other attack, no? 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 -Boris
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 5:03 PM, Mike Shaver wrote: > What is the proposed change to which specification, exactly? URL-bar > behaviour, especially input permission, seem out of scope for the > specs that the WHATWG is working on. Is there a better venue to discuss this then? (It seems like even if UI issues are out of the scope of what WHATWG is working on, all the right people are signed up to this list...) > Would a UA that asked for the > user's permission the first time a bookmarklet is used (like some > prompt the first time a given helper app or URL scheme is used) be > compliant? You mean like Windows User Account Control? ;) On Thu, Jul 22, 2010 at 5:02 PM, Maciej Stachowiak wrote: > 2) One possibility is to make javascript: URLs an optional > developer-only feature in the UI. I don't know if we could get > away with completely removing support in the address bar. That would be the ideal solution. On Thu, Jul 22, 2010 at 5:19 PM, Boris Zbarsky wrote: >> Just because there are two vectors for exploitation doesn't mean you >> shouldn't close the simplest one to exploit :-) > > Well, is it the simplest one, though? If closing it will do nothing for > security but just inconvenience people, what's the point? I'd really rather > not have us doing security theater just to look like we're doing something. 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) would be several orders of magnitude smaller than that number. Given the success of these exploits so far, it is also reasonable to suggest that the sophistication of attack will only increase with time.
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On 7/22/10 5:03 PM, Mike Shaver wrote: What should the URL bar say when the user clicks a javascript: link which produces content?five! This part the spec actually covers, I think; the url bar is supposed to say the url of the page that link was on, iirc. Which is what I think everyone but Gecko does already; we actually show the javascript: url in the url bar in this case. -Boris
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 4:48 PM, Tab Atkins Jr. wrote: > These days, though, all major browsers have javascript consoles which > you can bring up and paste that into. That doesn't typically apply to content tabs or windows, though. I have a couple of questions: What is the proposed change to which specification, exactly? URL-bar behaviour, especially input permission, seem out of scope for the specs that the WHATWG is working on. Would a UA that asked for the user's permission the first time a bookmarklet is used (like some prompt the first time a given helper app or URL scheme is used) be compliant? What should the URL bar say when the user clicks a javascript: link which produces content? five! Mike
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Jul 22, 2010, at 1:32 PM, Luke Hutchison wrote: > There has been a spate of facebook viruses in the last few months that > have exploited social engineering and the ability to paste arbitrary > javascript into the addressbar of all major browsers to propagate > themselves. Typically these show up as Facebook fan pages with an > eye-catching title that ask you to copy/paste a piece of javascript > into the addressbar to show whatever the title is talking about. > However doing so scrapes your facebook friends list, and the virus > mails itself to all your fb friends. > > Frequently these viruses will redirect to a legit-looking page after > propagating themselves, so the user doesn't know they have been duped > until one of their friends ask why they sent out the link. In most > cases nobody says anything because it looks like a legitimate shared > link (and there's so much junk shared on facebook anyway that nobody > can tell the difference!) -- as a result these viruses have been > wildly successful, accumulating tens of thousands of "Like"s before > anybody even reports the page as spam. > > An example: > > http://code.google.com/p/chromium/issues/detail?id=44796 > > There is no legitimate reason that non-developers would need to paste > "javascript:" URLs into the addressbar, and the ability to do so > should be disabled by default on all browsers. (Of course this would > not affect the ability of browsers to successfully click on javascript > links.) > > The above bug report was closed with the following suggestion: "to get > traction on this, I'd suggest looping in other browser vendors. The > WHATWG list might be appropriate. These sorts of changes work best > when all browser vendors move in unison." > > Comments, please? Interesting idea, but out of scope for the spec. This is a UI issue, not a content issue. HTML5 has no authority over what happens when the user types in the address bar. Here's some thoughts on the idea of making this change: 1) We probably can't disallow javascript: in bookmarks since many popular user features are distributed as bookmarklets. Does this still leave too much avenue for social engineering attack? 2) One possibility is to make javascript: URLs an optional developer-only feature in the UI. I don't know if we could get away with completely removing support in the address bar. Regards, Maciej
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On 7/22/10 4:46 PM, Luke Hutchison wrote: A bookmark is more like a link than a manually-entered URL What would prevent the viruses in question from saying "drag this link to your bookmarks bar and then click the bookmark"? Note that this is something that sites actually do... not necessarily commonly, but often enough. http://www.google.com/reader/settings the "Goodies" tab is an example. Or http://lab.arc90.com/experiments/readability/ for that matter. 99.% of people have never manually entered a javascript: URL into a browser addressbar in their life -- unless duped by a social engineering virus. I agree, but the duping for bookmarks seems just as simple -Boris
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 1:41 PM, Aryeh Gregor wrote: > On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison wrote: >> There is no legitimate reason that non-developers would need to paste >> "javascript:" URLs into the addressbar, and the ability to do so >> should be disabled by default on all browsers. > > Sure there is: bookmarklets, basically. javascript: URLs can do lots > of fun and useful things. Also fun but not-so-useful things, like: > > javascript:document.body.style.MozTransform=document.body.style.WebkitTransform=document.body.style.OTransform="rotate(180deg)";void(0); > > (Credit to johnath for that one. Repeat with 0 instead of 180deg to > undo.) You can do all sorts of interesting things to the page by > pasting javascript: URLs into the URL bar. Of course, there are > obviously security problems here too, but "no legitimate reason" is > much too strong. These days, though, all major browsers have javascript consoles which you can bring up and paste that into. As with Adam's suggestion of allowing bookmarklets, this would push such attacks further into the "too much effort to be effective" path, unlike the "copy+paste into address bar" that javascript: urls allow right now. ~TJ
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
A bookmark is more like a link than a manually-entered URL, and as mentioned in the original email, the browser will have to of course keep working with javascript: links. 99.% of people have never manually entered a javascript: URL into a browser addressbar in their life -- unless duped by a social engineering virus. On Thu, Jul 22, 2010 at 4:41 PM, Aryeh Gregor > wrote: > On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison > wrote: > > There is no legitimate reason that non-developers would need to paste > > "javascript:" URLs into the addressbar, and the ability to do so > > should be disabled by default on all browsers. > > Sure there is: bookmarklets, basically. javascript: URLs can do lots > of fun and useful things. Also fun but not-so-useful things, like: > > > javascript:document.body.style.MozTransform=document.body.style.WebkitTransform=document.body.style.OTransform="rotate(180deg)";void(0); > > (Credit to johnath for that one. Repeat with 0 instead of 180deg to > undo.) You can do all sorts of interesting things to the page by > pasting javascript: URLs into the URL bar. Of course, there are > obviously security problems here too, but "no legitimate reason" is > much too strong. >
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 1:41 PM, Aryeh Gregor wrote: > On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison wrote: >> There is no legitimate reason that non-developers would need to paste >> "javascript:" URLs into the addressbar, and the ability to do so >> should be disabled by default on all browsers. > > Sure there is: bookmarklets, basically. javascript: URLs can do lots > of fun and useful things. Also fun but not-so-useful things, like: > javascript:document.body.style.MozTransform=document.body.style.WebkitTransform=document.body.style.OTransform="rotate(180deg)";void(0); > > (Credit to johnath for that one. Repeat with 0 instead of 180deg to > undo.) You can do all sorts of interesting things to the page by > pasting javascript: URLs into the URL bar. Of course, there are > obviously security problems here too, but "no legitimate reason" is > much too strong. We could allow bookmarklets without allowing direct pasting into the URL bar. That would make the social engineering more complex at least. Adam
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison wrote: > There is no legitimate reason that non-developers would need to paste > "javascript:" URLs into the addressbar, and the ability to do so > should be disabled by default on all browsers. Sure there is: bookmarklets, basically. javascript: URLs can do lots of fun and useful things. Also fun but not-so-useful things, like: javascript:document.body.style.MozTransform=document.body.style.WebkitTransform=document.body.style.OTransform="rotate(180deg)";void(0); (Credit to johnath for that one. Repeat with 0 instead of 180deg to undo.) You can do all sorts of interesting things to the page by pasting javascript: URLs into the URL bar. Of course, there are obviously security problems here too, but "no legitimate reason" is much too strong.
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
Personally, I write JavaScript URLs in the address bar all the time, but I might not be a typical user. :) This sounds like a great opportunity for a CSP directive. Adam On Thu, Jul 22, 2010 at 1:32 PM, Luke Hutchison wrote: > There has been a spate of facebook viruses in the last few months that > have exploited social engineering and the ability to paste arbitrary > javascript into the addressbar of all major browsers to propagate > themselves. Typically these show up as Facebook fan pages with an > eye-catching title that ask you to copy/paste a piece of javascript > into the addressbar to show whatever the title is talking about. > However doing so scrapes your facebook friends list, and the virus > mails itself to all your fb friends. > > Frequently these viruses will redirect to a legit-looking page after > propagating themselves, so the user doesn't know they have been duped > until one of their friends ask why they sent out the link. In most > cases nobody says anything because it looks like a legitimate shared > link (and there's so much junk shared on facebook anyway that nobody > can tell the difference!) -- as a result these viruses have been > wildly successful, accumulating tens of thousands of "Like"s before > anybody even reports the page as spam. > > An example: > > http://code.google.com/p/chromium/issues/detail?id=44796 > > There is no legitimate reason that non-developers would need to paste > "javascript:" URLs into the addressbar, and the ability to do so > should be disabled by default on all browsers. (Of course this would > not affect the ability of browsers to successfully click on javascript > links.) > > The above bug report was closed with the following suggestion: "to get > traction on this, I'd suggest looping in other browser vendors. The > WHATWG list might be appropriate. These sorts of changes work best > when all browser vendors move in unison." > > Comments, please? > > -- > Luke Hutchison >
[whatwg] Please disallow "javascript:" URLs in browser address bars
There has been a spate of facebook viruses in the last few months that have exploited social engineering and the ability to paste arbitrary javascript into the addressbar of all major browsers to propagate themselves. Typically these show up as Facebook fan pages with an eye-catching title that ask you to copy/paste a piece of javascript into the addressbar to show whatever the title is talking about. However doing so scrapes your facebook friends list, and the virus mails itself to all your fb friends. Frequently these viruses will redirect to a legit-looking page after propagating themselves, so the user doesn't know they have been duped until one of their friends ask why they sent out the link. In most cases nobody says anything because it looks like a legitimate shared link (and there's so much junk shared on facebook anyway that nobody can tell the difference!) -- as a result these viruses have been wildly successful, accumulating tens of thousands of "Like"s before anybody even reports the page as spam. An example: http://code.google.com/p/chromium/issues/detail?id=44796 There is no legitimate reason that non-developers would need to paste "javascript:" URLs into the addressbar, and the ability to do so should be disabled by default on all browsers. (Of course this would not affect the ability of browsers to successfully click on javascript links.) The above bug report was closed with the following suggestion: "to get traction on this, I'd suggest looping in other browser vendors. The WHATWG list might be appropriate. These sorts of changes work best when all browser vendors move in unison." Comments, please? -- Luke Hutchison
