Где «правильное» место, чтобы проверить, не была ли подделана строка запроса?

Question

Я хочу добавить Querystring «проверка» и ведение журнала в случае любых «подделанных» строк запроса. Является ли событие Page_Init на данной странице подходящим местом для этого в жизненном цикле страницы ASP.Net?

Answer 1

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

Вопрос здесь: «Что вы считаете фальсификацией?» Неверные ключи? Неверные значения? Попытки закодировать теги, которые, возможно, могут быть записаны на результирующую страницу как часть атаки XSS?

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

РЕДАКТИРОВАТЬ : чтобы получить доступ к событиям приложения, добавьте Global Application Class в свой проект с помощью опции «Добавить новый элемент».

Каждый запрос запускает жизненный цикл приложения , и жизненный цикл страницы - это просто подпроцесс внутри этого процесса, когда обработчик запроса оказывается файлом aspx.

EDIT2 : Очистка данных строки запроса полностью зависит от того, для чего вы используете эти данные. Некоторые потенциально опасные варианты использования данных строки запроса включают:

• Значения для команды SQL : внедрение SQL может быть значительно смягчено с помощью «параметризованных запросов».
• Расположение файлов : Это может быть использовано для того, чтобы сервер выкашлял любой файл на жестком диске, если разрешения NTFS на сервере слабые.
• Значения, записанные в ответе HTML : Пользователь может кодировать тег и выполнять некоторый JavaScript. Обязательно используйте Server.Encode () или очистите строку вручную.

• значения идентификатора : если вы используете строку запроса для хранения значений идентификатора, пользователь может заменить их другими при попытке доступа к информации о вещах, которые он не должен видеть, например из которых может быть:

  http://domain.com/somepage.aspx?userid=1343243

Пользователь делает обоснованное предположение и изменяет его на:

http://domain.com/somepage.aspx?userid=0

И это может вызвать администратора.

Answer 2

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

http://geekswithblogs.net/casualjim/articles/64639.aspx

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

Дайте мне знать, если вам требуется дополнительная информация по какому-либо конкретному вопросу.

Ура !!!