Topic: Userscripts.org discussion / Cookie Stealing Scripts

Hi,

isn't it time to change the read banner to some yellow banner saying something like: "please beware that userscripts can get access to the cookies of the sites they run at. Please check them before installing..."

cause i think the current banner scares most non savvy new users away before they find out what userscripts are good for....

greets

Topic: Userscripts.org discussion / Cookie Stealing Scripts

fair play frederik... didn't think of that. i never used cookies from javascript. Sorry miles.
time to shut up now,,,greets

well no, wait, if that is the only security breach, then that would reduce hazardous scripts to scripts that run on sites where you login. since this is a limited list, that would seem like a starting point to look for solutions, not? maybe people could make a list of sites where they log in, or allow greasemonkey to autodetect that, and give them an extra warning if they install scripts that run in these sites?
Best solution seeming that the website verify the ip number as well as the session ID??? But that is not in our hands.

cu

Topic: Userscripts.org discussion / Cookie Stealing Scripts

dear miles,

that is why as i already said in my post above, someone has already done this work. Hence the possibility in firefox to safely run any javascript any website fires at us. Greasemonkey scripts should be treated as unprivileged code, unless they actually need those privileges, in witch case the user can be warned and check the code before granting. Since you can do 95% of the stuff you need in userscripts without special privileges, that reduces the scripts that need to be checked to about 5%, which could be again diminished by another 95% by improving the featureset of the XPCNativeWrapper Object, like support for frames to name just one thing...

With some integration with userscripts.org, some people could check these few scripts still not covered and give them a marker to approve them, which would lead to the needed and very wanted situation of allowing most users to just click install without any worries allmost all the time....

greets
naja

Topic: Userscripts.org discussion / Cookie Stealing Scripts

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

http://userscripts.org/scripts/show/10583

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

Topic: Userscripts.org discussion / Cookie Stealing Scripts

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":
      this.chromeWindow.setTimeout(
        GM_hitch(this, "chromeStartRequest", url, details), 0);
      break;
    default:
      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...

Topic: Userscripts.org discussion / Cookie Stealing Scripts

Well,

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!

greets

Topic: Script development / "for" loops and loading in an iframe...

hi,

if you want the timeout to fire at different times, dont rely on your for loop. you have to consider they all get set pretty fast, but you are in control of the time they wait right? just give the second param of setTimeout different values. For example if you use n as a variable in your for loop, and you increment it on each go, assuming you start with 0, use this parameter: n*1000. this way the first one will fire immediately, the second after 1s, then after 2s, 3s, 4s, etc...

good luck

Topic: Script development / "for" loops and loading in an iframe...

yeah,

just learned that as well... This article seems pretty interesting on the XPCNativeWrapper issues:

http://www.oreillynet.com/lpt/a/6257

greets

ps: alien_scum, like your nifty solution...;-)

pps: in fact, after reconsideration, I think you fall for the same trap.... how where you expecting to get access to the generateURL function?
On top of that, the hole function swapPages will remain, because the eventlistener holds a reference to it. because generateURL is part of this function, it will still be there after the userscript finishes. the only question is, will it still be there when the setTimout code runs. Im not sure about that. any case it could easily be solved by this (i think, cant be bothered to test it):

btw it is still not ideal, and i think i would not use it like this in release version, because of the global variable that would be available to the host site.
After all i have come to think that often the best thing to do might be to built a wrapper of your own, and get pages with a GM_xmlhttpRequest, and then extract info from them and put it in your version of the site... this way their scripts don't run and you have total control, no? That way also the user script keeps running as long as the site is open. so these problems do no longer occur. See it more like a browser runs scripts that are programs displaying stuff for which these programs use the internet as a db to get information..., pages or xml documents from which they draw the right content to show to the user

A combination of both could do:

document.body.addEventListener( "load", swapPages );

function swapPages()
{
  for( var i = 0; i < x; ++i )
  {
    setTimeout( next, 1000*i );
  }

  function next()
  {
    if ( ++i < 100 ) 
    {
      quiklik.src = generateURL();
    }

    function generateURL()
    {
      //well obviously you have to do this yourself...lol
      //maybe you don't need this function at all. and you could just
      //concenate some strings like:
      // quiklik.scr = "www.google.com?search=" + i;
    }
  }
}

Topic: Script development / "for" loops and loading in an iframe...

• Professional javascript for web developpers by N C Zakas
• Javascript Programmer'S Reference by C Wootton

Topic: Script development / How to reaplly CSS?

In fact, after thinking about this for a while. The difficult part would seem to keep track of those visible not visible changes in the browser history. this way the back and forward buttons would not be broken.

Does anyone have an idea on how to accomplish that?

Topic: Script development / How to reaplly CSS?

hi Descriptor,

im glad i inspired you... there is indeed more to it and i also decided already to do it this way. css gets reaplied to elements you add to a page. it only doesn't if you change the id or class from an existing element.

Conclusion i made
if you have the possibility (lets assume userscripts.org), you prevent the page from loading. This you could do most of the time because people go to scripts through the search or front page. These links you replace. If they click them you run javascript. (note: the following part i have not built it yet, so the exact details i still have to work out.) You move forward in the history of the browser (or anyway make sure not to break back and forward buttons.), you load the page in the background, you make a document fragment that you fill with data you extract from the body or even head tags if you wish. This data can be processed underway, like put in a completely different structure (with id's and classes for example). then you go: body.innerHTML = ""; body.appendChild( oFragment ); and hopla you have a new site...

anyway i still posted this thread because i want to know if there is a way to have a specific element re-rendered at your command. I'm afraid there isn't...

greetz

ps: obviously this only works with sites that don't change to often. The one Im working on hasn't changed in years. It is a government site, and i doubt they will change it anytime soon...

naja

pps: to have your script work on multiple sites, like on the search page as well as the individual script pages, just make a big switch case in your script with one case per different pagetype. I believe this does really well on performance, and the code for the other pages will never be evaluated i think. If not if else will do but is presumable a little bit slower.
That way, your users only have to install 1 script. Try to make it all completely transparant, innit...

ppps: here is another nice idea. The site im doing also uses frames. so if you do a search there is a top bar which stays if you click one of the results. As a result of this when watching one page and pressing refresh, you go to the search page, not even search results, and you loose your results. it is possible to retrieve results automatically, but why would we do something like that?

We want control, so we create a page that never changes as a wrapper around everything. then load the specific pages in iframes. say we are on a page and the user wants to go back to the search results. just turn the iframe with the page invisible, and the one with the search results visible again. No trip to the server, no wait times, instant!!! Imagine the user wants to refine their search? Just turn the search page visible. It has never been away, you know, cause we send the post result to another iframe. If the user now does a new search, just post it to the results iframe, overwrite the last results, and thereby keep memory usage reasonable.

I think this is a nice way to play, and im sure this will have a lot more applications than i realise right now, but anyway i already wanted to post it....

like this. make your top bar just look like a tab bar...

cu

Topic: Script development / How to reaplly CSS?

well,
off course i could add css in the script, but it would be nice:

a) to keep all the css together since the site is fucking complex and i m going to have a hard time to display it the way i want,

b) allow other people to up/download alternatives from userstyles.org instead of having to faf about in the javascript code... I suppose there is no easier way to get the css from a seperate file from within javascript, to inject it i mean...

oh on top of that, the javascript code is a complete parser, which is now almost 1000 lines of code. It just doesn't feel good to try and squash some css in there as well. it is spagetti enough as it is...

Topic: Script development / How to reaplly CSS?

hi,

just wondering. If i had a script that gives classes and id's to elements on a page. A page that would be to complicated to do it with css only. How could I reapply the css after or while the script is running? Stylish runs before, you know...

Is there a way to tell the browser to re-render a specific element?
Have it looking up css rules for elements that receive a new class or id???
Even better ideas???

cheers