从 Chrome 扩展程序执行跨源请求时存在 XMLHTTPRequest 漏洞？

Question

You can do cross origin requests with Chrome extensions. I created a test Chrome extension to fiddle with this. It gets all the code in a specific page from a site at the click of a button.

All I want from the page is data (just some text and numbers) to then display it in the options page of the extension.

The way I'm extracting this data is by traversing the document in the response (the response or responseXML property of the request). For example, I use querySelectorAll to get a bunch of elements, then I put all of their textContent properties in an array, then I put each element on the array in a <ul> in the DOM of the extension page.

Lastly, after I request a particular page from the site, I store the response document in my localStorage (only the last page requested will be stored, overwriting the previous page stored). I'm doing this by storing the outerHTML of the response element (through document.documentElement.outerHTML ). Then when I refresh the extension page, I use DOMParser and parseFromString to convert it back to a document. After it's been converted back to a document, the stuff in the previous paragraph happens again (the DOM traversing and extraction of data).

Any potential security issues?

MDN says this:

"Processing a responseText property containing an HTML document If you use XMLHttpRequest to get the content of a remote HTML webpage, the responseText property is a string containing the raw HTML. This could prove difficult to manipulate and analyze. There are three primary ways to analyze and parse this raw HTML string:

1. Use the XMLHttpRequest.responseXML property as covered in the article https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/HTML_in_XMLHttpRequest

2. HTML in XMLHttpRequest. Inject the content into the body of a document fragment via fragment.body.innerHTML and traverse the DOM of the fragment.

3. RegExp can be used if you always know the content of the HTML responseText beforehand. You might want to remove line breaks, if you use RegExp to scan with regard to linebreaks. However, this method is a "last resort" since if the HTML code changes slightly, the method will likely fail."

I am using the first method.

This page talks about dangerous and safe methods of handling the response (although here it's talking about responseText, not an html document gotten from response or responseXML): https://developer.chrome.com/apps/xhr

Summary:

    // 1. WARNING! Might be evaluating an evil script!
    var resp = eval("(" + xhr.responseText + ")");

    // 2. WARNING! Might be injecting a malicious script!
    document.getElementById("resp").innerHTML = xhr.responseText;

    // 3. JSON.parse does not evaluate the attacker's scripts.
    var resp = JSON.parse(xhr.responseText);

    // 4. innerText does not let the attacker inject HTML elements.
    document.getElementById("resp").innerText = xhr.responseText;

The only issue here is number 2. I have used innerHTML to create a <li> 's in a <ul> with data from the response doc. Now, I know this site, but I guess I could change this to not use innerHTML.

Answer 1

Safe API/properties:

• textContent or innerText are absolutely secure

• responseXML is secure, see step 5 in XHR specification :

  scripting support disabled on received bytes

• DOMParser API is secure just the same.

Potentially unsafe:

• innerHTML won't run <script> elements, see ( HTML5 spec ):

  When inserted using the innerHTML and outerHTML attributes, they do not execute at all.

  but it'll run inline code in event handler attributes like <img src="x" onerror="alert(1)"> and although normally this won't run in an extension page due to the default CSP forbidding inline code in extension pages, but many authors need to relax the CSP.

  Even if you didn't relax the default CSP and want to use the raw foreign html in the main document, you need to strip <style> and <link> elements as those can alter the main page appearance, remove the on attributes, <script> elements as well (just for consistency). Or put that HTML inside an iframe with sandbox attribute instead.

  There's also Mozilla's policy to consider:

  If your project is one that will undergo any form of security review, using innerHTML most likely will result in your code being rejected. For example, if you use innerHTML in a browser extension and submit the extension to addons.mozilla.org, it will not pass the automated review process.