Привязка открытого ключа (англ. Public Key Pinning) – это система, созданная для защиты от поддельных сертификатов. Ее идея заключалась в том, что доверять определенному URL-адресу или сайту можно было только при наличии сертификата от одного или двух центров сертификации. Сначала она реализовывалась с помощью статических привязок (встроенных в браузер непосредственно и вручную, в частности в Chrome и Firefox). Со временем владельцы других сайтов тоже захотели «привязать» сертификаты, в результате чего появились динамические привязки. Сертификат привязывался на определенный период времени (обычно на год) к определенному криптографическому идентификатору (ключам). Потеря ключей при этом означала потерю контроля над сайтом на срок до года, поскольку без них он не работал. URL сайта по сути оказывался «замурованным» (непригодным для использования), и в результате эта функция безопасности наносила катастрофический ущерб бизнесу. Такая ситуация называется «самоубийством с помощью HPKP».
Хотя использование данного заголовка безопасности потенциально дает большие преимущества, высокие риски делают его нежелательным средством защиты. Он применяется в тех случаях, когда требуется чрезвычайно высокий уровень безопасности и когда с ним работает команда, очень хорошо разбирающаяся в этой теме и готовая принять бизнес-риски.
ВНИМАНИЕ. Заголовок безопасности Public Key Pinning Extension for HTTP (HPKP) считается устаревшим и более не поддерживается.
Протокол HTTP никогда не был предназначен для обработки пользовательских сессий (то есть отслеживания входов в систему или наличия товаров в корзине. Отслеживание того, как пользователь переходит с одной страницы на другую внутри сайта, называется «состоянием»). Cookie используются для передачи информации о сессии пользователя от браузера к веб-серверу и могут быть сохранены для усиления персонализации (например, сохранения языковых предпочтений) в будущем. Многие сайты используют cookie для хранения информации в целях осуществления маркетинговых действий и отслеживания поведения пользователей, а также для продажи информации другим компаниям. Мы не будем рассматривать этические аспекты конфиденциальности данных, хранящихся в cookie.
Для обеспечения безопасности данных в файлах cookie необходимо применить нижеизложенные параметры.
Обратите внимание, что иногда разработчики решают использовать вместо cookie локальное хранилище. Для его защиты применяются совершенно иные меры безопасности, и в данном разделе они рассматриваться не будут. Кроме того, передача сессии должна происходить не в постоянном, а только в сессионном файле cookie и никогда не храниться в локальном хранилище. Всегда используйте сессионные файлы cookie.
Также не забывайте каждый раз проверять ввод в файлах cookie. Если получаемые данные не имеют смысла, отклоните их и попробуйте снова. Данные в файле cookie очень ценны, поэтому необходимо позаботиться о постоянной защите сессии (подробнее об этом в следующих главах).
Флаг Secure
гарантирует, что файл cookie будет отправлен только по зашифрованным (HTTPS) каналам. Если злоумышленник попытается перевести сессию на HTTP, веб-приложение откажется отправлять cookie. Данная настройка должна быть включена на постоянной основе:
Set-Cookie: Secure; (плюс все остальные настройки)
Так как данный флаг не имеет ничего общего с принудительным незашифрованным соединением (HTTP), его название вносит путаницу среди программистов. Когда он установлен, то это значит, что к файлу cookie нельзя получить доступ через JavaScript. Его можно изменить только на стороне сервера. Причина использования этого параметра заключается в защите от XSS-атак, которые пытаются получить доступ к значениям в файле cookie. Необходимо всегда устанавливать данный флаг во всех cookie в качестве еще одного уровня защиты от XSS-атак, угрожающих конфиденциальности данных:
Set-Cookie: HttpOnly; (плюс все остальные настройки)
При сборе конфиденциальных данных пользователя либо при управлении сессией файлы cookies не должны быть постоянными. Они должны самоуничтожаться в конце сессии, чтобы защитить данные. Файл cookie, который самоуничтожается в конце сессии, называется «сессионным cookie», в противном случае – «постоянным cookie» или «отслеживающим cookie». Решать, какой тип cookie вам подходит, необходимо с помощью команды по обеспечению конфиденциальности и бизнес-аналитиков.
Для постоянных файлов cookie можно с помощью атрибута expires
установить дату окончания действия, а через параметр max-age
– определить максимальный срок жизни cookie.
Окончание действия: 1 января 2021
Set-Cookie: Expires=Mon, 1st Jan 2021 00:00:00 GMT; (плюс все остальные настройки)
Максимальный срок жизни – 1 час
Set-Cookie: Max-Age=3600; (плюс все остальные настройки)
Чтобы к файлам cookies могли получить доступ сторонние домены, нужно указать их как доверенные домены с помощью атрибута domain
, иначе браузеры будут считать, что cookies предназначены «только для хоста», то есть доступны только вашему домену, а попытки других доменов получить доступ будут блокироваться. Этот тип встроенной защиты считается «безопасным по умолчанию». Вот бы все настройки программного обеспечения работали таким образом!
Set-Cookie: Domain=app.NOTwehackpurple.com; (плюс все остальные настройки)
ВНИМАНИЕ. Если поддомен не задан (то есть вы указали NOTwehackpurple.com вместо app.NOTwehackpurple.com), каждое приложение и страница, размещенные в этом домене, смогут получить доступ к вашему файлу cookie.