19

私は、作業中の Web アプリケーションのどこでセキュリティを強化する必要があるかを把握するために、innerHTML を使っていくつかの実験を行ってきました。

var name = "<img src=x onerror=alert(1)>";
element.innerHTML = name; // Instantly runs code.

a.) innerHTML を使用する必要があるかどうか、b.) それが問題ではない場合、なぜ他のコード挿入方法、特に eval を避けてきたのか、疑問に思いました。

私はブラウザで JavaScript クライアント側を実行していて、簡単にアクセスできる関数で機密情報を公開しないように必要な予防措置を講じており、innerHTML がセキュリティではないと判断した任意に指定されたポイントに到達したとします。リスクがあり、コードを最適化して、パフォーマンスへの影響が非常に小さいことを必ずしも心配しないようにしました...

eval を使用すると、さらに問題が発生しますか? 純粋なコード インジェクション以外にセキュリティ上の懸念事項はありますか?

または、別の方法として、innerHTML は同じように注意する必要がありますか? 同じように危険ですか？

4

3 に答える 3

21

tl;dr;

はい、あなたの仮定は正しいです。

innerHTML信頼できないコードを追加している場合、設定は XSS 攻撃の影響を受けやすくなります。

(ただし、コードを追加する場合は、それほど問題にはなりません)

textContentユーザーが追加したテキストを追加する場合は、使用を検討してください。エスケープされます。

問題は何ですか

innerHTMLDOM ノードの HTML コンテンツを設定します。DOM ノードのコンテンツを任意の文字列に設定すると、ユーザー入力を受け入れると XSS に対して脆弱になります。

たとえば、パラメータinnerHTMLからのユーザーの入力に基づいてノードの を設定するとしGETます。「ユーザー A」は、「ユーザーのデータを盗み、AJAX 経由で送信してください」という HTML を含むバージョンのページを「ユーザー B」に送信できます。

詳細については、こちらの質問を参照してください。

それを軽減するにはどうすればよいですか？

ノードの HTML を設定する場合に考慮すべきことは次のとおりです。

  • エスケープ機能を持つMustacheのようなテンプレート エンジンを使用します。(デフォルトでは HTML をエスケープします)
  • textContentノードのテキストを手動で設定するために使用する
  • ユーザーからテキスト フィールドへの任意の入力を受け入れず、データを自分でサニタイズします。

XSS を防ぐためのより一般的なアプローチについては、この質問を参照してください。

コードインジェクションが問題です。あなたは受信側になりたくありません。

部屋の象

innerHTMLとの問題はそれだけではありませんeval。DOM ノードの を変更するときはinnerHTML、コンテンツ ノードを破棄し、代わりに新しいノードを作成します。呼び出しているときevalは、コンパイラを呼び出しています。

ここでの主な問題は明らかに信頼されていないコードであり、パフォーマンスはそれほど問題ではないとおっしゃいましたが、それでも、この 2 つは代替手段に対して非常に遅いことに言及しなければならないと感じています。

于 2013-05-31T15:02:24.367 に答える