Уязвимости XMLHTTPRequest при выполнении перекрестных запросов от расширения Chrome? - PullRequest
Новая
       36

Уязвимости XMLHTTPRequest при выполнении перекрестных запросов от расширения Chrome?

0 голосов
/ 20 января 2020

Вы можете выполнять запросы кросс-источника с расширениями Chrome. Я создал тестовое расширение Chrome, чтобы поиграть с этим. Он получает весь код на указанной странице c с сайта одним нажатием кнопки.

Все, что мне нужно на этой странице, - это данные (только текст и цифры), чтобы затем отобразить их на странице параметров расширения.

Я извлекаю эти данные путем обхода документ в ответе (свойство запроса response или responseXML). Например, я использую querySelectorAll для получения группы элементов, затем я помещаю все их свойства textContent в массив, а затем помещаю каждый элемент массива в <ul> в DOM страницы расширения.

Наконец, после того, как я запрашиваю определенную страницу с сайта, я сохраняю документ ответа в моем localStorage (будет сохранена только последняя запрошенная страница, перезаписывая предыдущую сохраненную страницу). Я делаю это, сохраняя outerHTML элемента ответа (через document.documentElement.outerHTML). Затем, когда я обновляю sh страницу расширения, я использую DOMParser и parseFromString, чтобы преобразовать ее обратно в документ. После того, как он был преобразован обратно в документ, материал из предыдущего абзаца повторяется снова (обход DOM и извлечение данных).

Есть ли потенциальные проблемы безопасности?

MDN говорит следующее:

"Обработка свойства responseText, содержащего документ HTML Если вы используете XMLHttpRequest для получения содержимого удаленной HTML веб-страницы, свойство responseText представляет собой строку, содержащую необработанный HTML. Это может доказать трудно манипулировать и анализировать. Существует три основных способа анализа и анализа этой необработанной строки HTML:

  1. Использование свойства XMLHttpRequest.response XML, как описано в статье https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/HTML_in_XMLHttpRequest

  2. HTML в XMLHttpRequest. Вставьте содержимое в тело фрагмента документа с помощью frag.body.inner HTML и проследуйте DOM-фрагмент.

  3. RegExp можно использовать, если вы всегда заранее знаете содержание HTML responseText. Возможно, вы захотите удалить разрывы строк, если вы используйте RegExp для сканирования относительно разрывов строк. Однако этот метод является «последним средством», поскольку, если код HTML слегка изменится, метод, скорее всего, завершится ошибкой. "

Я использую первый метод.

На этой странице говорится об опасных и безопасных методах обработки ответа (хотя здесь речь идет о тексте responseText, а не html документе, полученном из ответа или ответа XML): https://developer.chrome.com/apps/xhr

Резюме: 

    // 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;

Единственная проблема здесь - номер 2. Я использовал внутренний HTML для создания <li> в <ul> с данными из ответа do c. Теперь я знаю этот сайт, но, думаю, я мог бы изменить это, чтобы не использовать inner HTML.

1 Ответ

1 голос
/ 20 января 2020

Безопасный API / свойства:

  • textContent или innerText абсолютно безопасны

  • responseXML безопасны, см. шаг 5 в спецификации XHR :

    отключена поддержка сценариев для полученных байтов

  • DOMParser API безопасен точно так же .

Потенциально небезопасно:

  • innerHTML не будет работать <script> элементов, см. (HTML5 spe c):

    При вставке с использованием внутренних атрибутов HTML и внешних HTML они не выполняются вообще.

    , но это ' Запустим встроенный код в атрибутах обработчика событий, таких как image, и хотя обычно он не запускается на странице расширения из-за CSP по умолчанию, запрещающего встроенный код на страницах расширения, но многим авторам нужно ослабить CSP .

    Даже если вы не расслабили CSP по умолчанию и хотите использовать необработанные сторонние html в основном документе, вам нужно удалить элементы <style> и <link>, так как они могут изменить При появлении главной страницы удалите атрибуты on, а также элементы <script> (только для согласованности). Или поместите это HTML в iframe с атрибутом sandbox.

    Существует также политика Mozilla для рассмотрения:

    Если ваш проект является тем, который в соответствии с go любой формой проверки безопасности, использование внутренней HTML скорее всего приведет к отклонению вашего кода. Например, если вы используете inner HTML в расширении браузера и отправляете расширение на addons.mozilla.org, оно не пройдет процесс автоматического просмотра.

...