Фактически большинство URL-адресов в интернете представляют собой множество отдельных приложений, имеющих различные пути и поддомены. Для пользователя они выглядят как одна огромная веб-страница, но на самом деле это тысячи различных приложений. В такой ситуации лучше всего ограничить доступ к cookie только определенной областью местоположения приложения – его «путем». Ограничение области действия cookie осуществляется с помощью атрибута path
:
Set-Cookie: path=/YourApplicationsPath; (плюс все остальные настройки)
Атрибут same-site
был создан компанией Google для борьбы с межсайтовой подделкой запроса (CSRF). CSRF, ласково называемый «си сёрф», представляет собой атаку на авторизованных на надежном сайте пользователей, при которой злоумышленник пытается совершить действия от имени пользователя без его согласия или ведома. Обычно атака происходит через фишинговое электронное письмо.
Представим, что Алиса собирается принять участие в телевизионном шоу, в котором будет рассказывать о своей компании. Чтобы выглядеть великолепно, она решила купить новый наряд через интернет. Алиса заходит на сайт любимого магазина одежды и, просматривая новинки, замечает, что ей пришло письмо. Оно фишинговое: в нем содержится ссылка на сайт, на котором она в данный момент авторизована, с закодированной инструкцией, позволяющей злоумышленнику купить какой-нибудь продукт и отправить его себе, а не Алисе. Если она нажмет на данную ссылку, а сайт не обеспечен надлежащей защитой, вся атака может произойти без ее участия и вовсе остаться незамеченной. При этом атака сработает только в том случае, если на момент ее совершения Алиса будет авторизована на сайте, указанном в фишинговом письме.
Данная ситуация может показаться надуманной, но вспомните, как вы работаете со своей учетной записью (аккаунтом). Всегда ли нажимаете кнопку «Выход»? Бывает ли такое, что сайт остается открытым в течение нескольких дней? Никто не совершенен, и наша работа – защищать пользователей наших сайтов, даже если они совершают такую ошибку, как нажатие на фишинговую ссылку.
Таким образом, атрибут cookie same-site
обеспечивает соблюдение правила, согласно которому cookies могут поступать только с одного сайта. Cookies не могут передаваться между различными сайтами (то есть исходить не с вашего сайта). Возможны следующие варианты применения данного атрибута: None
(файлы cookies могут исходить откуда угодно), Strict
(только с собственного домена) и Lax
(если нужно, чтобы cookies отправлялись при переходе по ссылке или с другой страницы, в них должна содержаться только нейтральная информация). Если ни одно из данных значений не установлено, то по умолчанию в современных браузерах используется lax:/
, а в старых версиях – none
.
Lax
означает, что пользователи могут оставаться в учетной записи и посещать другие сайты, а по возвращении на сайт файлы cookies будут продолжать работать. Lax
обычно используется для навигации и других функций, выполняемых приложением до того, как пользователь войдет в систему. Он блокирует очевидные CSRF-атаки (POST-запросы). Lax нельзя назвать надежным решением, однако это хороший компромисс, если не получается использовать значение strict
.
Set-Cookie: same-site=Strict; (плюс все остальные настройки)
Set-Cookie: same-site=Lax; // блокирует только POST-запросы, разрешает переход по ссылке
Префиксы для файлов cookies были введены относительно недавно и принимаются еще не всеми браузерами. Тем не менее они являются одним из средств «защиты в глубину» (дополнительным уровнем безопасности) для случаев ошибочной обработки файлов cookies. Например, если поддомен был взломан, а в настройках cookies Path
указан весь домен, то взломанный домен может попытаться получить доступ к файлу cookie. Префиксы расположены в имени файла cookie, и поэтому сервер увидит его, несмотря на то, зашифрован он или нет. Обеспечить доступ к cookie только в пределах определенного поддомена можно с помощью префикса host
. Более подробную информацию по этой теме можно найти на веб-сайтах Mozilla и Chrome.
В настоящее время большинство веб-сайтов имеют политику конфиденциальности, согласно которой веб-сайты должны указывать, какие данные они собирают и как их используют. Если на вашей работе имеется такая политика, убедитесь, что вы следуете ей. Если нет, возможно, ее необходимо установить. Есть над чем подумать.
Все собираемые, используемые или создаваемые приложением данные должны быть классифицированы и размечены, чтобы все участники проекта знали, как с ними работать. Используемая система классификации может отличаться в зависимости от того, в какой стране вы живете и где работаете (частная компания или государственное учреждение). За рекомендациями следует обратиться к специалистам по обеспечению конфиденциальности или безопасности.
Давайте рассмотрим несколько примеров того, зачем и как нужно классифицировать данные.
Боб работает в федеральном правительстве, имеющем свою систему классификации данных (рис. 2.2). В его обязанности входит работа с данными, которые являются государственной тайной, секретной и совершенно секретной информацией. Существует строгая система идентификации типа этих файлов и данных, которой Боб всегда следует. «Государственная тайна», «Секретно» и «Совершенно секретно» в Канаде (где живет Боб) означает, что в случае раскрытия данных может быть нанесен ущерб целой стране, а не конкретному лицу. На предыдущей должности Боб работал с данными, которые были гораздо менее чувствительными и классифицировались как общедоступные (их мог видеть любой человек), под защитой уровня «A» (могли причинить вред или смутить человека), под защитой уровня «B» (причиняли вред человеку или группе людей) и под защитой уровня «C» (могли привести к смерти или иному непоправимому ущербу для одного или нескольких людей).
Рис. 2.2. Классификация, используемая Бобом при работе с данными
Классифицируя (определяя уровень чувствительности) и размечая собираемые данные, Боб помогает всем членам команды понять, как правильно обращаться с этими данными. Работая с неразмеченными данными, люди могут совершить ошибку, что может привести к непреднамеренной утечке информации или незащищенности очень ценных или конфиденциальных данных. Многие системы баз данных (например, Microsoft SQL Server) позволяют добавлять к полям данных или таблицам уровни классификации. Если используемая вами программа не предоставляет такой возможности, вы сами можете разметить данные путем добавления дополнительного поля в таблицу (или нескольких, если данные имеют разные уровни чувствительности). Даже «несекретным» или «общедоступным» данным следует присвоить соответствующую метку.
Всегда следуйте правилам и положениям о классификации данных. Спросите о действующих в вашей организации правилах и нормах, если не знаете их. В случае их отсутствия можно следовать либо стандарту, разработанному правительством вашей страны, либо «Руководству по сопоставлению типов информации и информационных систем с категориями безопасности» от Национального института стандартов и технологий (NIST).
ПРИМЕЧАНИЕ. Хотя это не является обязательным требованием проекта, но должна существовать техническая документация, объясняющая, как работать со всеми уровнями конфиденциальных данных, а также готовый к использованию код или библиотеки для работы с данными. Лучше всего, если этот код или библиотека централизуют управление и обработку данных для получения одинаковых результатов.