Ist es akzeptabel, UnsafeHeaderParsing standardmäßig zu aktivieren?

Question

Das ist eine etwas subjektive Frage, aber ich würde gerne die Vor-/Nachteile dafür hören. Ich verwalte ein Open-Source-Projekt namens Quick and Dirty Feed Parser und das Ziel des Projekts ist es, es so nahtlos wie möglich zu machen, RSS- und Atom-Feeds in .NET zu konsumieren.

Eines der Probleme, die ich ziemlich früh in der Entwicklung des Projekts bekam, war, dass einige der Feeds, die ich als Testfälle verwendete (nämlich Hacker News RSS feed), falsch formatierte HTTP-Header und die HttpWebRequest-Klasse in .NET verwendeten 1.1 und höher löst sofort eine "unsafe header" Ausnahme aus, wenn Sie einen dieser Header in einer GET-Anfrage erhalten.

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.

Mein Problem ist also - ich kann die "UseUnsafeHeader" Konfigurationsoption programmgesteuert aktivieren, aber es tut es über alle HttpWebRequests im Kontext dieser Anwendung. Ich habe Nutzer, die sich darüber beschwert haben, dass der QD-Feed-Parser keine gültigen Feeds konsumieren kann, und dieses Header-Problem ist der Grund dafür.

Im Moment habe ich meine Bibliothek so eingerichtet, dass Entwickler, die es verwenden, unsafe Header-Parsing aktivieren müssen, obwohl die meisten von ihnen nicht wissen, dass dies das Problem ist, und es schafft einen Support-Overhead für mich .

Ich kann einfach Quick und Dirty Feed Parser aktivieren unsafe Header-Parsing standardmäßig und zwingen sicherheitsbewusste Benutzer, es zu deaktivieren, aber ich möchte nicht öffnen, Benutzer, die auch nicht besser zu Sicherheits-Angriffe wissen . Was ist die beste Option hier?

Answer 1

"Unsicher" ist ein bisschen extrem hier; Ich hätte diese Einstellung anders benannt. Das Problem tritt auf, wenn unangemessene Server Header ausgeben, die nicht exakt dem HTTP-RFC folgen. Zum Beispiel besagt der RFC, dass auf CR-Zeichen ein LF-Zeichen folgen muss. Wenn es kein LF gibt, erhalten Sie eine Ausnahme, es sei denn, Sie erlauben "unsichere" Header.

In der Praxis ignorieren viele HTTP-Clients diese geringfügigen Verletzungen, um mit so vielen Servern wie möglich zu kommunizieren. Deshalb beschwert sich Ihr Browser oder RSS-Reader nie über "unsichere" Header. Selbst wenn Header gefälscht sind, sind die .NET-Client-Bibliotheken robust genug, dass Sie beispielsweise Ihren Server nicht zum Absturz bringen, wenn ein böswilliger Angreifer einen Zeilenvorschub auslässt. :-) Es gibt hier also kein wirklich großes Sicherheitsproblem, es sei denn, Sie verwenden zum Beispiel dumme Dinge mit HTTP-Titelnamen, die Sie direkt in Ihren HTML-Code ausgeben (wodurch ein Angreifer möglicherweise einen XSS-Angriff in Ihren HTML-Code injizieren kann).

Solange also HTTP-Header so behandelt werden, als wären sie genauso wenig vertrauenswürdig wie andere von Benutzern gesendete Daten (wie Abfragezeichenfolgen, POST-Daten usw.), sollten Sie in Ordnung sein "Unsichere" Header in Ihrer App zulassen