Заголовки безопасности: ремни безопасности для веб-приложений

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

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

СОВЕТ. Узнать больше о заголовках безопасности можно на сайте OWASP.org или SecurityHeaders.com.

Заголовки безопасности на практике

Для проекта OWASP DevSlop Project мы с моей подругой Франциской Бюлер создали несколько видеороликов и записей в блоге о добавлении заголовков безопасности на сайт. Вот пример кода, который можно было бы использовать для ASP.Net:

<! – Start ASP.Net Security Headers – >

<httpProtocol>

<customHeaders>

<add name="X–XSS-Protection" value="1; mode=block"/>

<add name="Content-Security-Policy" value="default-src 'self'"/>

<add name="X-frame-options" value="SAMEORIGIN"/>

<add name="X–Content-Type-Options" value="nosniff"/>

<add name="Referrer-Policy" value="strict-origin-when-cross-origin"/>

<remove name="X-Powered-By"/>

</customHeaders>

</httpProtocol>

<! – End Security Headers – >

Х-XSS-Protection

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

Content-Security-Policy (CSP)

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

Заголовок Content-Security-Policy заставляет перечислять все источники содержимого (скрипты, изображения, фреймы, шрифты и т. д.), которые использует сайт и которые находятся за пределами домена, что не позволит уязвимому веб-приложению вызвать и запустить «вторую» ступень атаки. Таким образом значительно снижается риск и потенциальный ущерб от этого типа атак. Тем не менее разработчики склонны считать, что отслеживание источников отнимает много времени, поэтому данный заголовок не пользуется популярностью. По моему мнению, Content-Security-Policy использовался бы гораздо чаще, если бы разработчики понимали риски и осознавали, какую защиту он обеспечивает. Если разработчика трудно убедить применять этот заголовок, подумайте о том, чтобы одолжить ему эту книгу. Надеюсь, он отблагодарит вас в будущем.

ПРИМЕЧАНИЕ. Никогда не включайте CSP в код без согласия и помощи разработчика. Вообще не следует включать средства безопасности без согласования с командами, на работу которых они могут повлиять, но особенно это касается CSP. Этот заголовок почти наверняка нанесет ущерб внешнему виду сайта и некоторым его функциям, но, что более важно, его применение нанесет ущерб вашим доверительным отношениям с командой разработчиков. Не торопитесь: тщательно протестируйте его перед первым развертыванием.

Самая простая настройка – просто заблокировать все лишнее, если разрабатываемый сайт статичен или имеет примитивный вид (не обращается к стороннему контенту). Настройки в таком случае будут следующими:

Content-Security-Policy: default-src 'self'; block-all-mixed-content;

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

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

• default-src: Как понятно из названия, это настройка по умолчанию, своего рода «поимка всего». При попытке загрузить то, что не имеет четкого определения в остальной части политики, будет применен этот параметр. Его часто устанавливают на self, чтобы запретить загрузку контента, не имеющего четко полученного разрешения в политике. Всегда устанавливайте значение self в случае неуверенности в возможном содержимом сайта.

ПРИМЕЧАНИЕ. Исключением из этого правила являются опции Frame Ancestors и Form Action. Они не возвращаются к default-src.

• script-src: Список доменов (местоположений скриптов) или точный URL-адрес скрипта, которые разрешено запускать как часть сайта. Любой другой скрипт из любого другого места в интернете, кроме тех, что находятся в вашем домене и были включены в перечень разрешенных ресурсов, не будет выполняться. Так осуществляется защита от XSS-атак.

ВНИМАНИЕ. Ключевое слово unsafe-inline может использоваться как часть конфигурации для отмены всех блокировок, произведенных в политике безопасности контента. Оно позволяет запустить любой скрипт из любого места. Нельзя оставлять unsafe-inline в приложениях на постоянной основе: данная опция должна быть лишь временной мерой для проведения тестирования по мере продвижения к зрелой и полной реализации CSP. Кроме того, обязательно проверяйте наличие этой настройки в производстве во время оценки безопасности.

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

– object-src = плагины (надежные источники элементов <object>, <embed> и <applet>);

– style-src = стили (каскадные таблицы стилей, или CSS);

– img-src = изображения;

– media-src = видео и аудио;

– frame-src = фреймы;

– font-src = шрифты;

– plugin-types = ограничивает типы запускаемых плагинов.

• script-nonce: сложная, но заслуживающая внимания директива. Атрибут Nonce – это созданная для однократного использования строка символов, с помощью которой верифицируется вызываемый скрипт. script-nonce является дополнительным уровнем безопасности в заголовке безопасности CSP, а ее использование означает, что для запуска сценария необходим nonce.

СОВЕТ. Строки nonce – сложная тема, так как реализация функции nonce в CSP менялась с течением времени. В связи с этим я рекомендую изучить памятку от OWASP по этой теме, которая содержит свежие сведения и более подробное объяснение: cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html.

• report-uri: CSP может составить отчет, содержащий данные о заблокированных элементах и другую полезную информацию. URI указывает, куда отправить отчет. На данный момент существует всего четыре заголовка безопасности с функцией отчета, и, честно говоря, это действительно здорово. Наличие метрик и информации о типах атак, которым подвергается сайт, – это просто подарок.

ВНИМАНИЕ. URL-адрес отчетов находится в открытом доступе, то есть злоумышленник может просмотреть отчеты, а также провести атаку «отказ в обслуживании» (DoS или DDoS), чтобы скрыть свои злодеяния.

Content-Security-Policy, безусловно, является самым сложным из всех заголовков безопасности. Получить дополнительную информацию можно по адресам csp-evaluator.withgoogle.com (Google) и mscotthelme.co.uk.

Например,

Content-Security-Policy: default-src 'self'; img-src

https://*.wehackpurple.com; media-src https://*.wehackpurple.com;

позволяет браузеру загружать изображения, видео и аудио из *.wehackpurple.com.

Content-Security-Policy: default-src 'self'; style-src

https://*.jquery.com; script-src https://*.google.com;

позволяет браузеру загружать стили из jquery.com и скрипты из google.com.

СОВЕТ. Заголовками безопасности, которые предоставляют отчеты, являются CSP, Expect-CT, Public-Key-Pins и XSS-Protection. Они очень полезны!

ПРИМЕЧАНИЕ. DoS или DDoS означает «отказ в обслуживании» (от англ. denial of service), а дополнительная буква «D» означает «distributed», или «распределенная атака». Цель атаки DoS – перегрузить ресурсы жертвы так, чтобы никто не мог ими воспользоваться. Она может привести к прекращению работы веб-сайта, потере продаж в интернет-магазинах и другим формам блокировки доступа к онлайн-ресурсам. В самом начале DoS-атаки часто исходили из одного-единственного источника, таким образом, IP-адрес можно было заблокировать и сорвать атаку. Со временем злоумышленники поняли, что наличие большого количества (сотен или даже тысяч) различных IP-адресов, запускающих атаку, наносит гораздо больший ущерб и от них трудно защититься. На данный момент большинство DoS-атак являются распределенными (DDoS), часто с использованием взломанных IoT-устройств в качестве составной части атаки.