デフォルトでUnsafeHeaderParsingを有効にすることは許容される方法ですか？

Question

これはやや主観的な質問ですが、私はこれを行うための長所/短所を聞きたいと思います。私はQuick and Dirty Feed Parserと呼ばれるオープンソースプロジェクトを管理しています。プロジェクトの目的は、.NETでRSSフィードとAtomフィードをできる限りシームレスに使用することです。

プロジェクトの開発の初期段階で問題が発生したのは、テストケースとして使用していたフィードの一部（つまりHacker News RSS feed）が不適切な形式のHTTPヘッダーを使用していて、.NETのHttpWebRequestクラス1.1以降では、GETリクエストでこれらのヘッダの1つを受け取ると、即座に「安全でないヘッダ」例外がスローされます。

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。

私の問題はこうしています - 私は "useUnsafeHeader"設定オプションをプログラムで有効にできますが、そのアプリケーションのコンテキスト内のすべてのHttpWebRequestsで行います。 QDフィードパーサーが有効なフィードを使用できないという苦情を受けたユーザーがおり、このヘッダーの問題が原因です。

今私は自分のライブラリを使用する開発者が安全でないヘッダー解析を有効にするようにライブラリを設定していますが、ほとんどの人がこれが問題であることを認識しておらず、 。

デフォルトでは、クイックフィードとダーティフィードパーサーで安全でないヘッダー解析が有効になり、セキュリティを重視するユーザーには無効にすることができますが、セキュリティ攻撃をよく知らないユーザー。ここで最高のオプションは何ですか？

Answer 1

「安全でない」というのはここで少し極端です。私はこの設定に違った名前を付けました。問題のあるサーバーがHTTP RFCに厳密に従わないヘッダーを送信すると、この問題が発生します。例えば、RFCでは、CR文字の後ろにLF文字が続く必要があるので、LFがない場合は、「安全でない」ヘッダーを許可しない限り、実行を停止します。

多くのHTTPクライアントは、できるだけ多くのサーバーと通信するために、これらのマイナーな違反を無視します。そのため、あなたのブラウザやRSSリーダーは、「安全でない」ヘッダーについて不平を言うことはありません。ヘッダーが偽であっても、.NETクライアントライブラリは頑強であり、悪意のある攻撃者が改行を省略した場合など、サーバーをクラッシュさせることはありません。 :-)実際には大きな安全上の問題はありません.HTMLヘッダー名を使って直接HTMLに送信する（攻撃者がHTMLにXSS攻撃を加える可能性があります）など、愚かなことを行わない限り。

HTTPヘッダーは、アプリケーションに提供される他のユーザーから送信されたデータ（クエリ文字列、POSTデータなど）と同じように扱われている限り、あなたのアプリで「安全でない」ヘッダーを許可します。