web-dev-qa-db-ja.com

XSSフィルターがスラッシュをエスケープする必要があるのはなぜですか？

HTML要素コンテンツの信頼できない入力のエスケープ に関するOWASPの推奨事項では、次のように記載されています。

& --> &
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27;  &apos; not recommended because its not in the HTML spec (See: section 24.4.1) &apos; is in the XML and XHTML specs.
/ --> &#x2F;  forward slash is included as it helps end an HTML entity

そこに/を含める目的は何ですか？実際、/は終了エンティティの一部ですが、すでに<をエスケープしており、AFAIKはエンティティの終わりとして/を前に付けずに<を受け入れません。それを脱出する理由は何ですか？

web-applicationxsshtmldefense
16
StasM

HTML 5に標準の解析アルゴリズムが付属する前は、HTML 4はSGMLに基づいて定義されていました。そして、そのSGMLベースの構文には、ブラウザーサポートの点で異なる機能と、それらを認識する人々の点で異なる機能がありました。

この質問の目的で、あなたが興味を持つであろうあいまいな機能の1つはNull End Tag（NET）です。 HTMLページの次のコードを見てください。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title/hello/
<body>
<p/hello/

必要に応じて、 HTMLバリデータ を使用してみてください。 NETは、<TAGNAME/text/のようなコードが<TAGNAME>text</TAGNAME>から取得するものと同じものに解析されることを指定しています。

ここから、ユーザー提供のデータをマークアップに補間するときに/文字をエスケープすることがなぜ良いのかを理解できるかもしれません。 /は、これらのNET構造の1つになり、リテラルソリッドではなく、終了タグとして解釈される可能性があります。

現在、NET構文を理解しているブラウザーはありませんが、これは仕様の一部であるため、それを考慮することは賢明です。

9
guest

あなたの質問は「なぜ/なのか？」と尋ねます。

ただし、>、"、'については心配していないようです。

技術的には、要素コンテンツ内のセキュリティを確保するには、<、&、>、または"でHTMLタグを開始できないため、'および/文字のみをエンコードする必要があります。ここではHTMLについてのみ話していることに注意してください（XHTMLではありません）。

あなたの質問に答える理由は、/が特別な意味を持つHTML文字であることです。 OWASPガイドラインに従っている場合は、システムをセキュリティで保護する必要があると見なされます。この場合、そうすることの欠点はほとんどないので、常に注意する必要があります。

最小限にしたい場合は、 OWASP XSS実験的最小エンコーディングルール を確認してください。

6
SilverlightFox

キャラクターが何らかの文脈で構文上の意味を持っている場合、あなたは用心深く、それをエスケープする側に誤りがあるべきです。

たとえば、攻撃者が既存のタグの末尾に挿入する方法を見つけた場合、<br />のようなタグを作成することができますが、終了する必要はありません。変換によってドキュメントの意味が変わる可能性があります。

それ以上の具体的な例はありませんが、それを脱出するのにかかるコストは非常に少ないため、トレードオフはそうすることを支持しています。

他のバグやミスがこの特定のインクルージョンによって悪用可能にされるのを防ぐ以外に、その理由は特にありません。これは、その必要性を示すために普遍的に開発できるPoCがないという点で、特に強力な推奨事項ではありませんが、それに従うことに害はありません。

3
Falcon Momot

「私の知る限り...」は、危険な文字をエンコードできない多くのバグの原因です。危険でないとわかっているものだけをエンコードしないのではなく、危険なことがわかっているものだけをエンコードするのが「ブラックリスト」アプローチです。

例として、サーバーがHTMLタグ属性の値をユーザー入力に設定するとします...

<input value=userdata>

上記は完全に合法で有効なHTMLです。多くのWebページはそれらの値を引用符でカプセル化せず、ブラウザはこれを正しく解釈します。

ここで、ページの上部に含めたOWASPリストを使用するとします。スペースはリストにないことに注意してください..。

<input value=foo onclick=alert()>

これで攻撃が成功しました。スペースを使用して前のコンテキストから抜け出し、次に等号を使用してJavaScriptを記述できるコンテキストを設定し、括弧を使用して関数を実行しました。これらのどれも、あなたが示した（壊れた）ブラックリストにはありませんでした。

これと同じ攻撃（スペースを使用してブレイクアウト）を使用すると、/記号をJavaScriptコンテンツの一部として除算記号として使用したり、コメントの一部（//または/ *）として使用したり、他の方法で使用したりできます。 OWASPフィルター回避チートシート（ https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet ）は、エンコードされているものとエンコードされていないものに応じて、さまざまな文字を使用した適切な攻撃文字列のリストを持っています。とさまざまなコンテキスト。ダッシュ（-）文字は、mozillaに対するXULマークアップに使用できます。

問題がどこにあるかがわからないからといって、それだけでは十分ではありません。あなたはそれを通過する前にそれが問題になることは決してないことを知っていなければなりません。上記の例でわかるように、OWASPでもユーザーデータの特定の有効な使用法を予測できず、エンコード命令が不完全でした。

安全なことは、常にすべてをエンコードすることです。一般的に、英数字以外のすべてのASCII文字を文字ポイント127未満にエンコードし、それ以外はすべてエンコードせずに安全です。これより少ないと、上記のエラーが発生します。

2
atk