Предотвращение манипуляций с URL с помощью MVC?

Question

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

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

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

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

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

3. Выполните проверки в контроллере перед отображением страницы - означает, что вы везде надо делать код "админы" проверить операции.

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Вы не должны делать свои URL-адреса "защищенными от манипуляций", чтобы защитить базовую функциональность. Кроме того: большинство веб-сайтов делают URL-адреса более читабельными, например, /409742/predotvraschenie-manipulyatsii-s-url-s-pomoschy-mvc - запутывание будет шагом назад.

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

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

Answer 4

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

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