Есть ли способ предотвратить рендеринг страницы после того, как пользователь вышел из системы, но нажал кнопку “назад”?
https://stackoverflow.com/questions/64059
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
У меня есть какой-то веб-сайт, который требует входа в систему и показывает конфиденциальную информацию.
Пользователь переходит на страницу, ему предлагается войти в систему, затем он получает доступ к информации.
Пользователь выходит из системы с сайта и перенаправляется обратно на страницу входа в систему.
Затем пользователь может нажать "назад" и сразу вернуться на страницу, где содержится конфиденциальная информация.Поскольку браузер просто воспринимает это как отрисованный HTML, он показывает это им без проблем.
Есть ли способ предотвратить отображение этой информации, когда пользователь нажимает кнопку "Назад" на экране выхода из системы?Я не пытаюсь отключить саму кнопку "Назад", я просто пытаюсь предотвратить повторное отображение конфиденциальной информации, потому что пользователь больше не зарегистрирован на сайте.
Ради аргументации, приведенный выше сайт / сценарий находится в ASP.NET с проверкой подлинности в формах (поэтому, когда пользователь переходит на первую страницу, которая является нужной ему страницей, он перенаправляется на страницу входа в систему - на случай, если это имеет значение).
Решение
Короткий ответ заключается в том, что это не может быть сделано безопасно.
Однако существует множество хитростей, которые могут быть реализованы, чтобы затруднить пользователям нанесение ответного удара и отображение конфиденциальных данных.
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(Now.AddSeconds(-1));
Response.Cache.SetNoStore();
Response.AppendHeader("Pragma", "no-cache");
Это отключит кэширование на стороне клиента, однако это поддерживается не всеми браузерами.
Если у вас есть возможность использовать AJAX, то конфиденциальные данные могут быть получены с помощью updatepanel, которая обновляется из клиентского кода, и поэтому она не будет отображаться при повторном нажатии, если клиент все еще не вошел в систему.
Другие советы
Кэш и история не зависят друг от друга и никто не должен влиять друг на друга.
Единственное исключение сделано для банков является ли эта комбинация 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-апплет или flash-приложение, с помощью которого выполнялась аутентификация, вы могли бы сделать так, чтобы им приходилось проходить аутентификацию в, э-э, "реальном времени" на сервере каждый раз, когда они хотели просмотреть информацию.
Используя это, вы также можете зашифровать любую информацию.
Всегда есть вероятность, что кто-то может просто сохранить страницу с конфиденциальной информацией, отсутствие кэша не поможет обойти эту ситуацию (но тогда всегда можно сделать скриншот приложения flash или java).
Для полноты картины:
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
Response.Cache.SetExpires(DateTime.Now.AddMinutes(-1));
Правильный ответ предполагает использование установки заголовка HTTP Cache-Control в ответе.Если вы хотите убедиться, что они никогда кэшируйте выходные данные, вы можете выполнить Cache-Control:нет кэша.Это также часто используется при координации с no-store.
Другие параметры, если вы хотите ограничить кэширование, включают установку времени истечения срока действия и обязательную повторную проверку, но потенциально все это может привести к повторному отображению кэшированной страницы.
Видишь http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
Что ж, в крупной бразильской банковской корпорации (Banco do Brasil), известной тем, что у нее одно из самых безопасных и эффективных в мире программ для домашнего банковского обслуживания, они просто помещают history.go(1) на каждую страницу.Итак, если вы нажмете кнопку "Назад", вас вернут.Просто.
Пожалуйста, ознакомьтесь с заголовками HTTP-ответа.Большая часть ASP-кода, который публикуют люди, похоже, устанавливает их.Будь уверен.
Тот Самый книга о бурундуке от О'Рейли это библия HTTP, и HTTP-книга Криса Шифлетта это тоже хорошо.
Вы можете вернуть веб-страницу с конфиденциальным файлом в виде HTTP-сообщения, тогда в большинстве случаев браузеры выдадут вам сообщение с запросом, хотите ли вы повторно отправить данные.(К сожалению, я не могу найти канонический источник для такого поведения.)
Я просто имел в виду банковский пример.
На странице моего банка есть вот это:
<meta http-equiv="expires" content="0" />
Полагаю, речь должна идти примерно об этом.
