OWASP では、特に HTML 属性をエンコードするために別のエンコード方法を使用することを推奨していることに気付きました。ASP.NET MVC には、特に属性をエンコードするためのヘルパー メソッドがあります。
ただし、HTML でエンコードされた文字列が HTML 属性のコンテキストで機能しないという状況は考えられませんでした。標準の HTML エンコーディングを使用すると不十分または正しくない場合はありますか? そうでない場合、これらの追加のメソッドが一部のフレームワークで提供されているのはなぜですか?
(すべての文字列エスケープ フレームワークがそのようなメソッドを提供しているわけではないことに注意してください。)
参照実装を詳しく調べると、メソッドは、エンコードする必要のない一連の免疫文字を使用してHTMLEntityCodecクラスのメソッドをencodeForHTMLAttribute呼び出します。Codec classから継承されたメソッド内で、免疫セットにない英数字以外の文字が文字参照によってエンコードされることがわかります。encodeencode
HTML と HTML 属性の免責セットが異なることに既に気付いたように、特に HTML 属性では、スペースは免責とは見なされません。
private final static char[] IMMUNE_HTML = { ',', '.', '-', '_', ' ' };
private final static char[] IMMUNE_HTMLATTR = { ',', '.', '-', '_' };
その理由はおそらく、HTML 属性を必ずしも引用符で囲む必要がないためです。引用符がない場合、リテラルスペース文字で属性値が終了します。その場合、値の一部として解釈されるように、空白文字を文字参照でエンコードする必要があります。
私の思いつく例の 1 つは、属性内でテキストを引用した場合、引用符をエスケープする必要があるのは明らかですが、これは通常の html エンコーディングでは必要ありません (ただし、ほとんどのフレームワークでは安全性を高めるためにエスケープを行っています)。 ）。
一般に、html と css をエスケープしようとするのは非常に複雑です。さらに悪いことに、ブラウザーは、標準が存在する場合でも、標準に厳密に従っていません。多くの場合、それらはより寛大で、スクリプト タグ内のスペースの代わりに null 文字などを許可するため、攻撃者は単純なエスケープ メソッドをバイパスできます。もちろん、正確な動作はブラウザごとに異なります。The Tangled Webという本は、この分野の興味深い落とし穴について詳しく説明しています。