Повысьте безопасность и конфиденциальность, обновив HTTP-кеш.

Если вы забудете или неправильно используете заголовок Cache-Control, это может негативно повлиять на безопасность вашего веб-сайта и конфиденциальность ваших пользователей.

Arthur Sonzogni

По умолчанию ресурсы всегда могут кэшироваться любым типом кеша. Неиспользование или неправильное использование заголовка Cache-Control может негативно повлиять на безопасность вашего веб-сайта и конфиденциальность ваших пользователей.

Для персонализированных ответов, которые вы хотите сохранить конфиденциальными, мы рекомендуем вам одно из следующих действий:

• Запретите посредникам кэшировать ресурс. Установите Cache-Control: private .
• Установите соответствующий вторичный ключ кэша . Если ответ меняется из-за файлов cookie (что может произойти, когда файлы cookie сохраняют учетные данные), установите Vary: Cookie .

Читайте дальше, чтобы узнать, почему это важно, и узнайте:

1. Проблемы безопасности и конфиденциальности, о которых вы могли не знать
2. Различные типы HTTP-кэшей и распространенные заблуждения
3. Рекомендуемые действия для ценных веб-сайтов

Риски безопасности и конфиденциальности, связанные с кэшем

Утечки ресурсов из-за уязвимостей Spectre

Уязвимость Spectre позволяет странице читать память процесса ОС. Это означает, что злоумышленник может получить несанкционированный доступ к данным перекрестного происхождения. Как следствие, современные веб-браузеры ограничили использование некоторых своих функций, таких как SharedArrayBuffer или таймер высокого разрешения , страницами с изоляцией между источниками .

Современные веб-браузеры применяют политику внедрения перекрестного происхождения (COEP) . Это гарантирует, что ресурсы из разных источников:

• Публичные ресурсы, запрошенные без файлов cookie
• Ресурсы явно разрешены для совместного использования из разных источников через CORS или заголовок CORP .

Настройка COEP не мешает злоумышленнику использовать Spectre. Тем не менее, это гарантирует, что ресурсы с перекрестным происхождением не будут ценны для злоумышленника (когда они загружены браузером как общедоступный ресурс) или не будут доступны злоумышленнику (при совместном использовании с CORP: cross-origin ).

Как HTTP-кеширование влияет на Spectre?

Если заголовок Cache-Control установлен неправильно, злоумышленник может провести атаку. Например:

1. Удостоверяемый ресурс кэшируется.
2. Злоумышленник загружает изолированную страницу с перекрестным происхождением.
3. Злоумышленник снова запрашивает ресурс.
4. COEP:credentialless устанавливается браузером , поэтому ресурс извлекается без файлов cookie. Однако вместо этого кэш может вернуть ответ с учетными данными.
5. Затем злоумышленник может прочитать персонализированный ресурс с помощью атаки Spectre.

Хотя HTTP-кеш веб-браузера на практике не допускает такого типа атаки, существуют дополнительные кеши вне непосредственного контроля браузера. Это может привести к успеху этой атаки.

Распространенные заблуждения о HTTP-кешах

1. Ресурсы кэшируются только браузером

Часто имеется несколько уровней кэша. Некоторые кэши предназначены для одного пользователя, некоторые — для нескольких пользователей. Некоторые из них контролируются сервером, некоторые — пользователем, а некоторые — посредниками.

• Кэш браузера . Эти кэши принадлежат одному пользователю и предназначены для него и реализованы в его веб-браузере. Они повышают производительность, избегая многократного получения одного и того же ответа.
• Локальный прокси . Он мог быть установлен пользователем, но им также могут управлять посредники: его компания, организация или интернет-провайдер. Локальные прокси часто кэшируют один ответ для нескольких пользователей, что представляет собой «общедоступный» кеш. Локальные прокси имеют несколько ролей.
• Кэш исходного сервера/CDN . Это контролируется сервером. Целью кэша исходного сервера является снижение нагрузки на исходный сервер путем кэширования одного и того же ответа для нескольких пользователей. Цели CDN аналогичны, но они распределены по всему миру и закреплены за ближайшим кругом пользователей, чтобы уменьшить задержку.

2. SSL не позволяет посредникам кэшировать ресурсы HTTPS.

Многие пользователи регулярно используют локально настроенные прокси-серверы, будь то для целей доступа (например, совместного использования лимитного соединения), проверки на вирусы или в целях предотвращения потери данных (DLP). Промежуточный кэш выполняет перехват TLS .

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

В конечном итоге некоторые ресурсы HTTPS могут кэшироваться этими локальными прокси-серверами.

Как работает HTTP-кеш

• Ресурсам неявно разрешается кэшировать по умолчанию.
• Первичный ключ кэша состоит из URL-адреса и метода. (URL, метод)
• Вторичный ключ кэша — это заголовки, включенные в заголовок Vary . Vary: Cookie указывает, что ответ зависит от Cookie .
• Заголовок Cache-Control обеспечивает более детальный контроль.

Выполните эти рекомендуемые действия для своего веб-сайта.

Разработчики ценных веб-сайтов, в том числе веб-сайтов с высоким трафиком и веб-сайтов, которые взаимодействуют с личной идентифицирующей информацией, должны действовать сейчас, чтобы повысить безопасность.

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

Мы рекомендуем вам предпринять один из следующих шагов:

• Запретите посредникам кэшировать ресурс. Установите Cache-Control: private .
• Установите соответствующий вторичный ключ кэша . Если ответ меняется из-за файлов cookie (что может произойти, когда файлы cookie сохраняют учетные данные), установите Vary: Cookie .

В частности, измените поведение по умолчанию: всегда определяйте Cache-Control или Vary .

Дополнительные соображения

Существуют и другие подобные типы атак с использованием HTTP-кэша, но они основаны на другом механизме, чем изоляция между источниками. Например, Джейк Арчибальд описывает некоторые атаки в книге «Как победить в CORS» .

Эти атаки смягчаются некоторыми веб-браузерами, которые разделяют свой HTTP-кеш в зависимости от того, был ли запрошен ответ ресурса с учетными данными или нет. По состоянию на 2022 год Firefox разделяет кеш, а Chrome и Safari — нет. Chrome может разделить кеш в будущем. Обратите внимание, что эти атаки отличаются и дополняют разделение по источникам верхнего уровня .

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

Фотография в заголовке сделана Беном Паттинсоном на Unsplash .