Почему DotNetNuke отключали проверку?
Кто-либо может пролить некоторый свет на то, почему DotNetNuke приезжает настроенный с проверкой запроса и отключенной проверкой события? Они оба выключены на web.config уровне для установки по умолчанию, которая, кажется, регрессивный подход. Есть ли какие-либо веские причины для этого и каково функциональное влияние на DotNetNuke, если они снова включены?
Очевидно, соответствующий контроль ввода должен происходить в коде так или иначе, но собственное поведение платформы.NET всегда является хорошей нейтрализацией.
Обновление: дальнейшие размышления на этом в Проверке Запроса, DotNetNuke и утопии дизайна
2 ответа
Оказывается, люди в DotNetNuke отключили это, чтобы упростить отправку HTML-контента с помощью элементов управления форматированным текстом. Отключение проверки запросов и событий предусмотрено намеренно.
Я бы предпочел, чтобы это было сделано на уровне страницы, где это необходимо. Глобальная проверка никоим образом не освобождает разработчика от проверки вводимых данных в каждой точке, где они были получены, но я по-прежнему считаю, что наличие этой функции является хорошей страховкой, а ее отключение создает риск. Мне было бы очень интересно узнать, сколько сайтов DNN имеют XSS-уязвимости в результате отсутствия глобальной проверки в сочетании с плохой практикой разработки.
Глобальная валидация всех вводимых данных - плохая практика. Как и большинство приложений, DotNetNuke работает с проверкой ввода по функциям.
Создание уязвимого кода сильно зависит от того, как используется пользовательский ввод. Например, SQL-инъекция и XSS опираются на совершенно разные управляющие символы. Инъекция SQL может быть вызвана нефильтрацией одного из трех символов '"\, в то время как большинство XSS вызвано нефильтрацией <>. SQL Injection также может быть вызвана не использованием управляющих символов, например, этот код уязвим для SQL Injection, потому что в нем нет кавычек вокруг id:
SqlCommand("SELECT username FROM users where id="+id)
Глобальная проверка ввода, такая как magic_quotes_gpc в PHP, также не сможет предотвратить этот тип атаки, и это одна из причин, почему она была удалена в PHP6.