Безопасно ли хранить данные кредитной карты и информацию о ценах во ViewState даже через ssl? - PullRequest
5 голосов
/ 08 июля 2010

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

Это безопасно?

Ответы [ 6 ]

10 голосов
/ 08 июля 2010

Я бы не стал хранить конфиденциальную информацию в viewstate ... ever . Тем самым вы делегируете безопасность реализации браузера для защиты данных ваших клиентов.Уязвимости, такие как межсайтовый скриптинг (XSS), атаки с перенаправлением URL-адреса и т. Д., Могут подвергать эти конфиденциальные данные вторжению, краже или подделке.

Если вы храните такие данные в постбэках, следуетоцените свой дизайн - и найдите способ избежать этого.

2 голосов
/ 08 июля 2010

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

РЕДАКТИРОВАТЬ (для нижестоящего избирателя):

Q10.Является ли ViewState безопасным по умолчанию?Это может быть обеспечено?Как?

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

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

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

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

0 голосов
/ 08 июля 2010

Несколько баллов

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

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

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

0 голосов
/ 08 июля 2010

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

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

0 голосов
/ 08 июля 2010

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

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

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

0 голосов
/ 08 июля 2010

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

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

...