JSON Security

Question

Есть ли у Pagemethods и Json угрозы безопасности? (Я не использую куки). Например, у меня есть метод страницы, и я отправляю идентификатор пользователя в качестве параметра, но я не хочу показывать его пользователю. Может ли пользователь получить идентификатор пользователя из метода страницы?

Answer 1

да, они могут (см. Идентификатор пользователя). Любое взаимодействие между сервером и клиентом может быть просмотрено пользователем. Взгляните на скрипача или пожарного, чтобы увидеть, что происходит. Вы можете обращаться с ним так же, как с любым обычным запросом get или post.

Я не знаю причин, почему бы не использовать его. Не зная какой-либо предыстории, я не могу дать однозначного ответа о том, выбрал бы я ее, но в целом нет причин не использовать ее, просто примените ту же защиту, которую вы использовали бы для получения и отправки HTTP-запросов, как при отправке в обычной форме. .

Answer 2

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

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

Answer 3

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

Как правило, вы никогда не доверяете клиенту конфиденциальные данные. Предположим, что они всегда могут манипулировать ответом.

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

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

Answer 4

Я скрываю параметр идентификатора пользователя в скрытом поле и просто обеспокоен тем, можно ли его изменить во время этого процесса. Спасибо всем за поддержку

Answer 5

JSON может использовать безопасность FormsAuthentication, как и страницы. Что я обычно делаю, если не хочу, чтобы конечный пользователь видел идентификатор, - это сохраняю это значение (или что-то, что я могу использовать для поиска этого значения) в User.Identity.Name.

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

Answer 6

JSON сам по себе не имеет защиты, это незашифрованный формат данных.