On Sat, Jan 2, 2010 at 3:11 AM, Laurence <l.d.ander...@gmail.com> wrote:
> Yes, this really is a tough one. I guess the script could also change
> the action of a form etc
>
> If it is possible to classify data as "user data", ie something that
> has been entered by the user (inc form autofill), then a security
> capability be required to pass that back to the background page, or
> form URL's from it etc. I guess changing the action of a form would
> also need to be controlled. But how many other ways round this are
> there, is this feasible?
>
> Even if the above worked and stopped passwords being stolen, it could
> still perform actions as you once you've logged into a website, eg.
> send spam, transfer money etc. Maybe need to worry about one problem
> at a time though.
>
> Or could content scripts be disabled for certain websites, eg.
> internet banking. I was thinking this could be signalled by the site
> itself, however I guess all sites will start flagging it to stop
> advert blockers etc. Maybe a simpler and more effective approach?

That's an interesting idea.  I'm not quite sure how that would play
out.  We already block content scripts in the gallery to prevent
extensions from manipulating their own reputation.

> Is it worth recording this potential threat as a bug?

You can file a bug if you like, but it's not really actionable.  We're
certainly aware of the issue and on the lookout for ways to improve
the situation.

Thanks for your thoughtful comments.

Adam


> On Jan 2, 12:43 am, Aaron Boodman <a...@google.com> wrote:
>> On Fri, Jan 1, 2010 at 12:36 PM, Laurence <l.d.ander...@gmail.com> wrote:
>> > 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.
>>
>> There are many ways to pass data from a content script to a foreign
>> server besides XHR. For example, you can create an image tag and pass
>> the data in the src attribute querystring. You can create a link tag
>> and simulate a click on it. Etc.
>>
>> There have been thoughts down this path before, but nobody has ever
>> come up with a way to prevent data from going from web page to evil
>> servers that still allowed most valid use cases.
>>
>> Suggestions welcome, though.
>>
>> - a
>
> --
>
> 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.


Reply via email to