Целостность скрытых полей: Asp.NET MVC

Question

Мы использовали asp.net mvc для разработки.Иногда нам нужно поместить в форму некоторые скрытые поля, которые помещаются в модель привязкой модели (как и ожидалось).В настоящее время пользователи могут легко изменять форму, используя firebug или другие утилиты.Цель скрытого поля в основном состоит в том, чтобы предоставить некоторую информацию обратно на сервер как есть, и они не предназначены для изменения.

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

Answer 1

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

Answer 2

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

Это крупная дыра в безопасности на вашем сайте. Во всем, что вы делаете с веб-разработкой, независимо от того, насколько умным может быть чей-то код или насколько вы думаете, вы будете в порядке, пока пользователи ничего не делают, помните одно золотое правило: Никогда не доверяйте косвенно данным, полученным от клиент.

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

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

Answer 3

Одна потенциальная альтернатива - хранить эту статическую одноразовую информацию в TempData на сервере и не передавать ее клиенту, где она может быть подделана. Имейте в виду, что по умолчанию TempData использует Session и имеет собственные ограничения - но это может быть вариантом.