8 ms·

Seems like there should be some additional protection in the extensions API, if there is not already. "Read and change all your data on the websites that you vi

Seems like there should be some additional protection in the extensions API, if there is not already. "Read and change all your data on the websites that you visit" vs. "And send it somewhere over the web" are two separate layers of permission. Footnote: I can't visit the page. Blocked by corporate.

tyingq 9y ago
Since extensions can inject arbitrary js, there isn't really a way to be that granular. You could, for example, exfiltrate data by injecting an image tag with some extra url parameters on the url. Doesn't have to be xhr or websockets.
- debaserab2 9y ago
  I don't see why that couldn't be sandboxed. "Send and receive data from anywhere on the internet" Image doesn't load if you don't accept. Same goes for any tag or function that accesses external URI's.
  - tyingq 9y ago
    Perhaps. I don't know browser internals well enough to know if they could backtrack all the various possible indirections. Hijacking already existing code, like Google analytics code on the page, for example (change the ga id).
  - AgentME 9y ago
    If the extension has permission to manipulate webpages, then the extension could inject code (or an image element, etc) into any open webpage to make the webpage do the request for it.
    - debaserab2 9y ago
      That wouldn't affect it any differently than non-injected code. No external URI loading would occur from code sourced from an extension.
      - AgentME 9y ago
        What happens if an extension injects a script tag into the page with code to wait a second and then add an image element into the page? The code would be running outside of the extension's isolated world as normal code within the page. (There's many ways like this to trigger code to be evaled through the DOM API, and a lot of extensions depend on the ability to do this so they can interact with the page's javascript values.) The system could be made to remember that code spawned from an element inserted by the extension is still associated with the extension and its permissions, but then there's a lot of possible interactions that can get hairy from there. If we assume that any code parsed from eval (and equivalent functions) inherits the association of the code eval was called from, then if the webpage defines a function like this: function runAfterOneSecond(fn) { setTimeout(fn, 1000); } Then the extension can inject a script tag that calls runAfterOneSecond but passes it a string (which setTimeout evals internally) that contains code to inject an image. If that eval'd code is supposed to retain the association with the extension, then that would have to be tracked through the string. Do all strings now require an association field? What if the page code creates a new string based on that string? Does that new string get the association too? What if two strings associated with different extensions are combined? Do the associations get combined so that any code created from the string (or created from anything created from that string transitively) has the union of all of their security limitations? If instead of tracking the associations of values, you tracked whether the extension was on the call stack at the time of code being parsed, then you're out of luck there too. Imagine a page with the code `eval(getCode())`: if the extension overrode the getCode() function, then it could get the page to eval whatever it wanted. Certain popular web frameworks often eval code from the DOM (think inline templates), so it would be easy to write a more generic attack to have the extension stick some code into the DOM formatted in the specific way that the web framework recognizes so that it will eval and run it later. And even if you did manage to successfully restrict extensions from network requests, you'd end up with an extension that can't ever add elements to the page or manipulate elements that reference any external content. You couldn't make an extension for previewing an image on link hover. You could only add a button with an icon on it if that icon was an inline data uri. You probably couldn't reuse classnames from the page's css that referenced a remote background image or font. I would expect that nearly all page-interacting extensions would request the network permission just so they could get anything done. Chrome probably wouldn't spell out that permission in the permissions dialog (instead grouping it into the "Extension can read and change your data on all sites you visit" line) because of how common it was. ... And then they probably wouldn't go through the huge amount of effort and redesigns to support that permission in the first place.

tyingq 9y ago

Since extensions can inject arbitrary js, there isn't really a way to be that granular. You could, for example, exfiltrate data by injecting an image tag with some extra url parameters on the url. Doesn't have to be xhr or websockets.

debaserab2 9y ago
I don't see why that couldn't be sandboxed. "Send and receive data from anywhere on the internet" Image doesn't load if you don't accept. Same goes for any tag or function that accesses external URI's.
- tyingq 9y ago
  Perhaps. I don't know browser internals well enough to know if they could backtrack all the various possible indirections. Hijacking already existing code, like Google analytics code on the page, for example (change the ga id).
- AgentME 9y ago
  If the extension has permission to manipulate webpages, then the extension could inject code (or an image element, etc) into any open webpage to make the webpage do the request for it.
  - debaserab2 9y ago
    That wouldn't affect it any differently than non-injected code. No external URI loading would occur from code sourced from an extension.
    - AgentME 9y ago
      What happens if an extension injects a script tag into the page with code to wait a second and then add an image element into the page? The code would be running outside of the extension's isolated world as normal code within the page. (There's many ways like this to trigger code to be evaled through the DOM API, and a lot of extensions depend on the ability to do this so they can interact with the page's javascript values.) The system could be made to remember that code spawned from an element inserted by the extension is still associated with the extension and its permissions, but then there's a lot of possible interactions that can get hairy from there. If we assume that any code parsed from eval (and equivalent functions) inherits the association of the code eval was called from, then if the webpage defines a function like this: function runAfterOneSecond(fn) { setTimeout(fn, 1000); } Then the extension can inject a script tag that calls runAfterOneSecond but passes it a string (which setTimeout evals internally) that contains code to inject an image. If that eval'd code is supposed to retain the association with the extension, then that would have to be tracked through the string. Do all strings now require an association field? What if the page code creates a new string based on that string? Does that new string get the association too? What if two strings associated with different extensions are combined? Do the associations get combined so that any code created from the string (or created from anything created from that string transitively) has the union of all of their security limitations? If instead of tracking the associations of values, you tracked whether the extension was on the call stack at the time of code being parsed, then you're out of luck there too. Imagine a page with the code `eval(getCode())`: if the extension overrode the getCode() function, then it could get the page to eval whatever it wanted. Certain popular web frameworks often eval code from the DOM (think inline templates), so it would be easy to write a more generic attack to have the extension stick some code into the DOM formatted in the specific way that the web framework recognizes so that it will eval and run it later. And even if you did manage to successfully restrict extensions from network requests, you'd end up with an extension that can't ever add elements to the page or manipulate elements that reference any external content. You couldn't make an extension for previewing an image on link hover. You could only add a button with an icon on it if that icon was an inline data uri. You probably couldn't reuse classnames from the page's css that referenced a remote background image or font. I would expect that nearly all page-interacting extensions would request the network permission just so they could get anything done. Chrome probably wouldn't spell out that permission in the permissions dialog (instead grouping it into the "Extension can read and change your data on all sites you visit" line) because of how common it was. ... And then they probably wouldn't go through the huge amount of effort and redesigns to support that permission in the first place.