Параметры строки запроса подвергают мое приложение риску?

Question

Я пишу приложение Asp.Net WebForms, где я называю страницу редактирования передачей данных о записи, подлежащей редактированию с использованием параметров строки запроса в URL.

Как:

http://myapp.path/QuoteItemEdit.aspx?PK=1234&DeviceType=12&Mode=Edit

На предыдущей странице приложения я предоставил пользователю GridView экранированных элементов, которые он может редактировать на основе привилегий своей учетной записи, и я вызываю страницу редактирования с указанным выше списком параметров, и страница знает, что делать , Я НЕ выполняю никаких дополнительных проверок на целевой странице, чтобы проверить, имеет ли пользователь доступ к переданному значению записи PK, как я планировал полагаться на предыдущую страницу, чтобы отфильтровать список, и все будет в порядке.

Однако очевидно, что теперь пользователь может ввести URL-адрес другого ПК и получить доступ к редактированию этой записи. (Или он может иметь доступ к Mode = View, но не Mode = Edit или Mode = Delete. По сути, я надеялся избежать проверки записи и прав доступа на целевой странице.

Я также протестировал тот же рабочий процесс, используя переменные Session для хранения PK, DeviceType и Mode перед вызовом целевой страницы и последующим чтением их из Session на целевой странице. Таким образом, здесь не задействованы параметры строки запроса. Это отнимает у пользователя контроль.

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

Answer 1

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

Answer 2

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

Answer 3

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

Передача переменных за сеанс приемлема , но imho, вы все равно должны проверять значения.

Answer 4

Если вы действительно не хотите проверять права доступа на целевой странице:

Вы можете хешировать PK с помощью UserID, а затем добавить значение хеша в строку запроса.

string hash = hashFunction(PK.toString() + UserID.toString());

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

Предполагается, что это веб-приложение внутренней организации.

Answer 5

Я считаю, что обычной практикой является делать то, чего вы избегаете: на исходной странице вам необходимо проверить, какие действия должен иметь пользователь, и правильно отобразить его параметры.Затем на реальной рабочей странице вам нужно еще раз проверить пользователя, чтобы убедиться, что ему разрешено находиться там, с доступом к этой конкретной задаче.

С точки зрения удобства использования, это то, что пользователь хотел бы (сохраняетэто просто, позволяет им создавать закладки для определенных страниц и т. д.), и безопасность на обеих страницах - единственный способ сделать это.

Answer 6

Чтобы сделать URL-адреса более безопасными, вы можете сделать следующее:

-Используйте направляющие для первичных ключей, чтобы пользователи не могли угадать другие идентификаторы записи

- Режим может быть неявным: Guid = Редактировать, нет Guid = Новый

и ..

- Проверка на стороне сервера - единственный путь.

Answer 7

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