開発者ツール · HTML WYSIWYG エディター
貼り付けられた HTML のサニタイズ: CMS または電子メールに届く前に何を除去するか
· 仕組み
html セキュリティ テキストクリーンアップ
ホワイトリストに登録されたタグや属性から、削除されたスクリプトや無力化された URL まで、HTML サニタイザーの機能と、最初にマークアップを検査することでどのようにサニタイザー ルールの記述が容易になるかについて説明します。
onclick を含む貼り付けられたスニペット — リッチテキスト入力に隠れたリスクを伴って開く
アンカーを貼り付けると、無害な宛先の横にある onclick が非表示になることがあります。 ToolAcre はすべての属性名を小文字にし、受け入れられた要素に対して明示的にリストされた属性のみを保持するため、大文字と小文字が変更されても onclick は表示されなくなります。削除レポートは、変更されていないソースを黙って提示するのではなく、そのイベント ハンドラーを識別します。
この境界は、リッチ ペーストが挿入される前、ソースがビジュアル モードに戻るとき、コピー前、プレーン テキスト抽出前、そしてプレビュー ドキュメントの構築中に再度動作します。繰り返しによりアクション間の偶発的なバイパスが減少しますが、プロジェクトは依然として手書きトークナイザーを汎用 XSS フィルターと呼ぶことを拒否しています。
ホワイトリストがブロックリストに勝る理由 — 危険な構成要素をすべてリストアップしようとするよりも、許可されるものに名前を付ける方が安全であることを説明します
ホワイトリストは、許可される構造 (段落、見出し、セマンティック インライン要素、リスト、説明リスト、引用符、コードのような要素、およびアンカー) に名前を付けることから始まります。未知の通常のラッパーは、テキストを保持しながらタグを失います。スクリプト、スタイル、iframe、フォーム、SVG、MathML などの危険なコンテナもその内容を失います。
ブロックリストでは、危険な建設やサポートされていない建設をすべて予測する必要があります。ホワイトリストは理解できないものを拒否します。これは、ある編集者の制約された出力にとっては強力な選択ですが、依然としてトークナイザーによって制限されています。ブラウザの HTML5 エラー回復では、意図的に不正な入力が含まれる場合、より小さなパーサーとは異なるツリーが生成される可能性があります。
タグ、属性、および URL スキーム — サニタイザー フィルターの 3 つのレイヤーをカバーし、それぞれの一般的な決定を示します。
フィルタリングは 3 つのレイヤーで行われます。要素は構造語彙を決定します。要素ごとの属性では、リンクの href とタイトル、引用の引用、略語のタイトル、順序付きリストの開始とタイプなど、いくつかの値のみが許可されます。次に、URL 検査はエンティティをデコードし、プローブからコントロールと空白を取り除き、結果のスキームをチェックします。
受け入れられるスキームは、http、https、mailto、tel、ftp、および明示的なスキームのない相対形式です。 JavaScript、データ、ファイル、BLOB、vbscript、およびサンプルについては、テストで拒否されます。生き残ったリンクには rel 値が追加されますが、その追加は宛先ポリシーやリンクのレビューの代わりにはなりません。
スタイル: ストリップ、許可、または書き換え — インライン スタイルの処理と、多くのシステムがそれを完全に削除する理由について説明します。
スタイル属性は完全に削除されます。このモジュールは、宣言を解析したり、安全なサブセットを保持したり、デザイン トークンを書き換えたりすることはありません。このポリシーは、コピーされた外観と CSS ベースのリクエスト サーフェスを一緒に削除します。 class、id、data 属性も失われ、移植性はあるものの、意図的に表現力が低くなったマークアップが生成されます。
本物のスタイル要件を持つシステムには、別のレビュー済みポリシーが必要です。 CSS サニタイザーを使用せずにこのホワイトリストにスタイルを追加すると、セキュリティ面が大幅に変化します。現在の実装では、任意の敵対的なフラグメントに対する CSS の安全性を解決すると主張するのではなく、その問題を回避しています。
実用的な例: Word 固有のフィクスチャではなく、ToolAcre の文書化された許可リストからルールを派生させます
`<div class="WordSection"><p style="color:red" onclick="x()">Notice <strong>today</strong></p></div>` から始めます。 div はラップ解除され、クラスとスタイルは存続できなくなり、onclick は削除され、段落と強い要素が残ります。結果は、どのアプリケーションがラッパーを生成したかを主張することなく、一般的なポリシーに従います。
JavaScript href と script ブロックを追加します。アンカーは表示される単語を保持しますが、href を失います。スクリプトと本文が消えます。報告された理由を読んでください。この演習はサーバー ポリシーの定義に役立ちますが、ToolAcre の正確なサブセットをやみくもにコピーすると、アプリケーションに必要な要素が省略されたり、脅威モデルが禁止する URL が許可されたりする可能性があります。
サーバー側とクライアント側のサニタイズ — ブラウザーがすでにサニタイズを行っている場合でも、サーバーがサニタイズする必要がある理由を説明します。
クライアント フィルタリングはローカル ドラフトを改善しますが、ユーザー制御のリクエストを受信するサーバーからは信頼できません。攻撃者はページをバイパスしたり、エンドポイントを直接呼び出したり、パーサーの違いを悪用したりする可能性があります。サーバーは、レンダリング コンテキスト用に構成された維持された HTML5 対応実装を使用して、再度解析してサニタイズする必要があります。
出力エンコーディングも個別のままです。テキストとして意図された HTML は、マークアップとして挿入されるのではなく、テンプレートによってエスケープされる必要があります。意図的に HTML としてレンダリングされたフラグメントは、アーキテクチャに従って保存または出力する前にサニタイズが必要です。サンドボックス プレビューは、このプレビューがスクリプト、フォーム、または同一オリジン アクセスを許可しないことのみを証明します。
このツールの対象となるのは、一般的な敵対的な入力のサニタイズではなく、狭いエディターの出力フィルタリングです。
ToolAcre は、単なる検査ツールであるというワークブックの主張に反して、独自の出力サーフェスをフィルターします。正確な修正はより狭く、任意の敵対的な入力に対する汎用の XSS サニタイザーではありません。ソースはこれを明示的に述べており、パーサーの違いの可能性を文書化しています。
iframe は、ToolAcre 内でのレンダリングを多層防御します。その空のサンドボックス属性では、スクリプトの実行、フォーム送信、または同一オリジン アクセスが許可されず、リファラー ポリシーは非リファラーです。 HTML が別の場所にコピーされると、そのフレームはそれを保護しなくなります。出版物の安全性は受信システムに属します。
要点: ローカルで検査し、サーバーでサニタイズ — ワークフローと、サニタイザーが直面する問題をエディターがどのように確認できるかをまとめています。
ローカルで検査し、サーバー上でサニタイズし、コンテキストに従ってレンダリングします。これらは 3 つの異なるステップです。 ToolAcre は、貼り付けられたバゲッジを明らかにし、保守的なドラフトのサブセットを提供するのに役立ちます。一方、削除通知により、フラグメントが CMS または電子メールのワークフローに到達する前にポリシーの効果が可視化されます。
成功したプレビューを XSS に対する証拠として宣伝しないでください。テスト ペイロードは使い捨てコンテンツでのみ使用し、調査が重要な場合は生のソースを個別に保存し、宛先のサニタイズを個別に検証します。セキュリティの主張は、コードとレンダリングの境界が止まる位置で正確に停止する必要があります。