Drupalには filter_xss 関数があります。任意のユーザーHTML入力のフィルタリングに使用しても安全ですか?
そうでない場合、Drupal 7?
この質問は Drupalの組み込みxssフィルターVS HTMLピューリファイアモジュール の複製ですが、filter_xssにはHTMLを検証するためのコードが含まれていないため、その答えは正しくないようです
Drupalのfilter_xss
が安全かどうかはわかりません。あなたが提供したリンクによると、Drupalのfilter_xss
は、HTMLフィルタリング用のksesライブラリに基づいています。端的に言えば、ksesやksesから派生したフィルターは信用できません。
Ksesのコードを見ると、それはモンスターの正規表現に基づいています。これはHTMLのサニタイザーにとって不必要なアーキテクチャであり、その方法で構築されたものは何も信頼しません。任意のHTMLをフィルタリングする必要がある場合、適切な方法は、HTMLを解析してから解析ツリーを操作することです。 (HTML Purifierはそのように機能し、結果として部分的には、HTML Purifierをはるかに信頼しています。)
歴史的に、ksesにはいくつかのセキュリティ問題がありました。たとえば、 ksesベースのHTMLフィルターの脆弱性 および HTMLサニタイズ:悪魔の詳細(および脆弱性) を参照してください。これらの脆弱性がDrupalのバージョンに影響を与えるかどうかはわかりませんが、自信を刺激するものではありません。したがって、HTMLフィルタリングが必要で、セキュリティに基づいて選択している場合は、おそらくfilter_xss
よりもHTML Purifierを選択すると思います。
私も少しバックアップする必要があります。あなたが直面している状況についてはあまり話さなかった。 HTMLフィルタリングがあなたの仕事に適切なツールであると確信していますか?私の経験では、HTMLフィルタリングではなく、HTMLエスケープ(出力エンコーディング)が必要になることの方がはるかに一般的です。
信頼できない入力をHTMLドキュメントに含める場合は、必要な機能の種類を決定する必要があります。
HTMLエスケープ、別名出力エンコーディング。ユーザー提供の入力は「単なるプレーンテキスト」で、リッチなフォーマットはありませんか?はいの場合は、filter_xss
ではなく、HTMLエスケープ(出力エンコーディングとも呼ばれます)を使用します。 HTMLエスケープを行う場合は、状況依存エスケープを使用して、信頼できないデータが挿入される解析コンテキストに対して適切な方法でデータをエスケープします。詳細については、次のリソースをご覧ください。
OWASP XSSの概要 および OWASP XSS防止に関するチートシート を含む、XSSに関するOWASPのリソース。 OWASP ESAPIライブラリには、実行される可能性が高いすべてのHTML解析コンテキスト用の出力エスケープ関数があります。
HTMLフィルタリング。ユーザー提供の入力にリッチHTML形式を含めることを許可しますか?ユーザーがほぼ任意のHTMLを入力できるようにしますか。そのHTMLをそのまま出力ドキュメントに含めますか?はいの場合、HTMLフィルターが必要です。この状況では、HTML Purifierは優れた選択であり、おそらくDrupalのfilter_xss
よりも安全です。それは私の個人的な意見です。
ユーザーが提供した入力をHTML文書に挿入するとき、私の経験では、HTMLフィルタリングではなく、HTMLエスケープが必要な時間の95%以上になると思います。 HTMLフィルタリングは例外です。 (どのくらいの頻度でユーザーがHTMLマークアップを入力することを期待していますか?一般向けのアプリケーションを作成している場合、答えはほとんどありません。)では、とにかくHTMLフィルターが必要ですか?
D.W.いくつかの優れた点がありますが、私はいくつかのことを指摘しておきます:
このコードは4つのことを行います。
- ブラウザをだますことができる文字や構造を削除します。
- すべてのHTMLエンティティが整形式であることを確認します。
- すべてのHTMLタグと属性が整形式であることを確認します。
- HTMLタグに、許可されていないプロトコル(
javascript:
など)のURLが含まれていないことを確認してください。
それがこのリストのすべてのものの優れた仕事をしていると仮定すると、いくつかの顕著な省略があります:タグバランシング、エンコーディングレベルの攻撃、リンクスパム =。
それがうまくいくとしても、HTMLPurifyは周りにあり、攻撃されています。新しい攻撃を公開する前に、HTMLPurifyにパッチが適用され、安定していることを確認する、少なくとも1人のセキュリティアカデミックを頭のなかで考えることができます。 Drupalが同様の精査を受け取らなかった場合は、より強化されたものを使用します。
ユーザーのセキュリティが、ユーザーが作成したコンテンツと、コメント投稿者や他のサードパーティが作成したコンテンツを区別できるかどうかに依存する場合は、タグのバランスが重要です。
フォーマットに<table>
sを使用したとします。タグのバランスが取れていない場合、サードパーティのコンテンツのように見える領域から、サイト所有者によって制御されているように見えるページの領域にコンテンツを忍び込むことができます。たとえば、ホワイトリストに<table>
のような無害なフォーマットタグが含まれている場合、
</table>
<center>If you have any questions,
<a href="[email protected]">contact us</a>
<br>Bogus copyright</center><br><br><br><br><sub><sub><sub><sub><sub>
攻撃者がフィッシングリンクを含むフッターを偽造する可能性があります。
同様に無害に見える</ul>
は、セマンティックHTMLごとに<ul><li>...</ul>
を使用して表示されるユーザーコメントのリストから攻撃者が抜け出すのに役立つ可能性があります。
HTMLの専門家は<table>
や<ul>
のようなバランスのとれた要素はセキュリティに注意を払う必要がないと正しく想定しているため、ユーザー設定可能なホワイトリストを使用すると、ここにぶらぶらする余地が多くなります(フローコンテンツの周りにボックスを作成するだけです) )、ただし個々のタグには問題があります。
攻撃者が、コンテンツをサニタイズしたコンテンツを、エンコードを指定するContent-type
ヘッダーを持たないHTMLページの最初の数kBに入れることができる場合、IEページをUTF-7として扱い、他のすべてのサニタイズを回避します。
これは「ブラウザをだますことができる構成」に該当する可能性がありますが、そのページのソースコードはそうであることを示していません。
リンクを許可しても、サニタイザーがrel="nofollow"
をリンクに追加しない場合、評判が乗っ取られる可能性があります。