この記事を読んだ後、私には明確な答えがありません。
http://palizine.plynt.com/issues/2010Oct/bypass-xss-filters/
ブラウザは text/html データ URI ペイロードを、タグが実行される
<img>srcドキュメントとして解釈しますか?<script>そうでない場合、サードパーティの HTML でデータ URI を許可しても安全ですか?
このユース ケースでは、ブラウザー レベルでどのような安全メカニズムが存在しますか?
この記事を読んだ後、私には明確な答えがありません。
http://palizine.plynt.com/issues/2010Oct/bypass-xss-filters/
ブラウザは text/html データ URI ペイロードを、タグが実行される<img> srcドキュメントとして解釈しますか?<script>
そうでない場合、サードパーティの HTML でデータ URI を許可しても安全ですか?
このユース ケースでは、ブラウザー レベルでどのような安全メカニズムが存在しますか?
MSDNのドキュメントには、IE は次のことを行わないと書かれています。
セキュリティ上の理由から、データ URI はダウンロードされたリソースに制限されています。データ URI は、ナビゲーション、スクリプト作成、またはフレームまたは iframe 要素への入力には使用できません。
一方、Mozilla ではiframeとスクリプトの実行が許可されています。
data: リファラーのオリジンを継承する URL を使用すると、親が対話できるコンテンツを生成またはウィンドウ化するために使用できます。Gecko は常にこの方法でそれを行ってきました (そして、それを心配しなければならない多くのセキュリティ チェックがあちこちに散らばっています)。
SafariおよびChromiumサンドボックス データ URI の実行。効果的にそれらをクロス ドメイン リクエストとして扱います。
現在、data: URI は、他の data: URI を含む他のオリジンにアクセスできないものとしてマークされています。
HTML5 仕様には次のように記載されています。
ドキュメントまたは画像がデータから生成された場合: HTTP リダイレクトの場所として返された URL (または他のプロトコルで同等のもの)
origin は、data: URL にリダイレクトされた URL のオリジンです。
ドキュメントまたは画像がデータから生成された場合: 別のドキュメントまたはスクリプトで見つかった URL
オリジンは、ナビゲート アルゴリズムが呼び出されたとき、またはスクリプトが含まれていない場合は、その URL へのナビゲーションを開始した要素のノード ドキュメントの、現在の設定オブジェクトによって指定されたオリジンへのエイリアスです。
ドキュメントまたは画像が他の方法で取得された場合 (例: ユーザーが入力した data: URL、createDocument() API を使用して作成されたドキュメント、HTTP リダイレクトの場所として返された data: URL など)
オリジンは、ドキュメントまたは画像の作成時に割り当てられるグローバルに一意の識別子です。
そしてRFC6454は次を追加します:
URI は、必ずしもそれ自体と同じオリジンであるとは限りません。たとえば、データ URI [RFC2397] はそれ自体と同じオリジンではありません。これは、データ URI がサーバーベースの命名機関を使用しないため、オリジンとしてグローバルに一意の識別子を持っているためです。
CSSHTTPRequestライブラリは、データ URI を使用してクロスサイト GET 要求を実行しますが、これはすべてのブラウザーで実行できるほとんどのことです。
参考文献
この方法でデータを挿入することは可能ですが、画像自体のバイナリ データにデータを挿入することも可能であることに注意することが重要です。いずれにせよ、100%安全なものはありません。これまで。codeigniter フレームワークを使用している場合は、これから非常にしっかりと保護できます。
$this->security->xss_clean()
それ以外は、正規表現で危険なものを削除するだけのスクリプトの独自のバージョンを構築できます。このようなスクリプトを作成するときは、さまざまな文字エンコーディングに注意してください。