Хранение идентификатора модели в ASP.NET MVC ViewModel, Проблемы безопасности

Question

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

НаПредставление ChangeAccountDetails, которое я создал, я передаю ViewModel с данными, которые пользователь должен иметь возможность изменять в своей учетной записи.Я также сохраняю UserId в ViewModel, который отображается в скрытом поле на моем реальном представлении.У меня есть опасение, что это небезопасно по той причине, что при действии POST для сохранения измененных данных мой сервисный уровень загружает постоянную версию данных учетной записи пользователя, которые были только что изменены с помощью идентификатора пользователя, отправленного обратно во ViewModel.

Я использовал Fiddler для изменения запроса POST и изменил UserId на UserId другой записи пользователя в моей базе данных, это может иметь серьезные проблемы, поскольку кто-то может потенциально изменить чей-либо пароль и / или другие данные таким образом.

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

Answer 1

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

У меня есть модель пользователя (user), и эта модель заполняется дешифрованными данными из сеанса, это то, как я работаю с уровнем пользователя и т. Д.

моя незашифрованная строка выглядит следующим образом: userid || email || datetimelogin || users-GUID || Настоящее имя || userlevel

затем шифруется собственным секретным ключом 255.

Просто мысль, хорошая мысль, хотя я думаю, что для большинства довольно легко забыть, что люди могут возиться с удостоверением личности.

Идея, представленная выше zasz, также вполне справедлива, но тогда вам придется создать модель представления для учета дополнительного поля GUID и учета отсутствующего поля UserId.

Answer 2

Это распространенная проблема.Лучше всего решить, не отправляя UserID на стороне клиента.Поскольку вы не хотите использовать сеанс на стороне сервера и хотите защитить свое приложение от злокачественных пользователей, вам необходимо смоделировать сеанс с помощью таблицы базы данных.Поместите свой UserId и Random GUID в таблицу, когда пользователь входит в систему. Убедитесь, что в этой таблице есть только одна строка для любого заданного UserId (моя попытка упростить - когда пользователь входит в систему позже, снова обновите существующую строку с новым guid).

Теперь отправьте GUID клиенту как часть ViewModel.Когда обновленная электронная почта и т. Д. Возвращается с оригинальным guid, обратитесь к нашей таблице, чтобы преобразовать guid обратно в идентификатор пользователя.Обратите внимание, что это своего рода элементарный сеанс, и он защищен от несанкционированного доступа.Подделка GUID для поиска некоторых других пользователей Guid почти невозможен.

Как вы правильно понимаете, отправка идентификационных данных нашей БД для любой модели не только пользователю на стороне клиента, так как ввод скрытых полей - плохая идея, иКак только он проснется, каждый хакерский завтрак должен посмотреть на скрытые поля ввода и повозиться с ним.