Это приемлемая практика, чтобы включить UnsafeHeaderParsing по умолчанию?

Question

Это довольно субъективный вопрос, но я бы хотел услышать плюсы / минусы за это.Я управляю проектом с открытым исходным кодом, который называется Quick and Dirty Feed Parser , и цель проекта - сделать его максимально удобным для использования каналов RSS и Atom в .NET.

Один изПроблемы, с которыми я столкнулся довольно рано при разработке проекта, заключались в том, что некоторые каналы, которые я использовал в качестве тестовых случаев (а именно RSS-канал Hacker News ), использовали неправильно отформатированные заголовки HTTP и класс HttpWebRequest.в .NET 1.1 и выше быстро генерирует исключение «небезопасный заголовок» всякий раз, когда вы получаете один из этих заголовков в запросе GET.

Это изменение было добавлено, чтобы положить конец атакам с разделенным ответомкоторые вызывали проблемы с безопасностью во время выпуска .NET 1.1 .

Моя проблема, таким образом, заключается в том, что я могу включить параметр конфигурации «useUnsafeHeader» программно, но он делает это через ВСЕ HttpWebRequests в контексте этого приложения,У меня есть пользователи, которые жаловались на то, что QD Feed Parser не может использовать действительные каналы, и именно поэтому возникает проблема с заголовком.

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

Я могу просто использовать Quick and Dirty Feed Parser, который по умолчанию разрешает небезопасный парсинг заголовка, и заставляет пользователей, защищенных с точки зрения безопасности, отключать его, но я не хочу открывать пользователей, которые не знают ничего лучше для безопасностиатаки тоже.Какой лучший вариант здесь?

Answer 1

«Небезопасно» здесь немного экстремально; Я бы назвал этот параметр по-другому. Проблема возникает, когда плохо ведущие себя серверы испускают заголовки, которые точно не следуют HTTP RFC. Например, RFC говорит, что за символами CR должен следовать символ LF, поэтому, если LF отсутствует, вы получите исключение, если не разрешите «небезопасные» заголовки.

На практике многие HTTP-клиенты игнорируют эти незначительные нарушения, чтобы общаться с как можно большим количеством серверов. Вот почему ваш браузер или читатель RSS никогда не жалуется на «небезопасные» заголовки. Даже если заголовки являются поддельными, клиентские библиотеки .NET достаточно надежны, чтобы, например, не повредить сервер, если злонамеренный злоумышленник пропустит перевод строки. :-) Таким образом, здесь нет большой проблемы с безопасностью, если (например) вы не делаете глупостей с именами заголовков HTTP, например, отправляете их прямо в ваш HTML (что может позволить злоумышленнику внедрить XSS-атаку в ваш HTML).

Итак, если вы обрабатываете HTTP-заголовки так, как будто они так же ненадежны, как и любые другие пользовательские данные, поступающие в ваше приложение (например, строки запроса, данные POST и т. Д.), То вы должны быть в порядке, позволяя «небезопасные» заголовки в вашем приложении.