In the first entry in this series of entries on Greasemonkey and security, the security issues that Greasemonkey has had in the past were covered. Then in the second part of this series, the most recent security issues that were inherent to Greasemonkey were covered. And in this third and final part of this series, issues with the scripts that Greasemonkey uses, which are issues that Greasemonkey has had and may always have, are the topic.
As you probably know if you are reading this, Greasemonkey is a powerful tool that allows the users of it to do everything that can be done with JavaScript to web pages. It also has abilities that are beyond those that JavaScript usually has. And as was said before, the features that Greasemonkey has that allow its scripts to do what cannot usually be done with JavaScript can lead to issues with security. Many Greasemonkey scripts pose no security risk. Ones that simply make slight adjustments to pages, such removal of page elements, are harmless. However, there are also many more useful and powerful scripts that showcase Greasemonkey’s abilities through use of Greasemonkey’s advanced features. And these advanced features that make Greasemonkey as powerful as it is also give the scripts it uses the ability to perform malicious activity.
The source code of scripts used by Greasemonkey can be seen by all those who would want to view the source code of these scripts. Therefore, anyone who intends to do anything malicious with these scripts would certainly not be able to easily hide the fact that their scripts are malicious. There are a few things one could look for in the source code of scripts to determine whether or not they may be malicious. For example, when viewing this source code, one could get an idea of what data the script sends via the GM_xmlhttpRequest function, and could also see if the document.cookie property is being used. However, both the GM_xmlhttpRequest function and the document.cookie property have non-malicious uses. And determining whether a script is malicious or not is something that is not always easy to do. The number of Greasemonkey users who know what to look for in these scripts may not be known, although it does seem that there are many who would install scripts without knowing everything that their scripts do.
For some time on Userscripts.org, on each page in which information about a particular script is displayed, there had been a banner warning users about the possibility of scripts “stealing” cookies. In that warning was also a link to a thread of discussion which had been ongoing for several months. In that thread, users of Userscripts.org discussed implications of these security issues. The red flags that should be set off when one views the source code of these scripts was one topic that was brought up in that thread. Possible solutions to these issues were also mentioned in that thread. That thread has also been a place where requests have been made to review or remove scripts that may be malicious. It is a long thread in which many ideas and concepts are mentioned. And as I had done in the two previous entries on this topic, I attempt to summarize what is most important to know about this issue with Greasemonkey security.
The issue of what to look for in these scripts is one that needs to be mentioned. But first, I will mention a security issue that is often associated with JavaScript. Much has been said about the possibility of cross-site scripting (XSS) attacks when JavaScript is used. And in one kind of XSS attack, cookies can be stolen through use of the document.cookie property. This is a serious issue, as the data in cookies, which may include data such as a user’s authentication credentials, could be sent to another domain. An example of how this cookie stealing XSS attack could be carried out can be found here. In a cookie stealing attack similar to this kind of XSS attack, Greasemonkey scripts can be used to try to acquire the data stored in cookies. When viewing a script’s source code, one could try to see if information accessed through cookies in the scripts is sent to another website as a parameter in the URL of that website. There might also be the possibility that data in cookies could be transmitted to any site on the web via the GM_xmlhttpRequest function. However, code in scripts like these could possibly be noticed fairly easily. Still, a number of cookies may have been successfully stolen via scripts downloaded from Userscripts.org and other sites on which Greasemonkey scripts are hosted.
When an issue such as this occurs, solutions to it need to be suggested so that the necessary implementation of these solutions can occur. One set of possible solutions involve what can be done by script-hosting sites such as Userscripts.org. At this time on Userscripts.org, scripts already have sections for comments about each script. Also on Userscripts.org is that thread of discussion in which issues with scripts can be discussed. However, providing information on scripts this way may not solve the issue of keeping more casual users of Greasemonkey from installing malicious scripts before it is too late. Not all Greasemonkey users know what to look for, and it is only those who have the time and ability to look through scripts to check for malicious code who could report scripts that contain malicious code. It may be true that given enough eyeballs, security issues with Greasemonkey scripts could be shallow. But how can it be known if there were enough eyeballs on the code of a script to determine if the script poses a security risk?
There may be those who would say that the best way to solve this issue with Greasemonkey scripts could be with the use of other Greasemonkey scripts. And I actually considered writing a script that could tell automatically if there was anything in the source of a Greasemonkey script that could lead to problems. However, one user already wrote a similar script, and that script, titled “Screen Userscripts” can be found here. It should be mentioned that this script may not screen every malicious script. For example, there have apparently been scripts that use code obfuscation techniques to hide the fact they are accessing document.cookie, and obfuscated code is not something that this script detects. Use of code obfuscation techniques could be considered a red flag in a script’s source code. And this script could be updated to look for this red flag, and many other red flags could be found by a script similar to the “Screen Userscripts” script. Even use of TinyURL.com in a script’s source code could be considered characteristic of a script that cannot be trusted. Not all malicious scripts might successfully be determined to be malicious by script-screening scripts, as there may be those who will always try to get the code in their scripts around any filters. However, a sufficiently large community of users looking into this issue would minimize the number of scripts that could perform anything malicious.
It has also been suggested that updates be made to Greasemonkey itself. Some have suggested that Greasemonkey should disallow scripts from being able to access document.cookie in much the same way that the GM_xmlhttpRequest function only allows use of the HTTP, HTTPS, and FTP protocols. However, that would cause a number of non-malicious scripts to not work properly. This tradeoff between security and functionality is one that Greasemonkey has had and may always have. And as long as Greasemonkey has the ability to do everything that JavaScript can do and more, it could be considered a security risk. What appears to be Greasemonkey’s greatest selling point is also its most serious security issue.
In this series of entries, I have tried to summarize what should be known by users of Greasemonkey. However, I may not have covered everything that could have been (and perhaps should have been) covered. Some might say I have left out some important information, despite the fact that the information that I have written spans three rather long blog posts. In addition, there might be other issues with Greasemonkey security that are not yet known, as was the case with the recent security issues found by Anthony Lieuallen that were mentioned in the second part of this series. This is certainly not the last word on Greasemonkey and security. More information will be posted on this topic in the future. In fact, I have considered writing a summary of this summary that has taken up three blog posts. Greasemonkey has been referred to as a Firefox extension to avoid, as you can see if you read this article. However, as was said in that article, it is one to avoid only if you are not willing to do your homework. And anything that could make it easier for users to do that homework should be made available. Greasemonkey is meant for those who are knowledgeable about topics such as JavaScript and security. Therefore, I encourage those who want to use it to be sure to be knowledgeable about these topics. And if you know the risks and rewards that come with using Greasemonkey, you should be able to enjoy the rewards that come with using it, without having to take unnecessary risks.