If the website could override extension functions, attacks would already be possible by overriding Regex functions.
The untrusted script can override its own view of createElement, but not the extension's view.
I wonder if a DOM mutation event would be triggered if a content script adds a new link element and changes it's href.
Would I be able to catch that and quickly change the href, before the content script continues to fecth the processed properties?
It is true. See documentation => https://developer.chrome.com/extensions/content_scripts#exec... :
> Content scripts execute in a special environment called an isolated world. They have access to the DOM of the page they are injected into, but not to any JavaScript variables or functions created by the page. ... The same is true in reverse
[0] http://archive.oreilly.com/pub/a/network/2005/11/01/avoid-co...
For desktop browser extensions that are properly using the frameworks, the extension's Javascript runs in its own execution context so the page cannot redefine variables. This protected 1Password when we discovered that a certain page had redefined the global JSON object, which provides parse and stringify functions among other things, to be the number 3, i.e. a numeric constant called JSON. :'D
Context: I'm a new 1Password user who is contemplating use of the extensions for those latter two browsers, and while it seems probable their extension frameworks offer the level of security you describe, I'd like to be certain before pulling the trigger. Thanks!
Hi there!
Yes, all 3 of the major browsers (and derivatives of them) offer the same support for a sandboxed execution environment. You can safely use any of them if that's a requirement you have :)
Kyle
AgileBits
We really try not to call it "Classic" or anything like that. It's standalone, you're in charge of upgrades, syncing and backups and stuff like that. It's also not designed for sharing (at least to the degree of the Family and Team solutions).
That said, we don't have any immediate plans to remove the standalone products. However, if a vast majority of our users switch to 1Password Family or 1Password Teams (and as of today, an Individual plan!) then it doesn't make a ton of sense to keep the standalone product around. So, it's probably one of those speak with your wallet kind of scenarios.
I'll certainly pass your feedback along, it sounds like you'd like to keep it around.
I hope that helps answer your question :)
Kyle
AgileBits
Anyway, I gave up on both 1Password and LastPass. I've been a 1Password user for about 2 years before I switched to KeePass.
To be more specific, for the desktop (OS X, Linux, Windows) I use: https://keeweb.info/
For Android: https://play.google.com/store/apps/details?id=keepass2androi...
And for iOS, though be warned this one is subpar: http://minikeepass.github.io/
All 3 apps are open-source. This is important because open-source will not die for as long as there is demand and more importantly, you own it.
No, I'm NOT against proprietary software, as I said, I gladly paid a premium for 1Password. However their Windows client is basically unmaintained, their new "modern Windows" app is still alpha and doesn't work with Wine and of course, they have no Linux support. Most aggravating is that they are clearly switching to a subscription model, with all of their development effort going towards it lately. No more Everywhere interface for OpVault, no new sync options other than Dropbox and iCloud, etc. In other words I'm tired of bait and switch models and one is in progress here.
But the real important thing to consider is whether the protection you would get from a hosted solution so above and beyond overkill that it matters?
If you're curious why I feel that way, we have written up a white paper on how 1Password Teams (and therefore Families and now Individuals) stores and secures your data.
https://1password.com/files/1Password%20for%20Teams%20White%...
We designed 1Password so that we cannot know anything about your data. We also designed it knowing full well that our servers would be a target. So, we designed it in such a way that if a malicious person were to acquire your data there's more or less nothing they can do to acquire the decrypted data.
What we settled on is having two secrets. Both of which are not known by us. The first is your Master Password, something that you're likely well aware of having used 1Password already. The second part is an Account Key, which is a random 128-bit key generated locally. These two things are never given to us and should never be shared. They are both used for the cryptographic functions in 1Password. Without them both, you can't see the decrypted data.
This is unique in that it actually protects weak master passwords. That's the big deal to worry about if our database of user data is compromised. The first attack is to start running password cracking tools against it to try to find the weak passwords. Except in this case, there are no weak passwords because even if your master password is "a" the attacker still needs your Account Key, which looks something like this:
A3-Z4JZ6V-P9BALK-S6J69-FAXCN-LTDY8-T3QHJ
So, now a password cracker is going to have to guess all those combinations of weak passwords against something much much stronger as well. I wish them luck because the math more or less makes this impossible if a user uses a strong master password as well.
There's some math in the white paper if you're curious about more.
Knowing how it works and how extremely unlikely it is that I am such a target that someone is going to literally spend millions upon millions of dollars trying to crack my account (and still likely get nowhere)... I'm small fish, it just isn't worth it to even try.
Either way, for the sake of learning (I love learning, so I always assume others do as well), I would recommend reading the white paper, if not only to gain some new knowledge that you may not have been exposed to previously. If you have, awesome!
As always, if you have questions let me know!
Kyle
AgileBits
It is $2.99/mo when billed annual ($3.99/mo month to month), includes all of the applications as part of the subscription price.
It is otherwise based on the same technology as Family and Teams options. It's basically Families with only 1 user.
The same attack you describe could be applied to basically any javascript you cared to write (say, String.prototype.length). The safest approach is to treat the output of injected javascript as untrusted third-party input to your extension code and work from there.
Since malicious attackers have complete control over the page you're seeing - they can simply replace document.createElement with their own function. And instead of returning a DOM object, they can return an object that returns whatever they want in .hostname