Thanks for the reply! I get what you are saying now.

Just by the nature of the sketchy-looking URL though, it would probably make most people suspicous.
(Also, it is cumbersome to copy and paste the URL so that alone would probably deter many people)
Also, with today’s browsing habits, it would be more likely that the person would open up a new tab and paste the URL in there, which would defeat the attack.

But, I am sure if you spam enough people with it, someone will eventually fall for it….

Think of social networking sites where people send silly things to each others all the time. i.e.: “you gotta try this, it’s so cool!”

The attacker doesn’t need to break into the target site and place a bookmarklet. If he can do that, he doesn’t need a bookmarklet to hijack user sessions. In fact, there are much worse things he can do anyway once he can place content on a cracked site.

It seems to me that if an attacker can place a malicious bookmarklet on a webpage, they can most likely place malicious javascript as well. Hence, it is just a standard XSS issue. I wouldn’t be surprise if there was some bizarre case in which an attacker couldn’t put a piece of javascript that automatically loads, but was able to bypass filters to put up a malicioius javamarklet. However, I would guess that this case is very limited.

I am curious to know if anyone could cite such an example??

Also, you say that browsers should warn users when they are about to run a bookmarklet but I do not think this makes much sense. It is normal in almost every web browser not to warn users when they run javascript that gets automatically loaded. So why should they start to now inform users when they run javascript that they manually load??

Doesn’t this sound a little backwards?

Anyways, I am probably missing something on these two areas. If anyone has any wisdom on these issues I would love to know.

Cheers.

@Ross: yes, there are many other scenarios in which a bookmarklet can be used to hijack a site. I just provided one example so that our readers get an idea of how bookmarklets can be used to compromise data. Nevertheless, the list of scenarios you provided are definitely quite neat!

@kuza55: you’re probably right. But there are some advantages over tricking a user to run a bookmarklet on the target site. For instance, it WON’T be picked by by content filters, AVs, etc … A drive-by download attack will be picked up by an AV provided the malware’s signature already exists on the AV’s DB.

@atom: I did mention the “annoyance” factor of showing warnings, that’s why I proposed - as an alternative - to show the warning only the *first time* a given bookmarklet is executed. This is trivial to implement by browsers. Simply generate a unique hash value for each bookmarklet, so that if the bookmarklet’s hash is already in the browser’s database, NO more warnings are shown again.

@pdp: yeah, somehow who writes each post on GC is not clear enough to our readers :)

Guys, the point here is that many people are not aware of the *security* implications of running a bookmarklet. And yes, it’s true that even when browsers return warnings many users still ignore them. Still, I want a warning for bookmarklets. Call me silly, but I think it makes sense.

Just like I still want FF to show a warning when scripting code runs within *local* context. i.e.: opening an HTML file that has been saved to the user’s desktop. In this sense IE beats FF. Lots of people don’t realize that if you open an HTML file locally which has JavaScript in it, any file can be read from the local system (i.e.: using XMLHttpRequest) among other evil things.

kuza55, I totally agree. The web is broken beyond reason. I am trying to get together a bunch of guys to come up with a sensible enough security solution for Firefox. You are more then welcome to join. On the bookmarklets thing,… well I think that there are people who are using them especially for social bookmarking purposes. Bookmarklets are not mainstream but they have the potentials to become such.

How many people even use bookmarklets? My guess is it’s a lot fewer people than the amount that use sites with dodgy SSL or download and run executables.

I would imagine it is for convenience’s sake. I would be annoyed if I had to confirm that I wanted to run the bookmarklets that I had written myself every time I clicked them.

There are 2 situations here:
* Malicious user breaks into vulnerable.site.foo and backdoors their well-known bookmarklet
* Malicious user social engineers victim to install and run bookmarklet (on X site) “You want to see something cool?!”
* Malicious user puts bookmarkets that aren’t labeled improperly somewhere like a library. The javascript:evilcode bookmarklet is labeled “Email” at the public computer for example. He hopes they click the bookmarklet at all and at the right time.

In the first case, you can probably do a lot more abusing the trust relationship a user has with an owned domain than backdooring a bookmarklet. Throw up an ActiveX file or have them download an EXE. Still no 0days needed.

In the second case, most users are probably about as likely to run an executable you pass them or type something into a shell as they are to run a bookmarklet. “Want to see something cool? Open a shell and type ‘obfuscated code here + something cool’” “Hey, want to see something cool? Use this web proxy to log in instead!” “Hey want to see something cool? Download and run this!”

Third case you could easily install something a lot more malicious on that public computer, no 0days needed. Replace the browser link on the public computer with a link to your own backdoored one (which trusts you make believe CA and logs all credentials), for example.

In this case it is just exploitation of a users trust of a given application or party, but exploiting a bookmarklet exposes your malicious intent right there in plaintext (I’m not saying most people would know).

Why don’t browser makers warn you on bookmarklets? Well, several reasons, but you seem to know yourself that users would just click through so they can see the cool effect anyway (http://www.gnucitizen.org/blog/hacking-without-0days-drive-by-java/). Users don’t even stop at invalid SSL certs.