web-dev-qa-db-ja.com

HTMLメタタグ内のXSS

検索機能を含むウェブアプリケーションがあります。 aaaaaaaaxssを検索すると、次のようになります。

<meta property="the:property" content="100 Results for aaaaaaaaxss (Page 1)" />

_<_および_>_文字は削除されますが、二重引用符は削除されません。しかし、他の入力を取り除くことができないので、1;javascript:alert(1)や類似のものを使用できません。

このフィルターは安全ですか？

web-applicationjavascriptxssclient-side
4
735Tesla

私は間違いなく、ブラックリストの非有効性についてのザクサーに同意します-答えが私のウェブサイトを参照したからではありません:).

完全に不可能ではありませんが、最初のコンテンツ部分を取り除くことができないと、メタタグを介してXSSが成功する機会が確実に制限されます。たとえば、最初の部分が「No results for ...」などの非数値のWordで始まるように変更された場合、次のようなものを挿入できる可能性があります。

_;url=hxxp://www.maliciousxss.com" HTTP-EQUIV="refresh" blah="_これは、説明に基づいて、次のようなメタタグになります。

<meta property="the:property" content="No results for;url=hxxp://www.maliciousxss.com" HTTP-EQUIV="refresh" blah=" (Page 1)" />

私はFF 29.0.1でテストに成功しましたが、これが他の最新のブラウザーで機能するとは思いません。

最初のテキストが常に数字で始まる場合は、次のようなことを試すことができます

" STYLE="width:expression(alert('XSS'));" blah=" whichも、例に基づいて、次のようなメタタグになります。

<meta property="the:property" content="100 results for" STYLE="width:expression(alert('XSS'));" blah=" (Page 1)" />

これはIE 7以前でのみ機能するため、さらに制限されます。

これらの特定の例が機能しない可能性があるため、サイトの動作と追加の入力検証のいくつかの仮定を行う必要がありましたが、ブラックリストが完全に効果的なアプローチであることはめったにないという、xacreの発言をサポートできたら幸いです。ホワイトリスト（可能な場合）の方が優れていますが、ユーザー生成データがサーバーの応答に組み込まれる場合は常に出力エンコーディングが必須です。

5
T_v3rn1x

頭から離れて、ページを特に見ない限り、攻撃ベクトルを考えることはできませんが、「ブラックリスト化」が完全に効果的なセキュリティ手法であることはめったにないので、安全ではないと思います。

具体的にはメタタグに対処する例としてこの記事を見つけました： http://www.securitysift.com/quotes-and-xss-planning-your-escape/

その記事で説明されているように、HTTP-EQUIV = "refresh"とbase64エンコードされたURLを挿入してページをリダイレクトすることができます。

3
thexacre