Последствия, исправления и многое другое

TL;DR

  • Эд Морли из Mozilla сообщил о проблеме безопасности.
  • Я обнаружил еще несколько проблем с безопасностью.
  • Эти проблемы были исправлены в
    webpack-dev-server@^2.4.3,
    webpack-dev-server@^1.16.4,
    webpack-dev-middleware@^1.10.2.
  • Исправления - это критические изменения для небезопасных конфигураций.
  • Не используйте disableHostCheck или Access-Control-Allow-Origin: *

Отказ от ответственности

Я не эксперт по безопасности, поэтому, возможно, некоторые данные неверны / неточны.

Этот пост предназначен для объяснения последствий и повышения осведомленности.
Так что все остается простым.

Проблемы

Проблема №1: повторная привязка DNS для доступа к webpack-dev-серверу

Об этой проблеме сообщил Эд Морли из Mozilla. Вот полный отчет: https://github.com/webpack/webpack-dev-server/issues/887

Повторное связывание DNS: запись DNS на 127.0.0.1 позволяет плохому сайту делать запросы к локальному хосту, и они не рассматриваются браузером как перекрестный источник. Эти запросы позволяют утечку информации из локальных сервисов.

Атака использует повторное связывание DNS для доступа к серверу webpack-dev. Это предполагает, что злоумышленник знает порт dev-сервера и заставляет вас открыть вредоносный сайт во время работы dev-сервера.

Вывод: злоумышленник может отправить любой запрос на сервер webpack-dev и прочитать ответ. Это может привести к утечке вашего скомпилированного исходного кода и предоставить злоумышленнику доступ к вашим внутренним службам, когда вы используете функцию прокси для прокси внутренних служб.

Исправление: серверу webpack-dev-server необходимо проверить заголовок Host запроса, чтобы убедиться, что запрос может быть сделан только с правильного URL. Это запрещает повторную привязку DNS. Примечание: злоумышленники по-прежнему могут делать любые запросы к dev-серверу, как всегда, но эти запросы выполняются в соответствии с политикой кросс-происхождения.

Для исправления dev-серверу необходимо знать хост / URL-адрес, который вы используете для доступа к dev-серверу. По умолчанию мы используем адрес прослушивания (т.е. для--host my-computer --port 8080 URL должен быть http://my-computer:8080). Если вы предоставляете общедоступный URL-адрес, сервер разработки также принимает этот URL-адрес (т.е. --host 0.0.0.0 --public example.company.com). Это должен быть обычный способ предоставить URL-адрес для проверки безопасности.

Это возможность отключить проверку безопасности (disableHostCheck), но, пожалуйста, не используйте ее! Если вы действительно этого хотите, убедитесь, что вы полностью понимаете эту проблему безопасности.

Проблема # 2: sockjs-сервер webpack-dev-server принимает все соединения

Всем разрешено подключиться к sockjs серверу dev-сервера.

Последствия: злоумышленник получает доступ к статистике веб-пакета, в которой содержится ваш исходный код.

Исправление: то же, что и выше. Проверить заголовок Host для входящих соединений.

Проблема № 3: webpack-dev-middleware отправляет Access-Control-Allow-Origin: *

Всем разрешено делать запросы к ресурсам webpack для webpack-dev-server.

Последствия: утечка скомпилированного исходного кода.

Исправление: удалите заголовок по умолчанию в webpack-dev-middleware. Пользователь должен вручную установить Access-Control-Allow-Origin с правильным хостом.

Не устанавливайте Access-Control-Allow-Origin: *, потому что это снова открывает вектор атаки.

Выпуск этих критических изменений в виде патча

Да, я знаю, что это странно и противоречит семверу, но я решил опубликовать эти изменения как версию патча. Это может сломать ваши инструменты разработчика.

Я пошел по этому пути, потому что знаю, что если бы эти исправления были опубликованы как новая основная версия, большинство пользователей не перешли бы на новую версию и столкнулись бы с этими проблемами безопасности.

Я знаю, что это будет раздражать некоторых пользователей, потому что их настройки разработки сейчас нарушены, но я рискую, чтобы защитить их. Может быть, они читают примечания к выпуску, когда он ломается.

Я думаю, что безопасная установка стоит того, чтобы нарушить некоторые настройки ... Это только часть разработки ...

Если ваша установка не работает, пройдите --public xxx:yyy соотв. public: "xxx:yyy" и / или headers: { "Access-Control-Allow-Origin": "xxx:yyy" } как devServer параметры (xxx: хост, yyy: порт).

Заключение

До этих проблем я считал инструмент разработки не критичным для безопасности. Так что я не особо заботился о безопасности. Я был неправ. Любой инструмент, который открывает порты на вашем компьютере, даже только на локальном хосте, потенциально может быть доступен из Интернета.

Поэтому убедитесь, что инструменты, открывающие порты, защищены от повторного связывания DNS и CSRF. Думаю, здесь затронуты и другие инструменты разработки ...

Примечания

  • Некоторые DNS-серверы фильтруют DNS-записи по локальным IP-адресам.
  • Считайте все пароли / ключи в вашей «базе контента» (по умолчанию текущим каталогом) утечкой.