I am currently developing a browser extension/plugin that one would install and would then report information such as page load times, number of objects on each page, etc. to a server so that the data could be analyzed.
I was curious if something like Yahoo's Boomerang JavaScript code (http://hacks.bluesmoon.info/boomerang/doc/) would be able to be able to do this. From what I have read, it seems like Boomerang was developed for developers to implement into their own website in order to gather data, but would I be able to gather the same kind of data by putting this code in a browser extension in order to gather the data from each website that is visited?
The link you're using for boomerang is very outdated (it was my first experimental page). Use http://lognormal.github.com/boomerang/doc/
Boomerang does already use these APIs, and much more, but as a browser extension, you could do much more in terms of removing code that supports other browsers, and also maintaining offline storage more efficiently than boomerang's cookies.
FWIW, yslow already does most of what you want, so maybe just use that (it was built by the same team)
I don't see why not from a technical perspective, at least in Firefox and Chrome. However, user privacy issues and policies of the browser extension stores might prevent you from tracking users in certain ways and/or without consent. So better check that first to avoid surprises later.
You'd need a way to gather information. Judging from your question text, the regular DOM APIs and the PerformanceTiming API might be sufficient. And that's probably what Boomerang uses already.
You'd just attach your code (or Boomerang) with e.g. Firefox Add-on SDK PageMod or Chrome extension Content Scripts.
You'll also need to transmit the data somewhere. Both Firefox (XUL1, Add-on SDK) and Chrome extensions allow cross-origin XHR.
So there you are. ;)
1 XUL overlay scripts are privileged, and not restricted by the same-origin policy.
Related
I am fairly interested in my website visitor's Chrome extensions, and what they do
( outgoing network communication, file saving, storage, etc. )
Is there any possibility to detect these?
No.
That would be a nasty invasion of privacy.
The closest you could come to detecting an extension would be to examine the DOM and JS environment of your page and see if the browser modified it in ways you didn't expect … but that would be a massively broad problem to solve, so you could only practically do it to look for very specific effects (which is what ad-blocker-blockers do).
For some specific extensions only, you can detect them by trying to load resources from them. This will be testing for specific extensions, and not discovering a list.
This requires you to know the extension ID, path to resource, and the resource has to be in web_accessible_resources. As the name suggests, that makes some files accessible from the web context, so you can try to load them. A network error would signify it's not installed (or no longer has that resource in web-accessible).
Again, that requires you to know the extension you're going to test for in advance, and extensions without web-accessible resources are invisible to this technique.
Notes:
Google Cast library uses this technique to probe if its own extension is installed.
If it's not, it generates a nasty error in the JS console for the failed network transfer, an error that you cannot silence from JS code — which was enough of an annoying problem that Chrome eventually added a blacklist for those console messages just so it isn't an eyesore.
From that, you can deduce it's probably not a good idea to test for a long list of extensions. It will pollute your console with errors. For cooperating extensions on pre-defined domains, there's a better way to test that it's installed. But that's not your case.
I'm trying to detect the presense of certain addons that restrict functionality on our sites (such as Ghostery, or DoNotTrackMe), using plain JavaScript. If Firefox had a standard API to query for the existence of addons, it would short circuit my work. Probably something like:
AddonManager.getAddonByID('?')
Detection is possible for plugins such as Java and Flash (navigator.plugins), but not for addons, yet.
Detection is also possible if you are the developer of the addon.
No, there is no such API and there won't be. If the browser allows websites to detect what extensions are installed then it is a bug and a privacy issue - Firefox and Chrome fixed such issues in the past, currently no such issues are supposed to exist. Why webpages shouldn't know this:
The add-on list allows fairly precise fingerprinting of users and might allow tracking users even if cookies and similar mechanisms are disabled.
Attacking vulnerabilities in extensions gets a lot simpler if a website can check in advance whether a vulnerable extension/extension version is installed. Same goes for social engineering attacks that rely on the presence of particular extensions.
There is always a chance that websites decide to exclude website visitors that have unpopular software installed (ad blockers of all kinds, vulnerability scanners, download helpers etc).
The list of installed extensions tells a lot about the user, his browsing habits and preferences - providing this information to websites would be a huge privacy issue.
navigator.plugins functionality shares many of the same issues of course - it was introduced in the dark ages of the internet back when nobody considered such issues. This is the reason why this functionality is being actively discussed and might get limited in future.
Now of course websites can still try to detect extensions by their effects. However, this isn't a very reliable approach, e.g. the Adblock detector you linked to says "no ad blocking detected" to me and is clearly wrong.
Bonus info: Google Chrome does provide a list of installed extensions but only to a single website: Chrome Web Store. The Web Store uses it to indicate which extensions you already installed. Whether it does anything beyond it with that data is something where your guess is as good as mine.
You can detect AdBlock in FF, IE, Chrome
http://adblockdetector.com/
You can detect FlashBlock in FF, IE, Chrome and others
https://gist.github.com/artlung/1420308
https://github.com/browserstack/flashblock-detector/blob/master/flashblock-detector.js
You can detect Ghostery in Chrome
http://blog.securitee.org/?p=277
Please note these scripts use inference to detect the presense of these addons, there's no API. I haven't found detectors for other addons but they possibly exist.... (ongoing)
I know this subject has been largely discussed and there is no way to get the parent frame modify the children frame due to security reason.
BUT
I'm developing a ad-hoc solution for some clients, we can configure their browser and eventually install plugin ( which will be the "fail" solution).
We would like to configure the browser (chrome or whatever ) to NOT protect the browser from this.
My aim is to inject a JavaScript into their website without having any access to their website.
I actually use a php proxy which works... pretty bad ( how to keep the links when they are loaded dynamically via JavaScript? ) and I would not like to develop a Firefox plugin because it s a bit heavier and longer to set up I guess.
Any idea?
Your question is not that clear. But if you want to load a different domain from the parent in an iframe, there is no way to access it, UNLESS your customer uses an open-source browser and are happy for you to install on their systems a hacked version of the browser that will allow this.
But I can assure you this is not going to happen for a variety of reasons.
tl;dr: you can't.
You can communicate between 2 frames from 2 different domains using window.postMessage for the recent browsers.
If you have to support IE6/IE7 or older browsers, you can use the window.name hack.
Both techniques allow you to pass string data between frames.
You need then to have some javascript on both sides that listen to the event and make the action. You don't need to change anything to the browser configuration.
EDIT:
After your comment, here is another option: a bookmarklet. You define a page like this on your site, changing the path to the js file:
<html>
<body>
Drag'n Drop this to your bookmarks
</body>
</html>
And you ask your users to click the bookmark when they want your code to run.
This will inject the code in the client page, and you are free to do what you want.
Obviously this has a security concern. Your script has full access(content, cookies) in their page. But since you are almost ready to recompile a web browsers for that :) I guess it will work for them.
Let's say I wanted to create a browser plug-in that would open someone's floppy drive for them whenever they click a button on my web page. (You remember that old gag? - Don't worry, I don't really want to do that.)
What are the steps necessary to create a browser plug-in that will work on most browsers and most operating systems?
How do I deploy the plug-in? For instance, how do I make it so that the plug-in can be easily downloaded and installed? Do I have to worry about digital certificates?
How do I check for and use the pluggin once it's installed? Is it available to javascript in the form of an API?
Take a look at a project called FireBreath: http://www.firebreath.org/display/documentation/FireBreath+Home
Firebreath abstracts many of the differences between the browser plugin frameworks and platform issues so you can easily write the code for a plugin once and just re-compile it for different platforms.
I have found it good for exposing existing C/C++ library API's to Javascript so I can write dynamic pages that use functionality from the C++ library which were otherwsie not available.
Most modern browsers have their own plugin frameworks for developers to utilize. So, for example, a Firefox plugin will not work in chrome or IE. Firefox and chrome do both utilize javascript and css but they are fundamentally different in their structure.
As far as deployment, Mozilla and Google provide hosting for their respective plugins. I do know that firefox extensions are basically zip files with the extension changed.
EDIT...
I had assumed you meant browser extensions so disregard my answer if that is not the case.
The easiest cross-browser solution is use Java Applets or maybe Flash (I am not sure how you do it in Flash).
With applets, you would need to sign the applet and also create a security policy file for accessing the disk. When the applet loads in the browser it would ask permission from the client user, he/she needs to click Allow to give permission for the applet to access the disk. This would allow you to access any disk in the system.
I've never actually used greasemonkey, but I was considering using it.
Considering that GreaseMonkey allows you to let random people on the Internet change the behavior of your favorite websites, how safe can it be?
Can they steal my passwords? Look at my private data? Do things I didn't want to do?
How safe is Greasemonkey?
Thanks
Considering that GreaseMonkey allows you to let random people on the Internet change the behavior of your favorite websites, how safe can it be?
It's as safe as you allow it to be - but you aren't very clear, so let's look at it from a few perspectives:
Web Developer
Greasemonkey can't do anything to your website that a person with telnet can't already do to your website. It automates things a bit, but other than that if greasemonkey is a security hole, then your website design is flawed - not greasemonkey.
Internet user with Greasemonkey loaded
Like anything else you load on your system, greasemonkey can be used against you. Don't load scripts onto your system unless you trust the source (in both meanings of the term 'source'). It's fairly limited and sandboxed, but that doesn't mean it's safe, merely that it's harder for someone to do something nefarious.
Internet user without Greasemonkey
If you do not load greasemonkey or any of its scripts, it cannot affect you in any way. Greasemonkey does not alter the websites you visit unless you've loaded it on your system.
Greasemonkey developer
There's not much you can do beyond what can already be done with XUL and javascript, but it is possible to trash your mozilla and/or firefox profile, and possibly other parts of your system. Unlikely, difficult to do on purpose or maliciously, but it's not a bulletproof utility. Develop responsibly.
-Adam
Considering that GreaseMonkey allows you to let random people on the Internet change the behavior of your favorite websites
Random people whose UserScript you have installed. No one can force you to install a UserScript.
Can they steal my passwords?
Yes, a UserScript could modify a login page so it sent your password to an attacker.
No, it cannot look at your current passwords, or for websites the UserScript isn't enabled for
Look at my private data?
Yes, if your private data is viewable on a website that you've given a UserScript access too
Do things I didn't want to do?
Yes, a UserScript could do things to a webpage (you've given it access to) that are unwanted
How safe is GreaseMonkey?
As safe as the individual UserScripts you have installed
When used with discretion, Greasemonkey should be perfectly safe to install and use. While it is definitely possible to do all manners of mischief with carte-blanche Javascript access to pages, Greasemonkey scripts are restricted to specific URLs, and will not run on sites that are not specified by the URL patterns in their headers.
That being said, a basic rule of thumb is to consider most information on pages with Greasemonkey scripts active to be accessible to those scripts. It is technically feasible to play games like replacing input boxes (in which you might enter passwords or personal info), read any data on the pages, and send data collected to a third party. Greasemonkey scripts do run in an effective sandbox within the browser, and shouldn't be able to affect your computer outside of Firefox.
That being said, in some respects, the risk is comparable to or less than that of installing any other small pieces of open source software. Since Greasemonkey scripts are simple open source Javascript files, it's relatively easy for a programmer to take a look inside and make sure it does what it says it does. As always, run strangers' code (of any form) with care, and take the time to skim the source code if the software is important to you.
In general though, Greasemonkey scripts should be pretty safe. Try to use scripts with a large number of reviews and users, since these are likely to be more thoroughly vetted and analyzed by the community.
Happy userscripting!
Yes, userscripts can steal your passwords. That's the bottom line. Don't use firefox addons or userscripts on work or government computers without referring to your bosses.
Unlike firefox addons userscripts are not formally vetted. (Firefox 'experimental' addons are also not vetted). You can register and add a malicious script to userscripts.org in a moment.
Userscripts are very unsafe. The cross-site scripting ability means that it's no difficulty at all to send off your details/passwords to an evil server quite invisibly. And the script can do it for any site. Ignore the other answers that attempt to dismiss/minimise this issue. There are two issues: evil script writers putting their evil wares on to userscripts.org and scripts that break greasemonkeys' sandbox and so are vulnerable to being used by malicious code on a hacked site that would otherwise be restricted to same-domain.
In the case of evil script authors you can examine the scripts for code that sends your details; not much fun. At the very least you could restrict the script to particular sites by editing the 'include/exclude' clause. That doesn't solve the problem but at least it won't be sending off your banking credentials (unless you've used the same login details). It's a pity there isn't an 'includexss' clause to restrict xss requests, which would effectively solve the problem since, crucially, it would be easy to check even for non-developers. (the Firefox addon "RequestPolicy" doesn't block userscripts.)
Unsafe scripts: look for any use of 'unsafewindow'. There are other risky calls. Greasemonkey doesn't warn you of their use when the script is installed. Use of these calls doesn't mean the script is unsafe, just that the script writer had better be good at secure programming; it's difficult and most aren't. I avoid writing scripts that would need these calls. There are popular, high-download scripts that use these calls.
Firefox plugins/addons at Mozilla.org have similar problems to userscripts but at least they are formally vetted. The vetting/review includes the all-important code-review. Nevertheless there are clever techniques for avoiding the detection of evil code without the need of obfuscation. Also the addon may be hosted on an (unknown to anyone) hacked site. Unfortunately mozilla also lists 'experimental' addons which are not vetted and have had malicious code. You get a warning but how many know the real significance. I didn't until I picked up security knowledge. I never install such addons.
Userscripts are not formally vetted. Unless a script has a lot of installs I examine the code. Even so a high-install script could still have had the script-writer's account hijacked and script modified. Even if I examine a script the use of anti-detection programming means I may not see the evil. Perhaps the best bet is to examine outgoing requests with "Tamper Data" firefox addon, but a clever script will delay or infrequently send data. It's a tactical war, unfortunately. Ironically only microsoft's certificate based activeX objects really approach a real solution in developer traceability (but didn't go far enough).
It's true that a firefox addon gives an evil-doer greater exposure to potential victims, since firefox addons are generally more popular and so seem more likely to be targeted, but the firefox vetting process makes userscripts more attractive to the evil-doer since they are not vetted. Arguably a low-download userscript can still get a criminal plenty of valuable logins until it is spotted, while also giving the benefit of the relative obscurity and low community churn of userscripts, as well as a low chance of anyone code-reviewing it. You can't depend on firefox addons' popularity to protect you from evil userscripts.
As a non-developer you are dependent on other users spotting evil scripts/addons. How likely is that? Who knows. The truth is it's a crap security model.
Ultimately I use firefox for general browsing and Google Chrome (without greasemonkey/plugins) for admin purposes. Chrome also has a usable 'profiles' feature (totally separate browsing spaces) which is effectively like using different browsers. I've set up three chrome profiles to make myself even more safe: email/general-admin, banking, ebay/paypal. Firefox has unusable profiles (in my experience) but I prefer firefox as a browser which is why I still use it for uncritical browsing. Profiles also protect against old fashioned browser security holes and hacked sites, at least limiting their scope. But make sure you use different passwords. Another approach is a clean bootable ubuntu install on a USB stick for critical admin (see here http://www.geekconnection.org/remastersys/).
Jetpacks' special trust model, rather like the PGP trust network, which underlines the seriousness of this issue, should hopefully mitigate it. Jetpack is firefox's new kid on the block: a kind of super greasemonkey.