Разделы портала

Онлайн-тренинги

.
Руководство по XSS, часть 5
18.03.2020 01:00

Авторы: Джейкоб Каллин и Ирен Лобо Валбуэна (Jakob Kallin, Irene Lobo Valbuena)
Оригинал статьи
Перевод: Ольга Алифанова

Руководство по XSS, часть 1
Руководство по XXS, часть 2
Руководство по XSS, часть 3
Руководство по XXS, часть 4

Политика защиты содержимого (CSP)

Недостаток защиты от XSS путем использования только безопасного обращения со вводом в том, что даже единичный отказ безопасности может скомпрометировать ваш сайт. Недавно созданный стандарт под названием "Политика защиты содержимого" позволяет снизить этот риск.

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


CSP можно использовать для внедрения следующих правил:

  • Никаких недоверенных источников. Внешние ресурсы могут загружаться только из набора явно определенных доверенных источников.
  • Никаких встроенных ресурсов. Встроенные JavaScript и CSS выполняться не будут.
  • Никакого eval. Функция JavaScript eval не может быть использована.

Политика защиты данных в действии.

В примере ниже злоумышленник преуспел во внедрении вредоносного кода в страницу:

<html>

Latest comment:

<script src="http://attacker/malicious‑script.js"></script>

</html>

При правильно определенной политике CSP браузер не будет загружать и выполнять malicious‑script.js, так как http://attacker/ не находится в списке доверенных источников. Несмотря на то, что сайту не удалось нейтрализовать пользовательский ввод, политика защиты данных не дала уязвимости нанести сайту вред.

Как разрешить CSP

Браузеры по умолчанию не навязывают CSP. Чтобы разрешить CSP для своего сайта, вы должны включить на страницы дополнительный HTTP-заголовок: Content-Security-Policy. Браузер будет учитывать политику защиты данных любой страницы с таким заголовком, если браузер в принципе поддерживает CSP.

Так как политика защиты отправляется с каждым HTTP-ответом, то сервер может устанавливать политику отдельно для каждой страницы. Одна и та же политика может применяться ко всему сайту, если CSP-заголовок одинаков для всех ответов сервера.

Значение заголовка Content‑Security‑Policy – это строка, определяющая одну или несколько влияющих на сайт политик. Далее мы рассмотрим синтаксис этой строки.

Примеры заголовков в этом разделе используют новые строки и отступы для внятности. В реальном заголовке все это будет отсутствовать.

Синтаксис CSP

Синтаксис CSP-заголовка выглядит так:

Content‑Security‑Policy:

Директива условие-источника, условие-источника, ...;

директива ...;

...

Этот синтаксис состоит из двух элементов:

  • Директивы – это строки, определяющие тип ресурса, и для них есть предопределенный список.
  • Условия источника – это паттерны, описывающие сервер или серверы, с которых можно загружать ресурсы.

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

Директивы

В CSP-заголовке можно использовать следующие директивы:

  • connect‑src
  • font‑src
  • frame‑src
  • img‑src
  • media‑src
  • object‑src
  • script‑src
  • style‑src

Помимо этого, есть особая директива default‑src, предоставляющая значение по умолчанию для всех директив, не включенных в заголовок.

Условия источника

Синтаксис условия источника выглядит так:

протокол://имя-хоста:номер_порта

Имя хоста может начинаться с *, означающей, что любой поддомен имени хоста разрешается. Схожим образом номер порта может быть *, что значит, что все порты разрешены. Помимо этого, протокол и номер порта можно опустить. И, наконец, протокол может быть единственным условием – например, так можно требовать, чтобы все ресурсы загружались через HTTPS.

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

  • 'none'. Все ресурсы запрещены.
  • 'self'. Разрешает ресурсы от хоста, который предоставил страницу.
  • 'unsafe-inline'. Разрешает встроенные на страницу ресурсы – такие, как встроенные элементы <script>, <style>, и javascript:URL.
  • 'unsafe-eval'. Разрешает использование функции JavaScript eval.

Заметьте, что при использовании CSP встроенные ресурсы и eval по умолчанию запрещены. Использование 'unsafe‑inline' и 'unsafe‑eval' – единственный способ их разрешить.

Пример политики

Content‑Security‑Policy:

script‑src 'self' scripts.example.com;

media‑src 'none';

img‑src *;

default‑src 'self' http://*.example.com

В этом примере политики страница ограничена следующими ограничениями:

  • Скрипты можно загружать только с хоста, предоставившего страницу, и со страницы scripts.example.com.
  • Аудио и видео-файлы нельзя загружать вообще.
  • Файлы изображений можно загружать откуда угодно.
  • Все прочие ресурсы можно загружать только с хоста, предоставившего страницу, и с любого поддомена example.com.

Статус CSP

С июня 2013 года политика защиты данных – это рекомендация W3C. Она внедряется разработчиками браузеров, однако ее части до сих пор браузерозависимы. В частности HTTP-заголовок может различаться от браузера к браузеру. Прежде чем воспользоваться CSP, проконсультируйтесь с документацией поддерживаемых вами браузеров.

Резюме

Что такое XSS

  • XSS – это атака инъекции кода, которая возможна при небезопасном обращении с пользовательским вводом.
  • Успешная XSS-атака позволяет атакующему выполнить вредоносный JavaScript в браузере жертвы.
  • Успешная XSS-атака компрометирует безопасность сайта и его пользователей.

XSS-атаки

  • Существует три основных типа XSS-атак:
    • Длительная XSS-атака, когда вредоносная строка хранится в базе данных сайта.
    • Отраженная XSS-атака, когда вредоносная строка создается в запросе жертвы.
    • Основанная на DOM атака, когда уязвимость находится в клиентском коде, а не в серверном.
    • Все эти атаки выполняются по-разному, однако эффект у них одинаковый.

Предотвращение XSS

  • Самый важный путь предотвращения XSS-атак – это безопасное обращение со вводом.
    • В большинстве случаев при включении пользовательского ввода на страницу должно выполняться шифрование.
    • В некоторых случаях шифрование нужно заменять или дополнять валидацией.
    • Безопасное обращение со вводом должно учитывать контекст страницы, в которую встраивается пользовательский ввод.
    • Для предотвращения всех типов XSS-атак безопасное обращение со вводом должно затрагивать и клиентский, и серверный код.
    • Политика защиты данных дает дополнительный уровень защиты для случаев, когда безопасное обращение со вводом не сработало.

Дополнение

Следует отметить, что при описании XSS есть перенахлест терминологии – основанная на DOM-атака также является или длительной, или отраженной, это не некий отдельный тип атаки. Широко принятой терминологии, покрывающей все типы атак без перенахлеста, не существует. Вне зависимости от терминологии для каждой атаки важно понимать, откуда идет вредоносный ввод, и где расположена уязвимость.