Cookie Stealing Scripts

in discussion
Subscribe to Cookie Stealing Scripts 209 posts, 115 voices

Descriptor Scriptwright

I can't really think of any good reason for any user script to contain any form of createElement('SCRIPT'), or for that matter, contain any cloaked URL - why use a tinyurl when the full url can be used just as easily. So just the fact that a script contains http:// is a red flag.
Also will remove malicious links, spammers try and use them to get past spamurl filters.

Descriptor Scriptwright

Profiles can be created in less than a minute. You needn't even have a valid email-id.

If that's the case then spammers can use them as well, and they have already been added to spamurl filters.

Flyne Scriptwright

There are, in fact, plenty of good reasons for user scripts to attach other scripts. One is to allow the invocation of the privilege manager, allowing extra capabilities. Another is to avoid having to update code in multiple places.

Also, there are reasons to contain tinyurls, too. For example,

However, doing a simple server-side request for all obviously added "masked" code shouldn't be terribly taxing/difficult. Yes, one could get around it, but it would add another layer of security.

Bean Scriptwright

thanks to the admin for doing this....

this is what i did: as per my best part........

i reported all the malicious sites to the respective host and guess what?
all have been removed...... that person ruined all my scripts....
made them cookie stealer......

me and my friends on orkut posted "cookie Stealer" as a comment on his/her scripts and in return he posted "not working" on ours...... but they all were working fine.....
to my SHOCK .......... all those malicious comments are now removed........thanks admin

Bean Scriptwright

one more thing: that malicious script writer stole all my scripts and made them cookie stealer....... u can check the difference in his/her work and in mine..............

that ******* just made them cookie stealer...... he degraded my reputation :(

BrainCoder Scriptwright

Why my youtube script is flagged almost all?

Jesse Andrews Admin

BrianCoder, the banner is site wide, it just isn't on scripts that are bad. (we have removed all the bad scripts as they are discovered)

Descriptor Scriptwright

Also, there are reasons to contain tinyurls, too. For example,

That script does not contain tinyurls, it unmasks them. I know I should have specified more accurately http:// , but obviously anyone who looks at that script knows what it's for.
Please try to come up with better examples.

Naja Melan Scriptwright


it had to happen sometime. Im surprised it took so long before we got trouble here. I think it is a bit nonsense to think there could be any real security if you could go to a website where anyone can publish and click a button saying install this script, without reading and analysing the script. Bottom line is that we are all pretty irresponsible by doing that.

Scripts that by the way can do way more dangerous things than stealing coockies. they have access to the local filesystem... and to the entire internet. 1+1 = ?. right, By the way, can you launch an executable from a greasemonkey script? Does anyone know?

Maybe it is time to start seriously thinking about security. A page on the greasespot wiki explaining exactly what a userscript could possibly and not possibly do?

When it comes down to us.o, I think it is impossible to ask people to read and understand everything they install. First of all, not everybody that benefits from userscripts is a developer themselves. Secondly, I am working on a script and at current time, it is not finished, it is 1800 lines of code, mostly full with regex and xpath and... . How long does it take a good javascript programmer to dig through that and be absolutely sure it is safe? Right, a very long time. Let's face it. People are just not going to do it.

So, then what do we do?
1. I think the most feasable thing to do, because it can be semi-automated, is sift the +-safe scripts from the +- risky scripts, and add a warning on the risky scripts pages and ask authors to give a word of explanation about the risky features. Imagine a script that touches no coockies, does not load data from cross-domain urls, does not touch the local file system, ...( to be continued ). This script is probably quite harmless. How do you sift them though. Well, this is a bit of a challenge, but im sure it can be done.

So basically we need a way to automatically detect risky behaviour. The good thing about this is, someone already did most of the work. Hence the difference in ff between privileged and unprivileged code. If we treated GM scripts as unprivileged code until they need privileges, than a lot of scripts don't have to be checked for BS, because they simply don't do nothing dangerous. That would make it much more likely for anyone to go and check scripts if it concerned specific cases of risky behavior.

To take that one step further, if greasemonkey and us.o would be tuned in onto each other, on posting a new script we could have a developer obligatory notifying and explaining that, and what for their script needs privileges. us.o keeps track of that, and upon installing greasemonkey checks that. For example. I post a script. I don't notify about privilege requirements, then greasemonkey treats it as an unprivileged script. If the script tries to do something requiring privileges, it is blocked, the user is notified and the user has ultimate decision about making it privileged.
The other end of the scale. I have a script that needs privileges, I tick the check box on us.o, and fill in a box with explanation about why it needs this. A scripts page will clearly indicate whether it is a privileged or unprivileged script, and upon installation of a privileged script, another extra red message is added to the install box, so the user really realizes when they are doing something dangerous.

What is it all good for. Well we can save our time and not try to check if scripts are safe when they don't get privileges anyway, and focus on those that do, and focus on those extra that don't have good justification for needing privileges, and focus even more extra on those that didn't indicate needing privs while afterwards it turns out they do.

For the ease of the genuine developer, who does not try to masquerade anything, but just forgets that their script needs privs, we might do a scan on the code, and signal if it looks like it needs privs when none where asked...

The best thing of all is, you can do 99% of all things without needing privs. People should be encouraged to write scripts that don't use privileges if it is not needed. I think greasemonkey and firefox should improve their featureset. My 1800 line script would still run perfectly without privs, if I only found a way to access frames (not x-domain), without unsafe window. Unfortunately XPCNativeWrapper does not support frames. Most of the things people need privs for, I think, are things that have to do with unsafeWindow, and most of these could be resolved without privileges if the feature set of XPCNativeWrapper was slightly expanded.
A page on greasespot wiki explaning how to make sure that your script doesn't use privs it doesn't need, would also be nice.

Ideally speaking, the most common needs for privileges should be assessed, and than ff and gm should be improved, if possible to support those things without privileges, and then, we can probably reduce the number of scripts that needs to be controlled to about 1% (< - well, just guessing), and we can for sure figure out a way to check those 1%.

A number of people on us.o for example could be known to be trustworthy, and they could easily check short scripts without investing much time. Those could then be marked as safe, and that would further reduce the amount of scripts that users need to be careful with to an acceptable level.

Of course everytime a script is updated it needs to be checked again, but if there is a prior safe version, the differences could be marked, and thereby it would not be much work to verify the new version.

Furthermore, I think that us.o would not be harmed by a clear place to report malicious code, like a separate forum, something that will be checked by admins (well better, that sends notifications to them) even if they don't have time to look at anything else...

The one disadvantage that i see in this is that someone will have to spend time to build a such a system, to work on ff, to work on gm. It is all a time consuming business... If we want to move to a securer place, this is kind of how i would do it...

I would not support this look on security:

However, doing a simple server-side request for all obviously added "masked" code shouldn't be terribly taxing/difficult. Yes, one could get around it, but it would add another layer of security.

It will catch all the legitimate scripts, and not the malicious. In such a case lets not give people the idea that things have become safer. Security either works, or it doesn't. It is like chess or igo or martial arts. You play the board, not the player. You don't do strategy that works if your opponent complies. you just don't!


Joel H Scriptwright


There's a lot there, so I'll comment as I read.

1. I agree, eventually someone would start abusing when this site became popular enough. It really is up to the individual users to monitor other scripts, but most especially the ones they download themselves. Of course this is easier for those of us who are familiar with javascript, and the uneducated basically go on faith.

2. Yes, scripts can "do way more dangerous things than stealing coockies" (whatever coockies are :), but no, they absolutely do not have access to the local file system (this was a limitation placed on the XMLHTTPRequest object), and you absolutely cannot run executables. You cannot even download files without user approval (though you can initiate a download by redirecting to a downloadable file)

3. Security is, and always has been, a big issue. I agree that there should be a page on the wiki outlining the risks you take installing foreign scripts.

4. It is possible to make sure a given script is safe by looking for a few simple things, among them are any calls to XHR, eval statements, unsafeWindow, and base 64 encoding (again, all of which do have valid uses, but they should set off red flags to be investigated). Most experienced coders can glance at a section and see simple dom manipulation and know it's safe, though being Absolutely Sure is harder to do.

5. It would be very difficult to create a system that incorporates GM with us.o, because it would require updating not just this site, but the Greasemonkey extension itself. From what I gather, those devs are already overwhelmed with tickets to work on.

6. I agree that scripts probably could (should?) be flagged as 'risky' if they contain certain things, like those I mentioned above. It may then be feasible to allow either all users, or a specific set of 'trusted' users to Approve a script, so that normal users can gain some measure of assurance when they see that 10 trusted users all agree that it's safe.

7. I agree that defensive White Hats will always be at a disadvantage to the Black Hats because the Whites have to be better every time, whereas the Black have to get lucky just once. Really the only truly safe method is to require that everyone know javascript and either write their own scripts, or strongly suggest that they review any scripts before they install. Of course, that is completely unreasonable.


Naja Melan Scriptwright

Sorry for my confusion about local file access. It used to be possible, and it was fixed by this in xmlhttprequester.js:

  // This is important - without it, GM_xmlhttpRequest can be used to get
  // access to things like files and chrome. Careful.
  switch (scheme) {
    case "http":
    case "https":
    case "ftp":
        GM_hitch(this, "chromeStartRequest", url, details), 0);
      throw new Error("Invalid url: " + url);

However that leaves me even more confused, because that means it is not prevented by any privilege level, only by greasemonkey code. At what priv level does a userscript run then? As far as I new, it ran as a function from within greasemonkey.js. Does that mean it has the same privileges as the extension? That it herits the scope object from greasemonkey.js? If so, could a script not override the GM_xmlhttpRequester function to make it accept file:// ?

Im pretty new to firefox, so the innerworkings of extensions, and the browser are not completely clear to me...

BrainCoder Scriptwright

BrianCoder, the banner is site wide, it just isn't on scripts that are bad. (we have removed all the bad scripts as they are discovered)

I was talking about the fact that most of the code is highlighted in red...

Descriptor Scriptwright

Descriptor Scriptwright

@BrainCoder : I see a problem with your RegExp, you need to escape backslashes:
Try GM_log("RegExp hom = "+hom) and you'll see what I mean - you need to write a regex for period in a string as "\\." because the first slash gets parsed out.

I actually just discovered this myself, I don't use the RegExp constructor, but had to in order to use a variable in a regex.
See also: [Creating_a_Regular_Expression](
You're better off using a literal: /http:\/\/.../
Don't know if this will help the color issue though.

BrainCoder Scriptwright

Thanks Descriptor...I changed the regexes and now the code isn't highlighted anymore. I wrote this RegExps a lot of time ago and I didn't remember they were using the constructor...

Parashuram Scriptwright

May be us.o can quickly write a parser to list all the domains that the current script is trying to access. If this information is available on the home page of the script, people cam get a quick summary of the intent of the script.

I realize that this is not simple as the script may not use GM_XMLHTTPRequest, but could also construct something like <image src="">, but a good parser that executes the script could be able to catch it.

Any thoughts ?</image>

pogue User

If anyone sees a script like this, please send it to me - pogue[at] and I'll explain how to contact the ISP where the cookie hosting script is located and give a short description on how to report these to their abuse department so they can be stopped very promptly.

BTW, I also recommend everyone install the [NoScript]( extension for Firefox which prevents [Cross-site scripting (XSS)]( from being loaded into your browser. I am not sure if GM scripts can overwrite this function, but it is just an added level of protection against this sort of thing.

It also might be a good idea for to implement the following security precautions (if others have mentioned this previously, I apologize, I didn't read over all the posts in this thread:

  • Implement email verification for registration
  • Add CAPTCHAs for registration
  • Scan code of all uploaded scripts for certain obvious cookie stealing techniques and then either block them or enable another user to verify them before being allowed to downloaded
  • Add a "report this script to admin/mod" button to each page where a script is posted on

Joel H Scriptwright

I like the first two ideas, pogue.

The third idea is also good, but would require quite a bit of computing time and would block only the most form-cut scripting attacks. Fortunately, I think that's what we're dealing with at the moment.

In principle, I like the idea of reporting a script directly to an admin. However, we kind of already have this in the form of this very thread, as well as the Spam and Malware thread. So this is kind of useless unless you want something more advanced, like actively emailing or im-ing an admin.

Perhaps there could be a subset of "trusted, but not admin" users that could Quarantine scripts, disallowing downloads (and re-uploads), so that a problem script could be mitigated without need for an actual admin to remove the script. I think it might help reduce the number of downloads of problem scripts. Unfortunately, it may not be necessarily healthy for the social environment on the site to mark certain users but not others. As a result, I would set hard criteria, such as:

Two of:
-member for more than a year,
-more than 10 scripts
-more than 100 posts

Of course the numbers may be tweaked, but in principle it would make it clear who has this privilege and why (so no Admin favorites). Also, as the current admins would have to grant this privilege, you couldn't spam yourself 10 empty scripts and 100 useless replies and then quarantine every script on the site.

I realize this would be quite a bit of work on the site, but it may be worth it.


Descriptor Scriptwright

I think what would work nicely is some type of rating system, perhaps bananas and coconuts? But not based on number of posts or scripts - what's the point of that?
  1. Scripts could have ratings
    • Number of installs may be an indication of popularity, but that doesn't mean it works, it's good, or that people liked it - only that people tried it
    • Anyone should be able to rate a script
    • Ratings should be negative or positive
    • Possibly voters could change their vote later
    • To prevent abuse, people (members) should only be able to vote once, and the author can't vote on their own script.
  2. There should be a report button this should probably be #1
    • Report script as malicious or spam
    • Report script as duplicate
    • Report post as spam
    • Report comment as spam
    • Only members could report and only one report per member
    • Reports go into a database that records the script or post number, the script rating or member that posted the spam, the reporter's member name and ranking
    • It might be useful for reports to go against a script's rating
  3. Reporters get bananas, or coconuts to throw at spammers - a Ranking
    • Good reports add to a member's ranking
    • Posting spam or malicious scripts lowers a member's ranking
    • Reports are "weighted" based on the rank of the reporter
    • A good reporter quickly gets a high ranking, giving their reports more weight
    • A few low ranked reports, especially on highly rated scripts, can be ignored
    • And finally, bad reports could lower a member's rank, or at least not improve it any
  4. Admins and maybe certain privileged members can access the report database
    This should make it easier for them to review and act on the info, it should be easy to format the info and adjust rankings.

Now I'm not a big fan of popularity ratings, I'm rarely interested in the things that "most other people" are, and a lot of very good but "unpopular" scripts will have no rating at all. However there should be some way to notify users, especially non-members that don't interact, that a script might be malicious, don't work well or just plain bad. Ratings are good for that. consider a scenario where you voted high on a good script, but then it stops working and the author is not around to fix it, being able to change your vote would be useful.

Also we need some way to generate a red flag quickly. We already have good reporters here who spend a lot of time to post a message, but can't do much to warn anyone. If it was easier, more people would report, good reporters get a higher ranking, a high-ranked report can put up a red flag immediately that everyone can see.

I believe with this type of system this site could nearly be self moderated. It only takes 3 values - a reporter/member Rank, a Warning for high-rated reports, and a popularity rate which probably isn't really necessary. Spammers could literally get voted right out of existence.
It only requires that someone validate the reports, which wouldn't be any different than it is now, but certainly ought to be much easier.

Oh, one thing I forgot, I don't think a member's rank needs to be public, it's just a value added to the report and I don't see how it would be useful for anything else

Bean Scriptwright


it's urgent........... please remove this user

it's a cookie stealer......

pogue User

@Descriptor: Those all sound like excellent ideas.

Also, I want to say something again for anyone who has missed it. PLEASE email me one of these cookie stealing scripts that are being posted to Image Hosted by and I will write a short post about how users can identify these scripts themselves and report the website hosting these scripts to the ISP involved. Thanks,

Naja Melan Scriptwright

Could anyone explain me how you check such a script? It's done with a cruncher i think, as well as stringFromCharCode stuff eg.

looks nice for the rest, but im waiting to install.

Richard-Valley User

NOTE: This is how I checked my scripts for malicious code in Windows. If a script is found with this method, it is important to uninstall the script via Greasemonkey, and not just deleting the file from the folder (the later method could corrupt your config file, causing you to have to reload all your scripts).

In Windows, the scripts are located in the gm_scripts folder, which is located in your Firefox profile (and can be found with desktop search).

Having opened this scripts folder, I switched to details view, and sorted the script files by date.

As Windows dates each file when it was created and modified, I focused on the files since mid-June (I assume this has not been an issue prior).

Accordingly, I opened and searched all the script files for the term "cookie" to locate any malicious code in any of the scripts I use.

Hopefully, this deals with checking any scripts I currently use (have on my computer).

V-i-k-a-s P-... Scriptwright


Please visit my script page:

The user Radion ( commented:
-- start
COOKIE stealer!!!!!

cookie stealer!!!!!


-- end

That is absolutely false, misleading and malicious comment. Anyone can check that my script is not at all dealing with cookies.

Requesting admin to please have a look at my script source, and remove that intentionaly malicious comment that might have scared several users away from my script. hope some action would also be taken against the said user who joined on July 8, 2007 and posted that comment that very day. He doesn't have any script or any other comment till date, so he must have made that id only for making that comment.


Deb Morrissey Scriptwright

Re: a rating system

We already have a de facto system that points out when users really like a script: the favorites. In addition to listing how many times a script has been installed, could we also see how many users have marked it as a favorite? That would usually indicate, to me, a particularly useful script.