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

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

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

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 и перенаправляет, когда установлен «убийственный» файл cookie, но я полагаю, что это может пойти не так, если браузер не устанавливает / не очищает файлы cookie точно так, как ожидалось.

Из aspdev.org:

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

Response.Cache.SetCacheability(HttpCacheability.NoCache)

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

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

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

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

Вам нужна директива без кеширования:

<META HTTP-EQUIV="PRAGMA" CONTENT="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-апплет или флэш-приложение, и аутентификация через него была выполнена, вы могли бы сделать так, чтобы им приходилось аутентифицироваться в, эм, «в реальном времени» с сервером каждый раз. они хотели просмотреть информацию.

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

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

Для полноты:

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

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

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

См. 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, тогда в большинстве случаев браузеры выдадут вам сообщение с вопросом, хотите ли вы повторно отправить данные. (К сожалению, я не могу найти канонический источник такого поведения.)

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

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

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

Я полагаю, это должно быть об этом.