Есть ли способ удержать страницу от рендеринга, когда человек вышел из системы, но нажал кнопку «назад»?

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

Человек идет на страницу, ему предлагается войти в систему, а затем получает информацию.

Человек выходит из сайта и перенаправляется обратно на страницу входа в систему.

Затем человек может нажать «назад» и вернуться к странице, где содержится конфиденциальная информация. Поскольку браузер просто думает о нем как о визуализированном HTML, он не показывает им никаких проблем.

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

Для аргумента приведенный выше сайт / сценарий находится в ASP.NET с использованием аутентификации форм (поэтому, когда пользователь переходит на первую страницу, которая является той страницей, которую они хотят, они перенаправляются на страницу входа в систему – в случае, если это делает разница).

Короткий ответ заключается в том, что это невозможно сделать безопасно.

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

Response.Cache.SetCacheability(HttpCacheability.NoCache); Response.Cache.SetExpires(Now.AddSeconds(-1)); Response.Cache.SetNoStore(); Response.AppendHeader("Pragma", "no-cache"); 

Это отключит кеширование на стороне клиента, однако это не поддерживается всеми браузерами .

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

Кэш и история независимы и не должны влиять друг на друга.

Единственное исключение, сделанное для банков, заключается в том, что сочетание HTTPS и Cache-Control: must-revalidate обновить силу обновления при навигации по истории.

В обычном HTTP-интерфейсе нет способа сделать это, кроме как с помощью ошибок браузера.

Вы можете взломать его, используя Javascript, который проверяет document.cookie и перенаправляет, когда установлен куки-файл «killer», но я предполагаю, что это может серьезно ошибиться, когда браузер не устанавливает / очищает cookies точно так, как ожидалось.

От aspdev.org :

Добавьте следующую строку поверх обработчика событий Page_Load и ваша страница ASP.NET не будет кэшироваться в браузерах пользователей:

 Response.Cache.SetCacheability(HttpCacheability.NoCache) 

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

Элементы DannySmurf, чрезвычайно ненадежны, когда дело доходит до контроля кеширования, а Pragma, в частности, тем более. Ссылка .

dannyp и другие, no-cache не останавливает кэши от хранения чувствительных ресурсов. Это просто означает, что кеш не может обслуживать ресурс, который он сохранил, без повторной проверки его. Если вы хотите запретить кэширование чувствительных ресурсов, вам необходимо использовать директиву no-store.

У вас может быть функция javascript, которая выполняет быструю проверку сервера (ajax), и если пользователь не вошел в систему, удаляет текущую страницу и заменяет ее сообщением. Очевидно, это будет уязвимым для пользователя, у которого javascript отключен, но это довольно редко. С другой стороны, это как технология браузера, так и серверная технология (asp / php и т. Д.) Агностик.

Вы ищете директиву no-cache:

  

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

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

Операция выхода должна быть POST . Затем браузер предложит «Вы уверены, что хотите повторно разместить форму?» а не показывать страницу.

Я не знаю, как это сделать в ASP.NET, но в PHP я бы сделал что-то вроде:

 header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); header("Cache-Control: no-cache"); header("Pragma: no-cache"); 

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

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

Используя это, вы также можете зашифровать любую информацию.

Всегда есть вероятность, что кто-то может просто сохранить страницу с конфиденциальной информацией, не имея кеша, не обойдется вокруг этой ситуации (но тогда всегда можно сделать снимок экрана с помощью приложения flash или java).

Для полноты:

 Response.Cache.SetCacheability(HttpCacheability.NoCache); Response.Cache.SetNoStore(); Response.Cache.SetExpires(DateTime.Now.AddMinutes(-1)); 

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

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

См. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4.

Что ж, в крупной бразильской банковской корпорации (Banco do Brasil), которая известна тем, что имеет одно из самых безопасных и эффективных программ для домашнего банковского дела в мире, они просто ставят history.go (1) на каждую страницу. Итак, если вы нажмете кнопку «Назад», вы будете возвращены. Просто.

Посмотрите заголовки ответов HTTP. Большинство ASP-кода, которые публикуют люди, похоже, настраивают их. Быть уверенным.

Книга бурундука из O’Reilly – это библия HTTP, а HTTP-книга Криса Шифлетта тоже хороша.

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

Я просто имел в виду банковский пример.

На странице моего банка есть это:

  

Это должно быть примерно так.

  • Остановить jQuery .load от кеширования
  • Как удалить кэш других приложений из нашего приложения для Android?
  • Как реализовать мой собственный кэш диска с библиотекой picasso - Android?
  • Включение / выключение состояния сеанса для каждого controllerа / метода действий
  • Как очистить кеш процессора L1 и L2
  • Отключение кеширования браузеров для всех браузеров из ASP.NET
  • API с легким API-интерфейсом Java
  • Как использовать кеширование диска в Picasso?
  • Кэширование в asp.net-mvc
  • Как кэшировать данные в приложении MVC
  • Наблюдение за устаревшей инструкцией по x86 с самомодифицируемым кодом
  • Давайте будем гением компьютера.