Предотвращение атак с использованием MVC?

Question

Любые хорошие стратегии, фрагменты кода и т. Д. Для предотвращения манипуляций с URL-адресами?

Например, у меня есть этот url, http://localhost/profile/edit/5 id легко может быть изменен на все, и, таким образом, люди могут редактировать профили, которые они тоже не предполагают.

Вот несколько идей, я думал, но все они имеют там недостатки:

1. Поменяйте свою систему, чтобы использовать первичные ключи GUID - делает его практически невозможно угадать, ключи - но люди могут еще взять GUID из одной части приложения и позже использовать его в другом URL-адресе.

2. Использование TempData для хранения ключей - предотвращает отправку URL-адресов при использовании .

3. Выполнение проверок в контроллере перед отображением страницы - означает, что вы должны использовать код «adminy» всюду для проверки операций.

Что лучше всего делать? Одно из них или что-то еще?

Answer 1

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

Номер 1 является защитой от небезопасности, и если кто-то случайно размещает свой URL-адрес где-то (например, люди часто используют идентификаторы сеанса при копировании/вставке ссылок), ваша «безопасность» нарушена.

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

Answer 2

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

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

Answer 3

Вы не должны делать свои URL-адреса «защищенными от манипуляций» защитой базовых функций. Кроме того: большинство веб-сайтов делают URL более читабельными, например, http://stackoverflow.com/questions/741653/preventing-url-manipulation-attacks-with-mvc - обфускация будет шагом назад.

Скорее проверьте разрешения в своих контроллерах и поднимите исключение, если пользователю не разрешено редактировать профиль 6. Если вы не хотите, чтобы «проверки» были повсюду, возможно, вы могли бы поместить их в ActionFilter или создайте некоторый вспомогательный метод, например CurrentUser.FindProfileToEditById(profileId) (который генерирует исключение, если действие не разрешено) вместо Profile.FindById(id).

Если вы хотите получить общий сервис, в котором у вас нет «текущего пользователя», вы можете пойти с GUID (например, Doodle) - однако это всегда будет угрозой безопасности различными способами (Facebook имел это выпуск с их фотоальбомами).

Answer 4

Я использую настраиваемые фильтры авторизации для реализации контроля доступа на основе роли и владельца. Стандартный AuthorizationFilter позволит вам указать именованные роли или пользователей, которые могут иметь доступ к действию. Я расширил это, чтобы вы могли указать, что текущий пользователь может иметь доступ, если он является «владельцем» данных.У меня есть два дополнительных фильтра: RoleOrOwnerAuthorizationFilter и RoleOrOwnerAssociatedAuthorizationFilter. Первый проверяет, что настраиваемый параметр (обычно id), переданный в RouteData, является идентификатором текущего пользователя в моей таблице пользователей или если текущий пользователь находится в любой из перечисленных ролей. Если это так, то проверка завершается успешно, если нет, он возвращает вид ошибки авторизации.

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