291–300 of 443 posts
It's easy to forget that sandboxed extensions don't exist yet in iOS (as of 9.3.3), and sometimes we still have to use bookmarklets.
As far as I know, bookmarklets aren't afforded any level of sandboxing type protection. I wonder if a malicious page could intervene like that.
Earlier quoted context omitted.
I did speak rather harshly in my prior comment, and for that I apologize. Worse, I did a very poor job of expressing the concern that motivated me to respond. But I think it's still fair to ask whether your initial comment has value. I understand that, as a user of 1Password's browser extension(s), you may well feel some concern that a similar vulnerability exists, and I don't think it's unreasonable to want reassura…
Fwiw, his question did not sound at all like that to me. Your reaction feels like unfair personal bias. Not trying to start a fight but you seem openminded enough to hear it so figured Id let you know
Earlier quoted context omitted.
I'm sorry, but I don't see how asking an employee of the company that makes the product that I use every day is "discouraging devs to participate by taking their presence as an opportunity for drive-by pot shots". I think an official word holds more clout and is more valuable than any one person confirming for themselves in one version of one browser on one version of one OS.
Also, just because we're on Hacker News, it doesn't mean every reader is equipped to audit code for security vulnerabilities. Presumably that's the job of a professional security developer that might reasonably be expected to have checked their own similar product for this vulnerability...
Earlier quoted context omitted.
"On the other hand, using regexp to parse the URL when it's such an obviously security critical code path... just, why?!" Why not? URIs are at least able to be tokenized perfectly well by a regular expression. You have to do it right, but there's little guarantee that your non-regexp code will do it right either. I glanced at that regexp and immediately recognized several potential problems with it... will I be able…
Heh. https://mathiasbynens.be/demo/url-regex https://lostechies.com/chadmyers/2010/11/20/parsing-a-url-wi... https://stackoverflow.com/questions/27745/getting-parts-of-a... What do all these have in common? They all demonstrate that it is hard to write a regex that parses URLs. Regex's hide programming mistakes because they not only become harder for humans to parse as they get more complicated, but also there isn't…
fixedURL && (url = url.substring(0, fixedURL[1].length) + url.substring(fixedURL[1].length).replace(/@/g, "%40")); "http://avlidienbrunn.se/@twitter.com/%40hehe.php"
But I don't see how this leads to "the actual domain is treated as the username portion of the URL."?
Earlier quoted context omitted.
Likely in the sense that the attacker cannot login into your account using the stolen credentials, as the second factor would not be in their possession.
The article links to lastpass multifactor [0] though. I agree that having multifactor enabled on the site the credentials were stolen for would block this attack. [0] https://helpdesk.lastpass.com/multifactor-authentication-opt...
Is someone going to lose their job over this?
Earlier quoted context omitted.
Disclosure: I work for AgileBits, makers of 1Password. If you're interested, all our data formats are well documented for review: https://blog.agilebits.com/2013/03/06/you-have-secrets-we-do... You might also be interested in the security white paper for our hosted 1Password service: https://1password.com/security/ (White paper is linked at the bottom of the page.)
Long time 1Password user here. I use it on bunch of Machines and I wish you guys supported Linux. :( Heck 1Password mostly works under Wine, except perhaps there is no unlock on Secure desktop and bunch of other usability things.
Yea, we hear you there. I (and others on the team) wish we could make this happen, but priorities are a tough one. Linux in general didn't fit all that great in our standalone license model before, along with being closed source. Now with the subscription option for individuals (new today), families and teams we have made the payment side a little less of a concern but we still have the closed source nature of things making Linux a harder target to hit.
We're probably in a better position now than before though. Every time I asked a Linux user who wasn't asking for this they said they had no interest in paying for closed source software. I wanted all the positive response I could get to show to the decision makers but I fell short in getting it.
This is all to say it's simply a complicated situation. It has to either make money to pay for its development, or the others have to offset it enough that it's a win for us so we can keep the lights on.
Hope that helps a little anyway. I know it's not the answer you wanted but I hate leaving people like yourself wondering why it feels like we aren't listening.
Kyle
AgileBits
Earlier quoted context omitted.
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).
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.
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?