Czy dopuszczalne jest domyślne włączenie funkcji UnsafeHeaderParsing?

Question

To jest nieco subiektywne pytanie, ale chciałbym usłyszeć o zaletach/wadach, aby to zrobić. Zarządzam projektem o otwartym kodzie źródłowym pod nazwą Quick and Dirty Feed Parser, a celem projektu jest uczynienie go tak bezproblemowym, jak to tylko możliwe, korzystaniem z kanałów RSS i Atom w .NET.

Jednym z problemów, które napotkałem dość wcześnie podczas opracowywania projektu, było to, że niektóre kanały, z których korzystałem jako przypadki testowe (a mianowicie Hacker News RSS feed), używały niepoprawnie sformatowanych nagłówków HTTP i klasy HttpWebRequest w .NET 1.1 i wyżej natychmiastowo zgłasza wyjątek "niebezpieczny nagłówek" za każdym razem, gdy otrzymasz jeden z tych nagłówków w żądaniu GET.

This change was added in order to put a stop to split-response attacks that were raising security issues at the time .NET 1.1 was released.

Mój problem polega na tym, że mogę programowo włączyć opcję konfiguracyjną "useUnsafeHeader", ale robi to na wszystkich HttpWebRequests w kontekście tej aplikacji. Mam użytkowników, którzy skarżyli się, że analizator paszy QD nie może pobierać poprawnych plików danych, a przyczyną problemu jest nagłówek.

W tej chwili mam swoją bibliotekę skonfigurowaną w taki sposób, że programiści, którzy jej używają, muszą sami włączyć przetwarzanie niebezpiecznych nagłówków, chociaż większość z nich nie jest świadoma, że ​​to jest problem i powoduje obciążenie dla mnie. .

Mogę po prostu mieć Quick and Dirty Feed Parser domyślnie włączać niebezpieczne przetwarzanie nagłówka i wymuszać na bezpiecznych użytkownikach wyłączanie go, ale nie chcę otwierać użytkowników, którzy nie znają się na atakach bezpieczeństwa. . Jaka jest najlepsza opcja?

Answer 1

"Niebezpieczny" jest tu nieco ekstremalny; Nazwałbym to ustawienie inaczej. Problem pojawia się, gdy źle zachowane serwery emitują nagłówki, które nie są zgodne ze specyfikacją HTTP RFC. Na przykład RFC mówi, że po znakach CR musi występować znak LF, więc jeśli nie ma LF, dostaniesz execption, chyba że zezwolisz na "niebezpieczne" nagłówki.

W praktyce wielu klientów HTTP ignoruje te drobne naruszenia, aby rozmawiać z jak największą liczbą serwerów. Dlatego Twoja przeglądarka lub czytnik RSS nigdy nie narzeka na "niebezpieczne" nagłówki. Nawet jeśli nagłówki są fałszywe, biblioteki klienta .NET są wystarczająco odporne, aby nie doprowadzić do awarii serwera, jeśli mizerny napastnik pominie wiersz. :-) Tak naprawdę nie ma tu dużego problemu z bezpieczeństwem, chyba że (na przykład) zrobisz głupie rzeczy z nazwami nagłówków HTTP, jak np. Wyślij je bezpośrednio do HTML (co może pozwolić atakującemu na wstrzyknięcie ataku XSS do twojego HTML).

Tak długo, jak traktujesz nagłówki HTTP tak, jakby były tak samo niegodne zaufania, jak inne dane przesłane przez użytkowników, które przychodzą do Twojej aplikacji (takie jak ciągi zapytań, dane POST itp.), Wtedy powinieneś być w porządku dopuszczanie "niebezpiecznych" nagłówków w Twojej aplikacji.