Разрешённый ответ увидел другой пользователь: как принять изоляцию общего кэша

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

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

Представим вымышленное приложение для согласования договоров. Сотрудник А открывает карточку, сервер проверяет полномочия и возвращает разрешённые сведения. Ради скорости между приложением и браузером работает общий кэш: он сохраняет готовый HTTP-ответ. Позже сотрудник Б открывает тот же адрес. Если промежуточный слой возвращает прежнее тело без необходимой проверки текущего получателя, правильное первое решение уже не помогает.

В этой ситуации ошибка может находиться вне обработчика карточки. Он действительно умеет отказать пользователю Б, но второй запрос до него не дошёл. Поэтому отчёт «права проверяются на сервере» неполон, пока не показано, что проверка находится на каждом реальном пути выдачи чувствительного содержимого. Это относится и к успешному повтору, и к обработке исключения при недоступном приложении.

Для руководителя ИБ вопрос звучит конкретно: какое доказательство позволяет разрешить повторное использование этого ответа? Ответ «проверили вход» относится к установлению личности. Ответ «разделили ключи» относится к поиску сохранённого варианта. А допуск требует выяснить, кому и при каких текущих условиях разрешено получить содержимое.

Дальше рассматривается учебная методика приёмки собственного приложения. В ней нет настоящих клиентов, персональных данных и результатов испытаний НТА. Все исходы примеров — ожидаемые условия проверки, которые ещё предстоит сопоставить с наблюдением в разрешённой среде. Ускорение и вероятность утечки здесь не рассчитываются.

Какой именно кэш мы принимаем

HTTP-кэш сохраняет ответы на запросы и при определённых условиях использует их повторно. Личный кэш обычно обслуживает одного пользователя, общий — нескольких. Это различие определено в RFC 9111. Важна функция слоя: отдельный сервер перед приложением вполне может быть общим кэшем, даже если команда называет его просто ускорителем.

Не следует смешивать его с прикладным сохранением объектов. Например, приложение может положить рассчитанную карточку в собственное хранилище и потом собрать из неё новый HTTP-ответ. Такое хранилище не обязано понимать HTTP-заголовки. Изменение Cache-Control на внешнем ответе не устанавливает правила чтения внутреннего объекта. Для него понадобится отдельная модель доступа, которой эта статья не занимается.

Третья сущность — повторное использование вычислений языковой модели. Сам факт такого повторения не говорит, что готовый ответ приложения доступен другому сотруднику. Поэтому сообщения об ошибках модельного кэша нельзя переносить на HTTP как описание того же механизма. У этих слоёв разные объекты, условия совпадения и точки проверки. Общим остаётся вопрос о границе раскрытия, но технические доказательства нужно собирать заново.

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

На первой встрече полезно попросить команду провести запрос по всей цепочке: браузер, внешний посредник, внутренний посредник, приложение. Для каждого звена выяснить, может ли оно ответить самостоятельно. Это архитектурное описание, а не доступ к рабочим данным: достаточно вымышленного адреса и класса содержимого. Уже здесь часто становится понятно, к какому именно решению относится будущая приёмка.

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

Здесь полезно разделить также содержимое и оболочку. Общая неизменная разметка приложения может подходить всем сотрудникам, а персонализированный ответ с данными — иметь другую политику. Из запрета общего хранения второго не следует запрет сохранять первую. Такое разделение позволяет обсуждать конкретную границу без требования отказаться от любого повторного использования. Но само разделение нужно проверить: оболочка не должна незаметно включать персонализированные сведения.

Право получателя и свежесть ответа

У сохранённого ответа есть возраст и правила использования. У пользователя есть полномочия. Это разные состояния. В учебном примере содержимое договора может вообще не измениться, пока сотрудника переводят в другое подразделение и отзывают право чтения. Прежнее тело остаётся содержательно актуальным, но его выдача этому сотруднику больше не соответствует принятой политике.

Отсюда следует ограниченная рекомендация НТА: не принимать срок хранения как доказательство отзыва доступа. Малый срок уменьшает продолжительность хранения в выбранной схеме, но не устанавливает, что произошло между изменением права и следующим запросом. Если условие организации требует прекращения выдачи сразу после подтверждённого отзыва, ожидание истечения копии не доказывает выполнение этого условия.

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

Обратное тоже важно. Проверка прав не доказывает актуальность содержимого. У сотрудника может сохраняться право на карточку, но в ней уже изменились условия договора. Поэтому в приёмке нужны оба свойства: допустимый получатель и допустимая версия представления. Подмена одного другим приводит к ложному успеху: либо свежие сведения получает лишний человек, либо разрешённый человек получает непригодные сведения.

Для российских организаций с персональными данными правовая граница связана с защитой от неправомерного и случайного доступа: об этом говорит статья 19 152-ФЗ в публикации Минтруда. Из закона не следует конкретный ключ или набор заголовков. Выбор инженерного способа и доказательство его работы остаются отдельной задачей; этот разбор не является правовым заключением о системе.

×

Учебная модель НТА: сохранённое тело не освобождает от проверки права текущего получателя. Основание — RFC 9111 и методика OWASP.

Что различают ключ и Vary

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

Vary задаёт поля запроса, по которым различаются варианты представления. RFC 9111, раздел 4.1 описывает сопоставление этих полей; это не проверка полномочий на договор. Если два запроса имеют одинаковое значение выбранного поля, протокольное совпадение само по себе не доказывает одинаковые права их отправителей.

Поэтому универсальное предложение «добавим Vary и закроем вопрос» нельзя принять без модели приложения. Нужно понять, какие значения влияют на состав ответа, откуда они берутся и кто подтверждает их достоверность. Например, одна роль может давать разную видимость карточек в двух организациях. Разделение только по названию роли тогда не описывает границу данных, даже если заголовок технически работает.

Есть и временная сторона. Постоянный идентификатор пользователя не меняется при отзыве роли. Значит, ключ, содержащий только этот идентификатор, способен продолжить указывать на прежний результат. Это логическое следствие учебной модели, а не утверждение о конкретном продукте. Для такого решения нужна дополнительная проверка прав или доказуемая связь изменения политики с прекращением выдачи.

Руководителю ИБ не обязательно самостоятельно проектировать строку ключа. Его предмет решения — достаточность признаков разделения. Команда должна объяснить, какие два запроса вправе получить одно содержимое и почему. Если объяснение сводится к одинаковому адресу или одинаковой роли без границ организации и объекта, доказательство пока не соответствует задаче.

Три режима хранения отвечают на разные вопросы

В неквалифицированной форме private запрещает сохранение ответа общим HTTP-кэшем, но допускает личный. no-store запрещает сохранение HTTP-кэшем; no-cache допускает хранение, однако требует успешной проверки перед повторным использованием. Эти различия установлены в RFC 9111, разделе 5.2. Речь здесь о формах без списка отдельных полей.

Выбор зависит от требования. Если задача — исключить общий слой для персонализированного ответа, private выражает именно эту границу, сохраняя возможность личного хранения. Если нельзя разрешать и личное HTTP-хранение, рассматривается no-store. Если хранение допустимо, но требуется обращение к источнику перед повторной выдачей, рассматривается no-cache вместе с корректной серверной проверкой.

Однако личный кэш не равен отдельному хранилищу каждой учётной записи приложения. Два сотрудника могут последовательно использовать один профиль браузера. Поэтому private не освобождает от проверки смены пользователя на таком рабочем месте. Важно различать «личный» в HTTP и «принадлежащий текущей прикладной сессии» в требованиях организации.

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

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

Почему Authorization и настройки посредника требуют отдельной проверки

Наличие Authorization часто воспринимают как автоматический запрет общего кэширования. Но RFC 9111, раздел 3.5 предусматривает явно разрешающие директивы, включая public, s-maxage и must-revalidate. Поэтому факт передачи учётных данных ещё не доказывает, что ответ не будет повторно использован общим слоем. При cookie-сессии нельзя механически ссылаться на правило именно для Authorization.

Этот нюанс особенно важен при согласовании изменений. Команда может добавить директиву ради ускорения, считая её только настройкой времени. Руководителю ИБ нужен ответ, меняется ли при этом сама возможность общего повторного использования. Строка конфигурации должна оцениваться в контексте остальных директив и типа запроса, а не по своему названию.

В качестве доступного примера возьмём nginx. Его русская документация указывает, что proxy_cache по умолчанию выключен. Это не означает, что он выключен в установленной системе: значение может быть задано или унаследовано. Документация объясняет возможности, а подтверждение требует фактической конфигурации нужного маршрута и версии.

Там же различаются proxy_cache_bypass — условие не брать ответ из кэша — и proxy_no_cache — условие не сохранять ответ. Это два направления. Запрет новой записи не является доказательством отсутствия чтения из старой копии. А обход чтения на одном запросе сам по себе не определяет, что произойдёт с полученным новым ответом.

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

Отзыв права меняет условие выдачи

Рассмотрим три альтернативы как варианты проектного решения. Первая — не использовать общий HTTP-кэш для чувствительного ответа. Тогда каждый сетевой запрос идёт по пути, где приложение должно проверить доступ. Цена — отказ от соответствующего повторного использования, а не заранее известное замедление: его величину без измерения назвать нельзя.

Вторая альтернатива — сохранить тело, но перед выдачей проверять актуальное право текущего получателя. Механизм разделяет дорогую подготовку представления и решение о доступе. Он подходит только там, где проверка действительно предшествует выдаче во всех состояниях. Если при недоступности службы прав посредник возвращает прежнее тело, условие «проверяем каждый раз» не выполнено.

Третья — связать варианты ответа с действующей версией политики и доказуемо прекращать использование прежних вариантов при изменении прав. Это ограниченная архитектурная интерпретация НТА, а не готовая функция HTTP. Она требует показать источник версии, порядок распространения изменения, обработку старой копии и поведение при сбое. Одна запись номера версии в ключе этих свойств не доказывает.

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

Уже переданное разрешённому пользователю содержимое нельзя «забрать назад» изменением кэша. Поэтому проверка отзыва относится к последующим выдачам и отдельно оговорённому поведению приложения, а не к физическому уничтожению всех пользовательских копий. Эта граница защищает и от завышенного обещания безопасности, и от ошибочного критерия, который невозможно выполнить одним HTTP-механизмом.

Условный запрос тоже проходит проверку доступа

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

RFC 9110, раздел 13.2.1 устанавливает порядок: условия запроса оцениваются после обычных проверок. Прикладной вывод — обработчик не должен сообщать «не изменилось» в обход необходимого отказа по текущим правам. Это вывод о порядке контроля, а не требование единственного кода отказа для всех приложений.

В учебной проверке сначала получаем разрешённую копию для А и сохраняем сведения, необходимые для обычного условного чтения. Затем отзываем право и повторяем запрос штатным способом. Ожидаемый результат определяется политикой приложения: чувствительное содержимое не должно снова становиться доступным через разрешение использовать старое представление.

При этом одного сетевого наблюдения недостаточно для вывода о пользовательском результате. Браузер или приложение может уже показывать старую страницу без нового обращения. Поэтому в протоколе различают последующий сетевой ответ, восстановление открытого экрана и поведение при смене учётной записи. Это разные пути, и каждый проверяют в пределах заранее названного требования.

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

Учебная проверка с двумя получателями

Проверку проводят только на собственном разрешённом стенде. Подготавливают вымышленную карточку с заметным безвредным маркером, например «Учебная карточка К-17», и два аккаунта: А вправе читать её, Б не вправе. Маркер нужен для различения содержимого, а не для моделирования настоящих персональных данных. Реальные договоры и учётные секреты в протокол не включают.

Сначала устанавливают исходную истину без влияния общего сохранённого ответа: А получает учебное содержимое, Б — предусмотренный отказ или разрешённое ограниченное представление. Если это условие не выполнено, проверка уже обнаружила проблему прикладного доступа. Объяснять её кэшем преждевременно: сначала нужно различить исходный отказ и ошибку повторного использования.

Затем А обычным путём получает ответ через исследуемый слой. Команда подтверждает, был ли он действительно сохранён и откуда пришёл следующий ответ. Один короткий отклик или код 200 этого не доказывает. Нужен наблюдаемый признак самого слоя, согласованный с владельцем системы: например, его диагностическое состояние и соответствующая запись без содержимого карточки.

После этого Б обращается к тому же ресурсу. Важен состав ответа: нет ли маркера, полей или производного представления, которых ему быть не должно. Проверяют и обратную последовательность, когда первым идёт отказ Б, а затем разрешённое чтение А. Иначе методика может пропустить ошибочное повторное использование отказа и объявить успешной систему, которая просто перестала показывать данные всем.

Наконец, у А отзывают право и повторяют чтение при прежнем адресе и действующей по условиям опыта сессии. Дополнительно проверяют штатный условный запрос и предусмотренное состояние отказа зависимостей. Фактические результаты заносят рядом с ожидаемыми. Очистка всего браузера перед каждым повтором здесь мешает: она способна убрать именно ту прежнюю копию, влияние которой требуется обнаружить.

×

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

Что такой опыт доказывает и чего не доказывает

Исследование Web Cache Deception Escalates! на USENIX Security 2022 подтверждает, что ошибочное сохранение чувствительного содержимого — наблюдавшийся класс проблем. Но его внешняя историческая выборка не показывает вероятность дефекта российского корпоративного приложения. Из неё нельзя вывести процент риска для вашей системы или наличие ошибки в nginx как продукте.

Наш учебный опыт решает другую задачу: проверяет определённые переходы на выбранном маршруте. Он не охватывает автоматически печатную форму, выгрузку, соседний адрес, другой способ входа или дополнительный промежуточный слой. Два аккаунта — минимальная модель различения, а не универсальное доказательство всех возможных отношений между организациями, ролями и объектами.

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

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

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

Особенно аккуратно следует интерпретировать время. Если повтор выполнили уже после истечения сохранённого ответа, положительный исход может показать только правильную работу обычного приложения. Он ничего не говорит о выдаче ещё действующей копии. Поэтому в протоколе отмечают порядок событий: получение разрешённого ответа, подтверждение состояния слоя, изменение получателя или права, повторное чтение. Точные интервалы выбирают под условия стенда; универсальное число секунд в статье было бы вымыслом.

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

Матрица допуска общего кэша

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

Матрица не должна оставаться перечнем пожеланий. Для каждой строки полезно указать, кто подтвердит наблюдение: разработчик объяснит путь, эксплуатация — поведение посредника, владелец данных — допустимый состав, ИБ — соответствие условию раскрытия. Подпись одной команды не заменяет сведений, которыми располагает другая.

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

Если доказательства разделения или отзыва нет, результат методики — отказ в допуске общего кэша этого чувствительного ответа. Это не запрет ускорения приложения вообще. Можно выбрать повторное вычисление, личное хранение при подходящих условиях или другую архитектуру и проверить её собственные границы. Нельзя только подменить непроверенное условие удобным предположением о безопасности.

Где здесь DataSafe и работа НТА

Защищённое поле и сохранённый HTTP-ответ находятся на разных границах. Коннектор DataSafe для BPMSoft работает с правилами защиты, защищёнными полями и разрешённым раскрытием в приложении. Из этого не следует, что он управляет общим HTTP-кэшем или исправляет правила внешнего посредника.

Если разрешённое раскрытое значение уже вошло в тело ответа, последующие копии нужно обследовать в соответствующем приложении и пути доставки. DataSafe не следует представлять как универсальное средство исправления этой цепочки. Полезный предмет проектной работы — связать правила раскрытия с фактическими местами сохранения и приёмочными сценариями.

Отдельно остаётся браузерная граница CORS. Материал НТА о политике CORS отвечает, какой источник может читать ответ в браузере. Эта статья отвечает, как сохранённое представление получает текущий пользователь. Наличие правильной политики на одной границе не доказывает другую, хотя обе должны соответствовать одному назначению маршрута.

Для обсуждения с командой НТА достаточно принести обезличенную схему одного ответа и заполненную матрицу. Не нужны выгрузка рабочих договоров и секреты доступа. Нужны понятные условия: кто читает, что сохраняется, кто отзывает право и каким наблюдением подтверждается прекращение выдачи.

Тест понедельником

Возьмите один разрешённый учебный маршрут и заранее запишите три результата: что должен видеть А, чего не должен видеть Б и что перестанет получать А после отзыва права. Попросите команду показать полный повторный путь, включая случай найденной копии. Затем сравните состав ответа, а не только скорость и успешный код.

Если для объяснения требуется каждый раз очистить всё сохранённое, повторную выдачу вы ещё не проверили. Если разные ключи показаны, а переход после отзыва отсутствует, проверена только часть условия. Если отказ зависимости автоматически возвращает старое чувствительное тело, его нужно оценить относительно принятого требования, а не назвать удобством работы.

Результат понедельника — одна заполненная матрица с наблюдениями и решением по конкретному ответу. Технология выдерживает рабочий день, когда следующий получатель получает своё разрешённое представление, а прежнее разрешение не переживает согласованную границу отзыва незаметно для владельца данных.

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.