Поддерживает ли ASP.NET PostBack содержимое

Question

Хорошо, я все еще новичок во всем ASP.NET и как именно он отправляет обратно на свою страницу. Но мне было интересно, оставляет ли он след того, что в настоящее время находится на странице.

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

Хотя, если страница отправляется обратно сама себе, она раскрывает данные. Бессмысленно даже безопасно шифровать / передавать его куда-нибудь, если кто-то слушал или имеет доступ к журналам вашего браузера.

Так что, отправка обратно на страницу обеспечивает безопасность данных или открывает ее для быстрого доступа, как это делает строка запроса? А если нет, то есть ли какой-нибудь безопасный способ вернуться на сервер для скриптов?

Answer 1

ViewState

Использовать ViewStateEncryption . Вы можете установить это на уровне страницы:

<%@ Page Language="C#" ViewStateEncryptionMode="Always" %>

Вы также можете установить его на уровне сайта в web.config:

<system.web>
  <pages viewStateEncryptionMode="Always" />
</system.web>

Другие значения управления

Как отметил Эндрю Хэйр, это не распространяется на элементы управления, которые локально хранят свои значения .

Безопасность запросов и ответов

Помните, что вам нужно защищать контент обоими способами - и с сервера. SSL поможет с обоими из них.

Больше фона здесь .

Answer 2

ASP.NET использует HTTP POST для отправки данных на сервер - для защиты любых данных зашифруйте отправку с помощью сертификата SSL и используйте HTTPS.

Кстати, это не уникально для ASP.NET - HTTP POST является стандартным способом отправки полезных данных через HTTP.

Answer 3

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

Первоначальная передача текстового поля / входного значения на сервер происходит через традиционные переменные GET или POST, передаваемые через HTTP-соединение, это не связано с функциональностью PostBack / Viewstate в ASP.NET. Если вы включаете шифрование PostBack, оно просто шифрует то, что сервер отправляет в браузер, чтобы пользователь не мог прочитать или изменить эти переменные.

Вы можете попытаться зашифровать значение поля SSN в веб-браузере, написав функцию шифрования в Javascript, а затем отправив зашифрованный текст в скрытом поле на сервер, но вы должны передать algotihm и любой ключ шифрования в браузер, а это означает, что любой, кто слушает этот файл, может видеть открытый SSN, также может видеть код шифрования и, таким образом, отменять любые попытки шифрования SSN.

Лучшее решение - просто запустить ваш веб-сайт по протоколу SSL (https://),, что означает, что весь обмен данными между браузером и сервером зашифрован. Нет необходимости заново изобретать колесо шифрования.

Answer 4

Вам необходимо использовать SSL-сертификаты для защиты любых значений бланков. Также помните, что если взломан браузер, все взломано.

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

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

И, наконец, это применимо ко всем вещам, которые взаимодействуют через https и не относятся к ASP.NET

Answer 5

Вы можете зашифровать состояние просмотра с помощью AES. Если вы хотите стать действительно параноиком, поместите время первого запроса в состояние просмотра и откажитесь от использования состояния просмотра через x минут. Я забыл, что делает viewstate mac, но это еще одна хорошая вещь, которую вы можете включить.

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

Answer 6

Храните его как бизнес-объект, когда передача на сервер достаточно безопасна, а https является наиболее безопасным каналом.