XSSを防ぐための文字のブラックリストとホワイトリストの違い
OWASPおよびその他のセキュリティチャネルでのXSS防止について読んでいます。 ESAPIまたは同様のライブラリを使用し、ホワイトリストアプローチを介して入力フィルタリングを行う必要があると、彼らはみな言います。
ただし、私はデフォルトでエンコードするフレームワーク（Webobjects）を使用しているため、ESAPIを使用すると入力が変更されるため、選択肢がありません。
2番目のオプションは、ホワイトリストアプローチを使用することです。日本語、ロシア語、韓国語などの多くの言語をサポートしていますが、ホワイトリストに登録する文字をどのように決定しますか？
また、OWASPで言及されているように、ホワイトリストアプローチがブラックリストアプローチよりも優れているのはなぜですか？ XSSで使用される<、>などの文字をブロックしないのはなぜですか？
ブラックリストに登録する必要があるのは、一握りの文字のブロックだけではありません。セキュリティに関しては、この教義を踏襲しています。
「私たちが知っていることはわかっています。既知の未知数があります。つまり、現在私たちがわかっていないこともあります。しかし、未知の未知数もあります。わからないこともあります。知っています。」
ブラックリストは最初の2つのケースを防ぐのに役立ち、ホワイトリストは3つすべてをカバーするのに役立ちます:)
無害な文字のセットを識別して検証することは簡単ですが、既知のすべての不良を識別することは困難です。ほとんどのウイルス対策ソフトウェアはブラックリストアプローチ（シグネチャ）を採用していますが、既知の不良として知られていないため、0日間を捕捉できず、そのためのシグネチャがありませんでした。
また、OWASPで言及されているように、ホワイトリストアプローチがブラックリストアプローチよりも優れているのはなぜですか。 XSSで使用される<、>などの文字をブロックしないのはなぜですか
ブラックリストは静的な意味であり、「既知の不良」の発生を防ぎます。これの問題は、毎日新しい攻撃ベクトルが見つかり、安全のためにブラックリストを常に更新する必要があることです。一方、ホワイトリストは、必要なものだけにフィルターを作成できるため、より堅牢です。これで、OWASPがホワイトリストを提案する理由についての質問に答えることができます。
ESAPIをすぐに却下した可能性があります。 XSSを防ぐには、出力のエスケープを行うことをお勧めします。データをHTMLドキュメントに動的に挿入する場所では、データをエスケープします（その解析コンテキストに適した方法で）。 ESAPIはエスケープ用のライブラリを提供し、非常に便利です。これには「入力の変更」は含まれません。
詳細については、OWASPの XSS（クロスサイトスクリプティング）防止に関するチートシート 、および XSSを馬鹿に説明できますか？ 、および データベースの前にユーザー入力をフィルターするまたは表示時？ 、および 正規化および出力エンコーディング 。
入力フィルタリングを行う
必ず入力validation-ルールに基づいて入力を受け入れるか拒否します。入力データを変更しないでください。 Webサーバーとアプリケーション言語の間のインターフェースが、アプリケーション言語を危険にさらすコンテンツを許可している場合、非常にvery誤りがあります。確かに、この種のシナリオをアプリケーションコード内で処理することはできません。
アプリケーションの脆弱性は、通常、データがアプリケーション言語を離れた時点で発生します。XSSの場合、これは常に発生する場所です。これが、データに変換を適用するポイントです。変換は、データの移動先に適切である必要があります。データベースに書き込んでいるデータをエスケープする方法は、htmlに書き込むデータとは大きく異なります。