Параметры Строки запроса делают мое приложение в опасности?
Я пишу Asp. Сетевое приложение WebForms, где я называю редактирование, разбивает на страницы передачу в данных о записи, которая будет отредактирована с помощью параметров строки запроса в URL.
Как:
http://myapp.path/QuoteItemEdit.aspx?PK=1234&DeviceType=12&Mode=Edit
На предыдущей странице в приложении я подарил пользователю GridView экранированных объектов, которые он может отредактировать на основе своих полномочий учетной записи, и я называю страницу редактирования с ними выше списка параметров, и страница знает, что сделать. Я НЕ делаю никакой дополнительной проверки на целевой странице, чтобы проверить, есть ли у пользователя доступ к переданному в значении записи PK, когда я запланировал полагаться на предыдущую страницу для отфильтровывания списка, и я буду в порядке.
Однако ясно, что пользователь может теперь ввести в URL к другому PK и заставить доступ редактировать ту запись. (Или, у него могут быть доступ к Mode=View, но не Mode=Edit или Mode=Delete. В основном я надеялся постараться не проверять рекордные и права доступа на целевой странице.
Я также протестировал тот же рабочий процесс с помощью Переменных сеанса для хранения PK, DeviceType и Режима прежде, чем назвать целевую страницу и затем считать их из Сессии на целевой странице. Таким образом, нет никаких вовлеченных параматерей строки запроса. Это взяло бы на себя управление далеко от пользователя.
Так, я ищу обратную связь на этих двух подходах так, чтобы я выбрал принятый/стандарт способ иметь дело с этим, поскольку она походит на шаблон разработки очень распространенного приложения для Приложений типа CRUD.
7 ответов
Я считаю, что общая практика заключается в том, чтобы сделать то, что вы избегаете: на исходной странице вам необходимо проверить, что пользователь должен иметь возможности для выполнения, и отображать их параметры соответствующим образом. Затем на реальной рабочей странице вам нужно снова проверить пользователь, чтобы убедиться, что им разрешено быть там, с доступом к этой конкретной задаче.
С точки зрения использования возможности использования, это то, что пользователь захочет (держит его просто, позволяет их добавить в закладки определенных страниц и т. Д.), И безопасность на обеих страницах является единственным способом для этого.
Вы должны всегда подтвердить до реального выполнения действия, особенно если передавать параметры по строке запроса. Для второй страницы, которая делает выполнение, которое вам может не понадобиться так много обратной связи для пользователя, так как вам не приятно, чтобы пользователю не приятно, если он пытается Cirmvent вашу безопасность, поэтому обработка ошибок должна быть намного проще.
Передача переменных на сеанс приемлема , но IMHO Вы все равно должны подтвердить значения.
Мы всегда используем вопросы, поэтому записи могут быть легко добавлены в закладки, однако всегда подтверждают в обоих местах, если вы пишете вам код контроля доступа к тому, что он должен просто быть случайным -Угибающий код ...
Переменные сеанса могут быть также манипулируются, хотя и не так легко. Какая бы аутентификация вы использовали на протяжении всего вашего сайта, вы должны обязательно использовать на вашей целевой странице. В противном случае вы будете открыты для разоблачения данных, которые вы не хотите, как вы узнали.
Договорились, вы захотите проверить разрешения на целевой странице, это единственный способ быть абсолютно уверенным. Когда дело доходит до безопасности, избыточность не плохая вещь. Закрепите свою базу данных, как если бы вы не доверяете бизнес-уровне, закрепите свой бизнес-уровень, как если бы вы не доверяете пользовательскому пользовательскому пользовательскому устройству и закрепите и закрепите пользовательский интерфейс.
Если вы действительно не хотите проверять права доступа на целевой странице:
Вы можете хэшировать PK с идентификатором пользователя, а затем добавить хэш-значение к строке запроса.
string hash = hashFunction(PK.toString() + UserID.toString());
Тогда вы должны убедиться, что хэш в запросеString равен хэш-значению, вычисленному перед загрузкой страницы.
Предположим, что это веб-приложение внутренней организации.
Вы можете сделать следующее, чтобы сделать ваши URL немного более безопасными:
-Использование руководств для первичных ключей, чтобы пользователи не могли угадать другие идентификаторы записей
-Режимные купоны будут имплицитными: Guid = редактировать, нет Guid = новый
и...
- Проверка на стороне сервера - это единственный путь.