Безопасность авторизации аутентификации Форм ASP.NET
Я использую аутентификацию Форм в ASP.NET веб-сайт MVC, и я храню имя для входа в систему учетной записи пользователя в AuthCookie как это:
FormsAuthentication.SetAuthCookie(account.Login, false);
Я хочу спросить, существует ли возможность, что пользователю на стороне клиента так или иначе удастся изменить его имя для входа в систему в AuthCookie, и таким образом он будет, например, исполнен роль как кто-то с более высокими полномочиями и разрешен сделать больше действий, чем он, как обычно предполагается, имеет. Также лучше сохранить на это имя для входа в систему учетной записи пользователя cookie или Идентификационный номер учетной записи пользователя?
3 ответа
Файлы cookie зашифрованы, поэтому шансы на это весьма невелики. Но все равно.
Подход с использованием нескольких свойств
Если вы хотите усилить безопасность, вы можете сохранить имя пользователя, а также идентификатор пользователя или некоторые другие данные, которые невозможно угадать по имени пользователя. Их комбинация делает его более безопасным, потому что, если вы можете угадать одно, сложнее угадать другие и использовать правильную их комбинацию. Т.е. Если вы угадываете адрес электронной почты / имя пользователя другого пользователя, то будет немного сложнее угадать идентификатор того же пользователя, потому что они не связаны между собой. Таким образом, чем больше несвязанных свойств вы объедините, тем больше шагов потребуется для получения правильной комбинации.
Подход с использованием маркера безопасности входа
Вы можете использовать альтернативный подход, описанный в этом сценарии:
- Пользователь входит в систему.
- Сгенерировать случайный маркер входа в систему, который может иметь произвольную длину с определенной минимальной длиной и сохранить это против пользователя в хранилище данных. Вероятно, это не проблема, хотя довольно часто при входе в систему сохраняются другие данные, такие как информация
LastLogonDate. - Используйте этот токен и сохраните его в cookie вместо имен пользователей или другой информации.
- Если пользователь выходит из системы, очистить токен безопасности входа в систему из хранилища данных
- Пользователь снова входит в систему ... вернитесь к 1 и снова создайте новый токен и используйте его в этом сеансе.
Таким образом, это сделает его более безопасным в долгосрочной перспективе, потому что эта информация будет меняться при каждом входе в систему, и если пользователь вручную выходит из системы, вы всегда можете удалить этот токен из хранилища, поэтому вводить его будет невозможно. чужая личность. Это действительно усложняет использование постоянных файлов cookie, но это все еще можно сделать.
Этот подход не является пуленепробиваемым, но он обеспечивает дополнительный уровень безопасности, который предотвращает одну и ту же атаку снова и снова, когда одна учетная запись была взломана. А также, когда одна учетная запись скомпрометирована, это не значит, что другие тоже могут быть скомпрометированы. Если ваши токены безопасности достаточно длинные, будет намного сложнее начать атаку грубой силы на вашем сайте, и, пока этот вид атаки будет выполняться, токены безопасности будут меняться, поэтому это определенно безопаснее.
Нет, это невозможно (ну, теоретически возможно, но на практике это невозможно). Значение файла cookie аутентификации зашифровано, поэтому пользователь не может его изменить. Рекомендуется сохранить (уникальное) имя входа в файл cookie аутентификации, поскольку при восстановлении объекта IIdentity ( HttpContext.Current.User ) переданное вами значение to SetAuthCookie используется для свойства Name объекта IIdentity . Свойство Name будет отображаться, если вы используете, например, LoginStatusControl , поэтому рекомендуется, чтобы значение свойства Name было понятным для пользователя. .
Файл cookie будет зашифрован и расшифрован на стороне сервера, поэтому, если пользователь не сможет взломать ключ шифрования, он не сможет этого сделать.
Пока информация, которую вы храните, однозначно идентифицирует вашего пользователя, выбор того, что это за информация, полностью зависит от требований конкретного приложения.