Что пишут в блогах

Подписаться

Что пишут в блогах (EN)

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

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

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

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

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

Валидация

Валидация – это фильтрация пользовательского ввода таким образом, что все вредоносные участки удаляются, но при этом не происходит удаления всего кода целиком. Один из самых распространенных типов валидации в веб-разработке разрешает ряд HTML-элементов (например, <em>, <strong>), но запрещает прочие (такие, как <script>).

Внедрение имплементации имеет две основных характеристики:

  • Стратегия классификации. Пользовательский ввод может классифицироваться через черный список или белый список.
  • Результат валидации. Ввод, определенный как вредоносный, может отвергаться или чиститься от вредоносных частей.

Стратегия классификации

Черный список

Инстинктивно кажется разумным проводить валидацию путем определения запрещенного паттерна, который должен отсутствовать в пользовательском вводе. Если строка соответствует этому паттерну, она помечается как невалидная. К примеру, пользователям разрешено вводить URL с любым протоколом, кроме javascript. Такая стратегия классификации называется "черный список".

Однако у черного списка есть два значимых недостатка.

Сложность.

Очень трудно точно описать набор всех возможных вредоносных строк. Пример политики, описанной выше, нельзя успешно внедрить простым поиском по слову javascript, потому что тогда будет упущена форма "Javascript:" (с заглавной буквы), а также "&#106;avascript:" (где первая буква закодирована).

Устаревание

Даже если бы идеальный черный список и существовал, он засбоил бы при добавлении в браузер новой функциональности, позволяющей вредоносное использование. К примеру, черный список HTML-валидации, разработанный до введения атрибута HTML5 onmousewheel, не сможешь предотвратить XSS-атаку с использованием этого атрибута. Этот недостаток особенно значим в веб-разработке, состоящей из массы различных, постоянно обновляющихся технологий.

В связи с этими недостатками черный список не рекомендуется как классификационная стратегия. Белый список, как правило, куда более безопасен, и об этом мы сейчас и расскажем.

Белый список

Белый список – в целом противоположность черному: вместо того, чтобы определять запрещенный паттерн, белый список определяет разрешенный, и помечает ввод как невалидный, если он не соответствует этому паттерну.

В отличие от примера с черным списком, примером белого будет разрешение вводить URL, содержащие только протоколы http: и https:, и ничего более. Этот подход автоматически пометит URL невалидным, если в нем есть javascript-протокол, даже если он будет указан как "Javascript:" или "&#106;avascript:".

По сравнению с черным списком, у белого есть два значимых преимущества:

Простота

Точное описание набора безопасных строк – намного более простое дело, нежели определение всех вредоносных. Это особенно верно в распространенных ситуациях, когда пользовательский ввод должен включать лишь небольшой набор доступной в браузере функциональности. К примеру, вышеописанный белый список, разрешающий только URL с протоколами http и https, очень прост, и адекватен большинству ситуаций.

Долговечность

В отличие от черного списка, белый список не склонен устаревать при добавлении новой функциональности в браузер. К примеру, белый список HTML-валидации, разрешающий только атрибут title, продолжит работать, даже если он создан до введения атрибута HTML5 onmousewheel.

Результат валидации

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

Отказ

Ввод просто отвергается, предотвращая его использование на сайте.

Очистка

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

Из этих двух подходов отказ наиболее прост. Однако очистка может быть полезнее, так как дает пользователю более широкие возможности. К примеру, если пользователь вводит номер кредитной карты, очистка, удаляющая все нечисловые символы, предотвратит инъекцию кода, при этом позволяя пользователю вводить номер со знаками переноса.

Если вы решили внедрить очистку, вы должны убедиться, что подход к очищению не использует метод черного списка. К примеру, URL "Javascript:…", даже будучи определенным как невалидный методом белого списка, проберется через метод очистки, просто удаляющий все включения "javascript:". По этой причине для очистки должны использоваться хорошо протестированные библиотеки и фреймворки.

Какую технику предотвращения использовать

Шифрование должно быть первой линией защиты от XSS, так как его основная цель – нейтрализация данных, чтобы они не интерпретировались как код. В некоторых случаях шифрование должно сопровождаться валидацией, как уже говорилось выше. Такое шифрование и валидация должны быть исходящими, потому что вы будете знать, для какого контекста шифровать и валидировать, только после того, как ввод появится на странице.

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

Если эти линии защиты используются согласованно, сайт будет защищен от XSS-атак. Однако из-за сложности создания и поддержки сайтов добиться полной защиты путем безопасного обращения со вводом может быть трудным делом. В качестве третьей линии защиты стоит использовать политику защиты содержимого (Content Security Policy, CSP), о которой мы поговорим в следующий раз.

Обсудить в форуме