7 ms·

While that might be an "easy way" - it isn't a secure way in this case. Since malicious attackers have complete control over the page you're seeing - they can

by dkopi 10y ago

While that might be an "easy way" - it isn't a secure way in this case. 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

Navarr 10y ago
At least in Chrome, I'm imagining the raw url would be sent to a background process that is sandboxed from the webpage and would then do the createElement stuff.
JackC 10y ago
I think the point is that this would run in a document belonging to the LastPass extension -- not that it would run in javascript injected into the target site. 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.
jxpx777 10y ago
Disclosure: I work for AgileBits, makers of 1Password. 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
- favadi 10y ago
  When you are here, is 1password for team is the future and the classic 1password will become obsolete soon?
  - AGKyle 10y ago
    Disclaimer: I also work for 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
    - gergles 10y ago
      I also very very very strongly do not want any hosted service requirement for using 1password. I am very proud user of 1P but a hosted requirement would kill it for me. No matter how much you (the generic 'you') tell me you're super secure, nothing will be as secure as owning my own data and using local Wi-Fi sync to put it on my phone.
      - AGKyle 10y ago
        While I understand your concern, and to some extent, sure, you're right that owning your own data does reduce certain attack vectors it's also a trade off that a vast majority of people don't have to worry about either. 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%20Paper.pdf 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
- dkopi 10y ago
  Great point. Exactly the type of comments I come to hacker-news for!
- throwanem 10y ago
  Out of curiosity, does this apply only to Chrome's extension framework, or to Firefox's and Safari's as well? 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!
  - AGKyle 10y ago
    Disclaimer: I work for AgileBits as well :) 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
    - throwanem 10y ago
      Neat, thanks!
asjfkdlf 10y ago
No, that is not possible. Extensions in Chrome run in a different execution context than the website. The website's document.creatElement is different from the extension's. If the website could override extension functions, attacks would already be possible by overriding Regex functions.
- dkopi 10y ago
  Good point, but that's assuming you're running in the context of the popup and not in the context of a content script. In the popup's script, you are using a new DOM. But in a content script - you're using the same DOM as the client, which can override createElement (and any other function as well).
  - ghurtado 10y ago
    My understanding is that the content script can access the webpage DOM, but not the other way around (it's a "one way street", if you will)
  - mook 10y ago
    While content scripts (in the extension world, meaning scripts running in the context of a content page) shares the DOM with the untrusted page, it does not share the JavaScript wrapper layer around that DOM. This is extra confusing because the global object is a (JavaScript wrapper around a) DOM object. The untrusted script can override its own view of createElement, but not the extension's view.
    - dkopi 10y ago
      Very interesting if true. I'm tempted to build an extension just to check that. 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?
      - AgentME 10y ago

by dkopi 10y ago

Navarr 10y ago

At least in Chrome, I'm imagining the raw url would be sent to a background process that is sandboxed from the webpage and would then do the createElement stuff.

JackC 10y ago

I think the point is that this would run in a document belonging to the LastPass extension -- not that it would run in javascript injected into the target site. 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.

jxpx777 10y ago

Disclosure: I work for AgileBits, makers of 1Password. 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

favadi 10y ago
When you are here, is 1password for team is the future and the classic 1password will become obsolete soon?
- AGKyle 10y ago
  Disclaimer: I also work for 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
  - gergles 10y ago
    I also very very very strongly do not want any hosted service requirement for using 1password. I am very proud user of 1P but a hosted requirement would kill it for me. No matter how much you (the generic 'you') tell me you're super secure, nothing will be as secure as owning my own data and using local Wi-Fi sync to put it on my phone.
    - AGKyle 10y ago
      While I understand your concern, and to some extent, sure, you're right that owning your own data does reduce certain attack vectors it's also a trade off that a vast majority of people don't have to worry about either. 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%20Paper.pdf 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
dkopi 10y ago
Great point. Exactly the type of comments I come to hacker-news for!
throwanem 10y ago
Out of curiosity, does this apply only to Chrome's extension framework, or to Firefox's and Safari's as well? 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!
- AGKyle 10y ago
  Disclaimer: I work for AgileBits as well :) 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
  - throwanem 10y ago
    Neat, thanks!

asjfkdlf 10y ago

No, that is not possible. Extensions in Chrome run in a different execution context than the website. The website's document.creatElement is different from the extension's. If the website could override extension functions, attacks would already be possible by overriding Regex functions.

dkopi 10y ago
Good point, but that's assuming you're running in the context of the popup and not in the context of a content script. In the popup's script, you are using a new DOM. But in a content script - you're using the same DOM as the client, which can override createElement (and any other function as well).
- ghurtado 10y ago
  My understanding is that the content script can access the webpage DOM, but not the other way around (it's a "one way street", if you will)
- mook 10y ago
  While content scripts (in the extension world, meaning scripts running in the context of a content page) shares the DOM with the untrusted page, it does not share the JavaScript wrapper layer around that DOM. This is extra confusing because the global object is a (JavaScript wrapper around a) DOM object. The untrusted script can override its own view of createElement, but not the extension's view.
  - dkopi 10y ago
    Very interesting if true. I'm tempted to build an extension just to check that. 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?
    - AgentME 10y ago