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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

С aspdev.org :

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

Response.Cache.SetCacheability(HttpCacheability.NoCache)

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

Answer 4

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

Answer 5

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

Answer 6

Элементы

DannySmurf, крайне ненадежны, когда речь идет об управлении кэшированием, а в особенности Pragma - тем более. Ссылки .

Answer 7

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

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

<meta http-equiv="expires" content="0" />

Полагаю, это должно быть примерно так.

Answer 8

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

Answer 9

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

Книга от бурундука О'Рейли - это библия HTTP, и Книга Криса Шифлетта также хороша.

Answer 10

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