2

利用可能なantisamy-1.4.1.xmlポリシーでAntiSamyを使用しています。ポリシーは、攻撃されたほとんどのXSSをブロックするためにうまく機能していますが、以下はブロックされていません。XSS攻撃を防ぐために、以下をブロックする方法に関する提案はありますか？

1234%27%2Balert%2873918%29%2B%27

ありがとう

4

1 に答える 1

15

Antisamyは、信頼できないユーザーが「安全な」HTMLの限定されたサブセットを入力できるようにすることを目的としたHTMLコンテンツフィルターです。これは、文字列のエスケープやXSSの問題について考える必要をなくすことができる万能の入力フィルターではありません。

antisamyは、ページに逐語的に出力するHTMLを含むコンテンツをクリーンアップする場合にのみ使用する必要があります。ほとんどのユーザー入力は一般にHTMLではありません。ユーザーが入力するとき、a<b or c>d通常、太字のタグではなく、文字通りの小なり記号と大なり記号を取得する必要があります。これが正しく行われるようにするには、antisamyとは関係なく、出力段階でページに挿入されるすべてのテキストコンテンツをHTMLエスケープする必要があります。

1234%27%2Balert%2873918%29%2B%27

これは、典型的なHTMLインジェクション攻撃のようには見えません。含まれている唯一の「特殊」文字はアポストロフィです。これは通常HTMLで特別ではなく、ユーザーは通常英語で書くためにアポストロフィを使用する必要があるため、入力から実際に除外することはできません。

これがアプリケーションのスクリプトインジェクションを引き起こしている場合は、antisamyが解決できるものよりも大きな問題があります。これによりページにalert()ダイアログが表示される場合は、JavaScript文字列リテラルでエスケープされていない値を使用している可能性があります。たとえば、次のようになります。

<a href="..." onclick="callfunc('hello <%= somevar %>');">

テキストコンテンツを文字列リテラルとしてJavaScriptコードに入れるには、別の形式のエスケープが必要です。'文字（ URLエンコード%27された入力内の）をバックスラッシュでエスケープされたものに変換し\'、\それ自体を\\（および他のいくつかの置換）に変換するもの。

サーバーサイドスクリプト言語からJavaScriptリテラルに値（文字列など）を取得する簡単な方法は、標準のJSONエンコーダーを使用することです。

ただし、上記の場合、JavaScript文字列リテラル自体がHTML属性内に含まれているため、JSONエンコーダーの結果をHTMLエンコードする必要があります。これは少し醜いです。インラインイベントハンドラー属性は避けるのが最善です。<script>代わりに外部スクリプトと要素を使用し、HTMLではなくJSからのイベントをバインドします。

<script>通常HTMLエンコードする必要がないブロックでも、文字列</script>（または、通常、</ブロックを終了する可能性のある最初の文字列）に注意する必要があります。そのシーケンスを回避するには、<文字を別のものに置き換える必要があります。\x3C。一部のJSONエンコーダーには、問題を回避するためにこれを行うオプションがある場合があります。

含まれている言語にコンテンツを挿入するために特別な種類のエンコーディングが必要な場所は他にもたくさんあります。それぞれに独自のルールがあります。汎用入力フィルターを使用して文字列エンコードの難しさを回避することはできません。一部の「アンチXSS」フィルターは試行しますが、常に惨めに失敗します。

于 2010-08-08T00:51:19.343 に答える