6

以下のコードで捕捉できない危険なものの例は何ですか?

編集:いくつかのコメントの後に、別の行を追加し、以下にコメントしました。David Grant の回答で Vinko のコメントを参照してください。これまでのところ、Vinko だけが質問に答えており、この機能をすり抜ける具体的な例を求めています。Vinko が提供してくれましたが、コードを編集してその穴をふさぎました。別の具体例を考えられる方がいらっしゃれば、私の投票をお待ちしております。

public static string strip_dangerous_tags(string text_with_tags)
{
    string s = Regex.Replace(text_with_tags, @"<script", "<scrSAFEipt", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"</script", "</scrSAFEipt", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"<object", "</objSAFEct", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"</object", "</obSAFEct", RegexOptions.IgnoreCase);
    // ADDED AFTER THIS QUESTION WAS POSTED
    s = Regex.Replace(s, @"javascript", "javaSAFEscript", RegexOptions.IgnoreCase);

    s = Regex.Replace(s, @"onabort", "onSAFEabort", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onblur", "onSAFEblur", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onchange", "onSAFEchange", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onclick", "onSAFEclick", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"ondblclick", "onSAFEdblclick", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onerror", "onSAFEerror", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onfocus", "onSAFEfocus", RegexOptions.IgnoreCase);

    s = Regex.Replace(s, @"onkeydown", "onSAFEkeydown", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onkeypress", "onSAFEkeypress", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onkeyup", "onSAFEkeyup", RegexOptions.IgnoreCase);

    s = Regex.Replace(s, @"onload", "onSAFEload", RegexOptions.IgnoreCase);

    s = Regex.Replace(s, @"onmousedown", "onSAFEmousedown", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onmousemove", "onSAFEmousemove", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onmouseout", "onSAFEmouseout", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onmouseup", "onSAFEmouseup", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onmouseup", "onSAFEmouseup", RegexOptions.IgnoreCase);

    s = Regex.Replace(s, @"onreset", "onSAFEresetK", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onresize", "onSAFEresize", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onselect", "onSAFEselect", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onsubmit", "onSAFEsubmit", RegexOptions.IgnoreCase);
    s = Regex.Replace(s, @"onunload", "onSAFEunload", RegexOptions.IgnoreCase);

    return s;
}
4

11 に答える 11

48

それだけでは十分ではありません – ホワイトリストに登録し、ブラックリストに登録しないでください

たとえば、疑似 URL は HTML エンティティで難読化される可能性がありますが、IEにはやなどの危険な CSS プロパティがあるjavascript:ことを忘れていました。<embed>behaviorexpression

フィルターを回避する方法は無数にあり、そのようなアプローチは必ず失敗します。現在、可能性のあるエクスプロイトをすべて見つけてブロックしたとしても、将来、新しい危険な要素や属性が追加される可能性があります。

HTML を保護するには、次の 2 つの方法しかありません。

  • <everyをに置き換えてテキストに変換します&lt;。
    ユーザーが書式設定されたテキストを入力できるようにする場合は、独自のマークアップを使用できます (たとえば、SO のようなマークダウン)。

  • HTML を DOM に解析し、すべての要素と属性をチェックして、ホワイトリストに登録されていないものをすべて削除します。
    また、次のような許可された属性の内容を確認する必要がありますhref(URL が安全なプロトコルを使用していることを確認し、不明なプロトコルをすべてブロックします)。
    DOM をクリーンアップしたら、DOM から新しい有効な HTML を生成します。無効なマークアップ、コメント、エンティティなどによってフィルターが簡単にだまされる可能性があるため、HTML をテキストのように処理しないでください。

また、ブラウザが間違ったエンコーディングを自動検出することを利用するエクスプロイトがあるため、ページでエンコーディングが宣言されていることを確認してください。

于 2008-10-12T17:04:36.637 に答える
10

<すべてを に&lt;、すべて>を&gt;に変換してから、受け入れ可能なタグを元に戻す方がはるかに優れています。言い換えれば、ホワイトリストに載せて、ブラックリストに載せないでください。

于 2008-10-12T16:40:19.493 に答える
7

David が示しているように、javascript: のような何かをいつでも忘れることができるいくつかの正規表現だけで保護する簡単な方法はありません。出力時に HTML エンティティをエスケープすることをお勧めします。実際に許可する必要があるものに応じて、これを行うための最良の方法について多くの議論がありますが、確かなことは、機能が十分ではないということです。

ジェフはこれについてここで少し話しました。

于 2008-10-12T16:35:00.673 に答える
4 
<a href="javascript:document.writeln('on' + 'unload' + ' and more malicious stuff here...');">example</a>

ドキュメントに文字列を書き込むことができるときはいつでも、大きなドアが開きます。

HTML/JavaScript に悪意のあるものを挿入する場所は無数にあります。このため、Facebook は当初、アプリケーション プラットフォームで JavaScript を許可していませんでした。彼らの解決策は、悪いものを真剣に除外できるようにするマークアップ/スクリプト コンパイラを後で実装することでした。

すでに述べたように、いくつかのタグと属性をホワイトリストに登録し、それ以外はすべて取り除きます。いくつかの既知の悪意のある属性をブラックリストに載せて、他のすべてを許可しないでください。

于 2008-10-12T16:27:56.273 に答える
3

http://ha.ckers.org/xss.htmlにあるXSSチートシートをご覧ください。これは完全なリストではありませんが、良いスタートです。

頭に浮かぶのは<imgsrc="http://badsite.com/javascriptfile"/>です。

また、マウスオーバーとスタイルタグを忘れました。

実際に行う最も簡単なことは、エンティティのエスケープです。そもそもベクトルが適切にレンダリングできない場合、不完全なブラックリストは問題になりません。

于 2008-10-13T15:55:27.943 に答える
3

なぜそうしないのか具体的な例を示すことはできませんが、私は先に進み、はっきりとノーと言うつもりです. これはプリンシパルの詳細です。正規表現は素晴らしいツールですが、特定の問題にのみ使用する必要があります。それらは、データのマッチングと検索に最適です。

ただし、セキュリティのための優れたツールではありません。正規表現を台無しにして、部分的にしか正しくないようにするのは簡単すぎます。ハッカーは、構成が不十分な正規表現、または適切に構成された正規表現の内部に多くの余地を見つけることができます。クロス サイト スクリプティングを防ぐために別の方法を試してみます。

于 2008-10-12T16:37:32.243 に答える
3

これを通過する攻撃の例として：

  <div style="color: expression('alert(4)')">

恥知らずなプラグイン: Caja プロジェクトでは、HTML のスクリプトを実行する方法とタイミングを制御できるように、HTML 要素と属性のホワイトリストを定義しています。

http://code.google.com/p/google-caja/でプロジェクトを参照してください。ホワイトリストはhttp://code.google.com/p/google-caja/source/browse/#svn の JSON ファイルです。 /trunk/src/com/google/caja/lang/html および http://code.google.com/p/google-caja/source/browse/#svn/trunk/src/com/google/caja/lang/ CSS

于 2009-01-09T23:32:14.777 に答える
2

空白はあなたを脆弱にします。これを読んでください。

于 2008-10-12T17:11:28.963 に答える
1

ホワイトリストへの別の投票。しかし、あなたはこれについて間違った方法で進んでいるようです。私が行う方法は、HTML をタグ ツリーに解析することです。解析しているタグがホワイトリストにある場合は、ツリー ノードを指定して解析します。属性についても同様です。

ドロップされた属性は単にドロップされます。それ以外はすべて HTML エスケープされたリテラル コンテンツです。

そして、このルートのボーナスは、すべてのマークアップを効果的に再生成しているためです。これはすべて完全に有効なマークアップです! (人々がコメントを残して、検証/設計を台無しにするのは嫌いです。)

Re "I can't whitelist" (para) : ブラックリストはメンテナンスの多いアプローチです。新しいエクスプロイトに注意を払い、確実に対処する必要があります。可哀想な存在です。一度正しく行うだけで、二度と触れる必要はありません。

于 2008-10-12T16:53:22.947 に答える
1

別の観点から言えば、誰かが「javascript」または「functionload」または「visionblurred」を送信したい場合はどうなりますか? これは、さまざまな理由でほとんどの場所で発生する可能性があります...私が理解していることから、それらは「javaSAFEscript」、「functionSAFEload」、「visionSAFEblurred」(!!) になります。

これが当てはまる可能性があり、ブラックリストのアプローチに行き詰まっている場合は、正確に一致する正規表現を使用して、ユーザーの迷惑にならないようにしてください。言い換えれば、セキュリティと使いやすさの最適なポイントにあり、どちらもできるだけ妥協しないようにします。

于 2008-10-13T16:39:13.020 に答える