ASP.NET MVC: убедитесь, что редактирование записи разрешено (владение) - PullRequest
4 голосов
/ 13 сентября 2009

У меня есть многопользовательское приложение ASP.NET MVC. Пользователи не должны видеть или делать что-либо с данными друг друга.

Одним из моих действий контроллера является обязательное POST для / редактирования для редактирования записи (например, контакта). Теперь вот моя проблема: что если кто-то подделает простой POST для / Edit (который автоматически привязывает модель к моему классу контактов) и отредактирует чужую информацию? Поскольку каждая запись идентифицируется по Id, все, что нужно сделать, - это создать поддельный POST с Id XXX, а затем запись # XXX будет перезаписана тем, что предоставил злоумышленник. Как я могу это остановить?

Единственное, о чем я подумал, это выборка исходного экземпляра каждый раз, когда сначала из БД, проверьте, что он действительно находится в области действия редактируемых объектов пользователя (тех, которые он обычно видит для редактирования). ) и только в том случае, если эта проверка прошла, чтобы продолжить работу с UpdateModel и зафиксировать изменения обновления.

Есть ли лучший способ?

Редактировать: Это не кросс-сайт / CSRF атака . Это может сделать другой зарегистрированный пользователь.

Ответы [ 4 ]

4 голосов
/ 14 сентября 2009

Авторизация для просмотра / страницы и авторизация для конкретного объекта - это на самом деле две разные концепции. Наилучшим подходом является проблема использования атрибута Authorize в сочетании с системой ролей ASP.NET для предоставления или запрета доступа к данной странице. После того как вы убедились, что у пользователя есть доступ к странице, вы можете проверить, имеет ли он разрешение, которое он запрашивает, для объекта, для которого он запрашивает его. Я использую этот подход в своем приложении, и он прекрасно работает. Сначала, используя фильтр Authorize, он значительно повышает производительность, поскольку проверка прав доступа к объекту является гораздо более тяжелой операцией.

Кроме того, я использую систему правил домашнего приготовления, чтобы фактически установить и определить, имеет ли пользователь доступ к объекту. Например, в моей системе администраторы имеют полный доступ к каждому объекту. (Это правило.) Пользователь, который создает объекты, имеет полный доступ к объекту (также указанному правилом). Кроме того, менеджер пользователя имеет полный доступ ко всем вещам, к которым имеют доступ его сотрудники (опять же, определяется правилом). Мое приложение затем оценивает объект, чтобы определить, применимо ли какое-либо из этих правил - сначала начнем с того, чтобы сначала не выполнить сложные правила, а затем перейти на более сложные правила в прошлом. Если какое-либо правило является положительным, я прекращаю оценку правила и выхожу из функции.

1 голос
/ 13 сентября 2009

Что вы можете сделать, это исключить идентификатор в привязке модели с помощью следующего синтаксиса:

 public ActionResult Edit([Bind(Exclude="Id")] User userToEdit)

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

0 голосов
/ 25 ноября 2009

Этот вопрос напомнил мне статью, в которой описана похожая проблема (в свете атак с использованием URL), которую я добавил в закладки. Они имеют дело с аутентифицированным пользователем, связывающимся с данными другого пользователя. Вы можете найти это полезным: текст ссылки

Редактировать: эта ссылка должна быть правильной: Предотвращение атак с помощью URL-адресов

0 голосов
/ 13 сентября 2009

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

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