One policy is to have a higher level of verification for extension authors. Some method where they're name and address are verified which at least insures that they'll be identified if they do anything evil.
On Jan 2, 5:36 am, Laurence <[email protected]> wrote: > Completely agree on 3, for too long everyone is expected to be an IT > expert, and it's their fault if their not. > > As I see it, there is a problem that an innocent looking extension can > turn into a malicious extension via autoupdate, or eval/innerHTML, > potentially compromising many users. An obvious thing for the > malicious extension to do is to log all form data, and post it to a > hostile site using XHR. I don't have any good ideas for preventing > this directly... > > One idea is to use fine grained security to prevent the malicious > behaviour. My first though was to require an extra capability to allow > passwords to go from content script to XHR, however as pointed out > above this is not as simple as it seems. My second though: an > additional capability is required to pass any data from a content > script to XHR. I'm not sure how many extensions would require this > capability, password managers would, but hopefully it would be few, > and come with a suitably strongly worded warning. > > I'm sure there are many issues to work through, but lets discuss! > > On Jan 1, 7:44 pm, Adam Barth <[email protected]> wrote: > > > > > Some high-level points: > > > 1) In thinking about security, I find it helpful to separate policy > > from mechanism. A bunch of messages in this thread are about various > > mechanisms (taint tracking, DOM reference monitors, etc), but we don't > > have a clear idea what policy we'd like these mechanisms to enforce. > > > 2) Several messages are interested in protecting passwords (e.g., > > noticing if an extension mis-uses passwords in various ways). Before > > we think about what sorts of policies we ought to apply to passwords, > > we should think about how we're going to recognize what's a password > > and what's not a password. Just using <input type="password"> isn't > > sufficient if the extension can draw things on the web page (which is > > a more or less a requirement for the extension system) because the > > extension can draw a box that looks exactly like a password field. > > > 3) Some folks are tempted to punt security questions to the user > > (e.g., extension XYZ wants to communicate with host ABC, allow/deny?). > > Although it might make us feel better to be able to blame the user > > when something goes wrong, many users won't have enough context to > > make reasonable security decisions when faced with these kinds of > > questions (e.g., should the Happy Fun Ball extension be allowed to > > communicate with happyfunball.com?). > > > Adam > > > On Fri, Jan 1, 2010 at 6:48 AM, Laurence <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > >> > > 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 <[email protected]> > > >> > 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 > > >> > > > [email protected]. > > >> > > > > To unsubscribe from this group, send email to > > >> > > > [email protected]<chromium-extensions%2Bunsu > > >> > > > [email protected]><chromium-extensions%2Bunsu > > >> > [email protected]> > > >> > > > . > > >> > > > > 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 > > >> > [email protected]. > > >> > > > To unsubscribe from this group, send email to > > >> > > > [email protected]<chromium-extensions%2Bunsu > > >> > > > [email protected]><chromium-extensions%2Bunsu > > >> > [email protected]> > > >> > > > . > > >> > > > 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 > > >> > [email protected]. > > >> > To unsubscribe from this group, send email to > > >> > [email protected]<chromium-extensions%2Bunsu > > >> > [email protected]> > > >> > . > > >> > 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 [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group > > > athttp://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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en.
