3

I'm working on an extension that injects script in a page.

The extension is basically a content script that injects another script into the DOM. ( Why not just a content script? )

(There aren't any issues with my code, it works fine. The main purpose here is to learn about security issues in web development only)

The injected script is a source file in my extension and I get it with JQuery.get, using the address from chrome.extension.getURL('myscript.js').

Are there any security issues I should be aware of?

The page is not https, can this get return something different from my script?

I also insert HTML content using the same method. The HTML file is from my extension, just like the scritp. Is there any possibility of the responsetext be corrupted by a man in the middle??

What are the common practices to avoid such security issues if they exist?

Differently, if I create a script (document.createElement('script')) and set its source to my file. Would it be possible for someone to interfere when I inject this cript into the dom? (document.documentElement.appendChild(myScipt))

Also, what are the security issues involving this approach? Injecting a script that changes the XMLHttpRequest methods open and send in order to capture ajax calls, add listeners and send them with the same exact original arguments.

So, namely, say I have these:

var myScript = document.createElement('script');
myScript.src = chrome.extension.getURL('myscript.js');
var page = chrome.extension.getURL('mypage.html');
  • In such context, can a $.get('mypage.html') return anything different from my page due to a man in the middle? (In other words, could I unknowingly inject a malicious page?)
  • Could a document.documentElement.append(myScript) inject a different script? Could a supposed man in the middle get between the .src and change the actual script?
  • Since the script is meant to change the XMLHttpRequest prototype as described in the linked approach, could I ever send with arguments different from those passed by the original call?

Thank you!

Community
  • 1
  • 1
Daniel Möller
  • 84,878
  • 18
  • 192
  • 214
  • [Content scripts](https://developer.chrome.com/extensions/content_scripts) should be used for injection of such code (see also [Programmatic injection](https://developer.chrome.com/extensions/content_scripts#pi) in the same document). – wOxxOm Jul 08 '15 at 18:31
  • It must be injected into the DOM by a content script as described. That's the only way it works. – Daniel Möller Jul 08 '15 at 18:32
  • And what exactly prevents you from using a content script or chrome.tabs.executeScript? – wOxxOm Jul 08 '15 at 18:33
  • It doesn't work, you can see all details in the linked approach there. – Daniel Möller Jul 08 '15 at 18:34
  • I never tried "chrome.tabs.executeScript", I might take a look at that. Is it safer than what I'm doing? – Daniel Möller Jul 08 '15 at 18:35
  • To answer the original question: the first jQuery.get call that fetches the script code is invoked in the context of the extension, which is why it succeeds. Then the script is injected in the context of the page so there's no way for it to access anything else from your extension directly unless you inject it explicitly yourself. – wOxxOm Jul 08 '15 at 18:41
  • I understand that. Assume I know exactly what I can and what I cannot do, and why I decided to inject the script that way. I have no problems with that, and it works perfectly. The question is solely about possible security failures, attacks from others, receiving requests different from expected and things like that. – Daniel Möller Jul 08 '15 at 18:53

1 Answers1

1

First of all, Chrome is both the client and the server when you fetch a file from an extension, so you don't need https, it's worthless in this scenario. There is no man in the middle here.

One can think of another extension intercepting the ajax, but to do so that extension should already have proper permissions granted by the user, so it won't be an unauthorized interception. At least it won't be any less secure than any https ajax.

And, as you say, another man in the middle attack consists in redefining XMLHttpRequest, which you can do with an extension (with proper user authorization) or any other way to inject a script in the page (specially if the page is not a secure one).

I wonder if you can inject and run a script before the page loads, or at least before any other script execute, with the only purpose to "secure" the original XMLHttpRequest object (with something like mySecureAjax = XMLHttpRequest;)

You can execute before any script on the page, but you can't guarantee to execute before another extension's injection.

Alejandro Silvestri
  • 3,706
  • 31
  • 43
  • 1
    Then it means....if someone can change the XMLHttpRequest (as I did), my extension can get a different result for my files, even being Chrome the client and server, right? I ask for my files via AJAX, if the XMLHttpRequest is corrupted, I can get anything else.... – Daniel Möller Jul 11 '15 at 00:02
  • Or does the XMLHttpRequest I use in my extension belongs only to the extension context, so it's always safe? (After all, I must hunt for the page's XMLHttpRequest into the dom, because changing it in the content script results in nothing....? I'll test that. – Daniel Möller Jul 11 '15 at 00:29
  • 1
    Cool. The `XMLHttpRequest` of the **content script** is not affected by the changes of the `XMLHttpRequest` of the **page**. So, I'm safe indeed :) What about the `scriptelement.src = chrome.extension.getURL(...)`, could it be ever hacked somehow? – Daniel Möller Jul 11 '15 at 01:16
  • 1
    Your answer really helped me a lot here. I edited the question a little, regarding the `myScript.src`. Do you have anything to say about that? – Daniel Möller Jul 11 '15 at 01:21
  • Yes, assigning myScript.src is a better way to put your script in the page, and you also avoid using XMLHttpRequest. And yes, scripts in the page can't affect extension context's XMLHttpRequest. I don't know your worry about "someone" changing this object, but your extension can put the HTML on the DOM, without using XMLHttpRequest. – Alejandro Silvestri Jul 11 '15 at 21:28
  • My worries are exactly putting some HTML that is not my own. But that is not a risk, as I understood from your answer. Is the `.src` as safe as the rest? – Daniel Möller Jul 11 '15 at 22:27
  • How to insert the HTML without the request? (besides hard-coding it in a text var?) – Daniel Möller Jul 11 '15 at 22:33
  • You can inject a content script to interact with the DOM, to insert your HTML. You can safely use XMLHttpRequest in your content script without worrying, because nobody else can change it, it runs in a separate javascript environment. – Alejandro Silvestri Jul 12 '15 at 23:05