Чувствительные данные в Viewstate?

Question

Мне нужно хранить конфиденциальные данные на нескольких страницах (через https) за сеанс.

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

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

1) Должен ли я зашифровать данные и сохранить их затем в Viewstate (хотя и не рекомендуется - sec & perf. Значения) ИЛИ ЖЕ 2) Должен ли я хранить данные в сериализуемом классе и хранить их в Viewstate? (не рекомендуется снова из-за перфектных последствий)

Любое мнение, пожалуйста?

Answer 1

Мне нужно хранить конфиденциальные данные через несколько страниц (через https) на сессия.

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

Возможно, вы можете хранить ваши конфиденциальные данные в cookie, но это сопряжено с некоторыми рисками безопасности.

Вы также можете хранить свои конфиденциальные данные в хранилище данных на стороне сервера (XML-файл, база данных и т. Д.) И хранить ключ к данным в файле cookie на стороне клиента. Чуть безопаснее.

Answer 2

Если вы используете 2.0, вы можете зашифровать состояние просмотра. Смотрите эту статью Channel9 . AES - достаточно хорошее шифрование для военных и федерального правительства США. Хотя DES может быть взломан за несколько часов, AES требуется 150 триллионов (с оборудованием 2001 года) лет, чтобы взломать AES. Даже с более быстрым и более распределенным оборудованием ваше представление не стоит ресурсов, необходимых злоумышленнику для его взлома. Если вы не думаете, что ключи машины как-то небезопасны, я не уверен, что представляет собой шифрование угроз безопасности.

Что касается производительности, состояние представления с конфиденциальными данными является компромиссом между хранением данных на стороне сервера ценных данных или использованием ценных циклов ЦП для шифрования данных (особенно в версии 2.0, где вы можете настроить « представление состояния на стороне сервера ») , Возможно, вы захотите собрать некоторые эмпирические данные с вашей рабочей нагрузкой и конкретным оборудованием, чтобы выяснить, каковы истинные компромиссы. Если еще не поздно спроектировать ваше приложение для хранения состояния в сеансе вместо viewstate, вы также можете рассмотреть SqlSessionStore, который является безопасным (на стороне сервера) и не использует много памяти на стороне сервера.

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

Answer 3

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

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

Было бы довольно просто поместить простой файл данных MS Access на сервер, или вы можете просто вставить XML или текстовые файлы и записать в них свои данные. Не намного больше, чем это, пойти в легкие реляционные магазины, такие как SQL Express, VistaDB или даже MySQL

Answer 4

Ну, общий ответ - не делай этого! Хотя viewstate является (может быть) зашифрованным, он не был предназначен для хранения конфиденциальных данных. Причина в том, что данные о состоянии представления могут быть получены третьей стороной и впоследствии расшифрованы.

Но это не значит, что вы не должны этого делать ... :-) Во-первых, ваше соединение через https, поэтому все, что вы передаете, уже зашифровано. Это означает, что сбор конфиденциальных данных будет очень сложным. Если третье лицо похитит ваши конфиденциальные данные, ему сначала придется расшифровать соединение, а затем расшифровать состояние просмотра. Поэтому злоумышленнику, вероятно, будет гораздо проще использовать другие подходы для получения ваших данных (например, обманывать пользователей, фишинг и т. Д.).

Так что для безопасности ваших данных я бы остановился на том, что их достаточно хранить в зашифрованном виде и использовать https.

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

Answer 5

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

Вы не можете контролировать пользовательскую среду, поэтому вы не можете контролировать то, что ДЕЙСТВИТЕЛЬНО будет иметь доступ к этой «конфиденциальной» информации.

Answer 6

Чувствительные данные не должны храниться во ViewState, поскольку их легко можно десериализовать.

Но вы также сказали, что страница запускается по https, поэтому вам нужно ответить на вопрос; К кому чувствительны данные? Пользователь, который получает доступ к странице? Тогда вам нужно зашифровать его.

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

Answer 7

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

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