How do you guys think about extensions having some sort of "Whitelist" for XHR requests. If an extension needs to access helloworld.com, it will popup an info bar stating this extension needs to have access to this website, that way the user will know what is going on. They could add it to their whitelist so that info bar will never show again.
If people allow URL which is not safe, then it there is nothing we can do to solve the security problem, http://technet.microsoft.com/en-us/library/cc722487.aspx see law #1. I am no security person, maybe Adam can comment. -Mohamed Mansour On Fri, Jan 1, 2010 at 9:48 AM, Laurence <l.d.ander...@gmail.com> wrote: > Agreed, it'll be hard to detect if an extension is maliciously using > passwords. However if passing of passwords can be detected between the > content script and the background page/XHR for example, it can have a > security capability associated with it, which hopefully people would > only grant to a password saver. Well that's my theory... > > Laurence > > On Jan 1, 2:10 pm, PhistucK <phist...@gmail.com> wrote: > > But, think of the counter case, how can you detect that an extension is > > maliciously using your passwords as malicious, and an extension that is > > rightfully using your passwords (a password saver) as not malicious? > > > > Both of them can act the same way, so, what, will you block both of them > due > > to the security risks? > > > > ☆PhistucK > > > > > > > > On Fri, Jan 1, 2010 at 16:04, Laurence <l.d.ander...@gmail.com> wrote: > > > Could there be some more fine grained security around forms, > > > especially password fields? (Including document.onkeypress when a > > > password field has focus, and possibly other vectors - am I being too > > > simplistic here - does the content script merge and become > > > indistinguishable from the web page itself?). It should be very rare > > > for extensions to need these (only password managers, which you > > > implicitly trust with everything anyway), and if people give an > > > extension access to their passwords, then they do it with their eyes > > > open. > > > > > Is fine grained security around eval/innerHTML from XHR possible? I > > > assume that would be difficult too, would need to 'taint' every > > > variable derived from an XHR. > > > > > What do you think? Or other ideas? > > > > > Laurence > > > > > On Dec 31 2009, 10:14 pm, Mohamed Mansour <m...@chromium.org> wrote: > > > > Maybe having some kind of statistical usage of xhr calls that each > > > extension > > > > will keep track permanently. That way, we could do some sort of smart > > > > algorithm that will point out some uncommon, untrustworthy requests. > I am > > > > just dreaming, but I think its possible to eliminate some threat. > > > > > > Cause currently, if some developer's extension's account got hijacked > or > > > > stolen, the user could modify his extension and add some privacy > > > concerning > > > > risks. To (try to) stop that, we could do what we did before, and let > the > > > > developer supply the certification file (pem) everytime he updates > his > > > > extension, that will eliminate that kind of threat, when the account > has > > > > been compromised. > > > > > > PS: I am not a security person, just some ideas that came out of my > head. > > > So > > > > I might be just dreaming. Nevertheless, its an interesting topic. > > > > > > -Mohamed Mansour > > > > > > On Thu, Dec 31, 2009 at 3:44 PM, Adam Barth <aba...@chromium.org> > wrote: > > > > > Yes, that's a scary scenario and a real threat. If you have ideas > for > > > > > what we could do to protect against that threat, I'd be interested > in > > > > > discussing them. > > > > > > > Keep in mind that a nefarious extension doesn't need the > auto-update > > > > > system at all to change its behavior over time. For example, the > > > > > extension can load code from it's own web site into the extension > > > > > process (e.g., via eval or innerHTML). > > > > > > > Adam > > > > > > > On Sun, Dec 27, 2009 at 4:16 AM, Laurence <l.d.ander...@gmail.com> > > > wrote: > > > > > > Hi, > > > > > > > > I've been playing about with the extension framework - really is > a > > > joy > > > > > > to use. > > > > > > > > However I have a slight concern about the threat model. It's > fairly > > > > > > trivial to write an extension to log all form data (from both > http > > > and > > > > > > https sites) and send it off to a foreign host, given content > script > > > > > > and Cross-Origin XHR permissions. The threat model assumes that > such > > > > > > an extension will get bad reviews, so not affect many users, but > does > > > > > > it factor in the autoupdate mechanism? > > > > > > > > As a nefarious developer, I could create a perfectly innocent and > > > > > > useful extension (with content script and Cross-Origin XHR > > > > > > permissions), and wait until a large number of users have > installed > > > > > > it. Then I release a new version, automatically pushed out to > > > existing > > > > > > users, that introduces form logging. Whilst it may only take a > day or > > > > > > so for someone to notice and the extension killed, large numbers > of > > > > > > users will have their details (usernames, passwords, credit card > > > > > > numbers) stolen. > > > > > > > > Any thoughts? > > > > > > > > Laurence > > > > > > > > -- > > > > > > > > You received this message because you are subscribed to the > Google > > > Groups > > > > > "Chromium-extensions" group. > > > > > > To post to this group, send email to > > > > > chromium-extensi...@googlegroups.com. > > > > > > To unsubscribe from this group, send email to > > > > > chromium-extensions+unsubscr...@googlegroups.com<chromium-extensions%2bunsubscr...@googlegroups.com><chromium-extensions%2Bunsu > bscr...@googlegroups.com><chromium-extensions%2Bunsu > > > bscr...@googlegroups.com> > > > > > . > > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/chromium-extensions?hl=en. > > > > > > > -- > > > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > "Chromium-extensions" group. > > > > > To post to this group, send email to > > > chromium-extensi...@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > > chromium-extensions+unsubscr...@googlegroups.com<chromium-extensions%2bunsubscr...@googlegroups.com><chromium-extensions%2Bunsu > bscr...@googlegroups.com><chromium-extensions%2Bunsu > > > bscr...@googlegroups.com> > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/chromium-extensions?hl=en. > > > > > -- > > > > > You received this message because you are subscribed to the Google > Groups > > > "Chromium-extensions" group. > > > To post to this group, send email to > chromium-extensi...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > chromium-extensions+unsubscr...@googlegroups.com<chromium-extensions%2bunsubscr...@googlegroups.com><chromium-extensions%2Bunsu > bscr...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/chromium-extensions?hl=en. > > -- > > You received this message because you are subscribed to the Google Groups > "Chromium-extensions" group. > To post to this group, send email to chromium-extensi...@googlegroups.com. > To unsubscribe from this group, send email to > chromium-extensions+unsubscr...@googlegroups.com<chromium-extensions%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/chromium-extensions?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to chromium-extensi...@googlegroups.com. To unsubscribe from this group, send email to chromium-extensions+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en.
