That's an interesting idea. There might be some way to leverage the extended validation certificate system to do that easily.
Adam On Fri, Jan 1, 2010 at 2:22 PM, Erek Speed <melin...@gmail.com> wrote: > 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 <l.d.ander...@gmail.com> 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 <aba...@chromium.org> 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 <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%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%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%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. >> > > 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 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. > > > -- 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.
