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

РЕДАКТИРОВАТЬ (для голосующего):

Q10. Безопасен ли ViewState по умолчанию? Можно ли его защитить? Как?

По умолчанию значение скрытого поля формы __VIEWSTATE кодируется Base64 и не шифруется. Следовательно, по умолчанию данные в ViewState не защищены.

Да, данные в ViewState могут быть защищены. Это можно сделать двумя способами. Первая - использовать SSL. Вторая - убедиться, что EnableViewStateMac имеет значение true. Это гарантирует, что ViewState будет зашифрован, а также будет проверен на несанкционированное вмешательство. По умолчанию используется алгоритм шифрования SHA1, но при желании его можно изменить на MD5 или 3DES. При этом следует помнить, что почти всегда существует компромисс между повышенной безопасностью и производительностью. Лучше избегать хранения конфиденциальных данных в ViewState и снижения производительности из-за необходимости повышения безопасности.

ссылка на страницу

Помните, что все, что содержится в ViewState, доставляется в браузер клиента (просто хранится в скрытом вводе) и передается туда-сюда от клиента к серверу. Шифрование и расшифровка данных может стать огромным системным накладным расходом.

Я бы сказал определенно нет. Если вам нужно хранить данные кредитной карты в нескольких HTTP-запросах, мне, возможно, придется переосмыслить вашу архитектуру.

Надеюсь, это поможет.

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

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

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

Я бы не рекомендовал это и действительно подумал бы над своим дизайном, если бы столкнулся с ним. Но если вы хотите это сделать: сохраните состояние просмотра на сервере.

Прочтите это: http://aspguy.wordpress.com/2008/07/09/reding-the-page-size-by-storing-viewstate-on-server/

Несколько пунктов

• MSDN : (Сеанс против ViewState) Хотя данные ViewState закодированы и могут быть дополнительно зашифрованы, ваши данные наиболее безопасны, если они никогда не отправляются клиенту. Таким образом, состояние сеанса - более безопасный вариант. (Хранение данных в базе данных еще более безопасно из-за дополнительных учетных данных. Вы можете добавить SSL для еще большей безопасности ссылок.) Но если вы отобразили , то ] личные данные в пользовательском интерфейсе, по-видимому, вы уже знакомы с безопасностью самой ссылки. В этом случае не менее безопасно помещать такое же значение в ViewState .

• ViewState отображается в исходном коде : Хотя информация о состоянии просмотра находится в свободном доступе в скрытом поле с именем __VIEWSTATE, она не является открытым текстом. По умолчанию машинно-зависимый код аутентификации рассчитывается на основе данных и добавляется к строке состояния просмотра. Результирующий текст затем кодируется только Base64 , но не шифруется. Однако, если требуется конфиденциальность данных, тогда SSL - единственное решение, поскольку он защищает не только состояние просмотра, но и все данные, которые перемещаются на страницу и со страницы. Состояние представления декодирования все еще возможно, но необходимо выполнить ряд шагов; Необходимо не только демонтировать несколько недокументированных и внутренних конструкций, но также должен возникнуть ряд обстоятельств. Кроме того, учтите, что состояние подделки просмотра обычно обнаруживается на сервере, и возникает исключение безопасности .Наконец, что наиболее важно, состояние просмотра содержит данные , а не код . Если вы явно не уменьшите параметры безопасности по умолчанию для страницы, хакер мало что сможет сделать, чтобы изменить состояние просмотра. Однако, если вы измените настройки безопасности по умолчанию, вы должны быть осторожны с состоянием просмотра. Хакер может изменить данные, представляющие состояние страницы. Это не ошибка как таковая и открывает дыры для атак только в том случае, если не соблюдаются основные правила проверки и проверки данных. Но, как вы понимаете, это более общая проблема, когда вы пытаетесь написать безопасный код. Внутренняя реализация состояния представления довольно сложна и достаточно многоуровневая, чтобы препятствовать атакам. Шифрование является наиболее важным элементом защиты информации о состоянии просмотра. Чтобы сделать состояние просмотра более безопасным, директива ASP.NET @Page поддерживает атрибут EnableViewStateMac, единственная цель которого - обнаруживать любую возможную попытку повреждения исходных данных.

• Если EnableViewStateMac имеет значение True, то, когда страница отправляет обратно, зашифрованное состояние просмотра алгоритмически проверяется, чтобы убедиться, что оно не было изменено на клиенте. В итоге вы можете прочитать содержимое состояния просмотра, но для его замены вам понадобится ключ шифрования, который находится в LSA веб-сервера.