他の種類の攻撃については心配していません。HTML Encode があらゆる種類の XSS 攻撃を防ぐことができるかどうかを知りたいだけです。
HTML エンコードが使用されている場合でも、XSS 攻撃を行う方法はありますか?
他の種類の攻撃については心配していません。HTML Encode があらゆる種類の XSS 攻撃を防ぐことができるかどうかを知りたいだけです。
HTML エンコードが使用されている場合でも、XSS 攻撃を行う方法はありますか?
いいえ。
いくつかのタグを許可するという主題 (実際には問題のポイントではありません) はさておき、HtmlEncode は単にすべての XSS 攻撃をカバーしているわけではありません。
たとえば、サーバー生成のクライアント側 JavaScript を考えてみましょう。サーバーは、html エンコードされた値を直接クライアント側 JavaScript に動的に出力します。htmlencode は、挿入されたスクリプトの実行を停止しません。
次に、次の疑似コードを検討してください。
<input value=<%= HtmlEncode(somevar) %> id=textbox>
ここで、すぐには明らかでない場合に備えて、somevar (もちろんユーザーによって送信されます) がたとえば次のように設定されている場合
a onclick=alert(document.cookie)
結果の出力は
<input value=a onclick=alert(document.cookie) id=textbox>
これは明らかに機能します。明らかに、これは(ほとんど)他のスクリプトである可能性があります...そしてHtmlEncodeはあまり役に立ちません。
考慮すべき追加のベクトルがいくつかあります... DOM ベースの XSS と呼ばれる XSS の 3 番目のフレーバーが含まれます (悪意のあるスクリプトは、# 値などに基づいてクライアント上で動的に生成されます)。
また、UTF-7 タイプの攻撃についても忘れないでください。攻撃は次のようになります。
+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-
そこにエンコードするものはあまりありません...
もちろん、(適切で制限的なホワイトリストの入力検証に加えて) 解決策は、コンテキスト依存のエンコーディングを実行することです: HtmlEncoding は、出力コンテキストが HTML である場合、または JavaScriptEncoding、VBScriptEncoding、または AttributeValueEncoding が必要な場合に最適です。 、または...など
MS ASP.NET を使用している場合は、必要なすべてのコンテキスト エンコーディング メソッドを提供する Anti-XSS Library を使用できます。
すべてのエンコーディングは、ユーザー入力に限定されるべきではなく、データベースやテキスト ファイルなどからの保存された値にも制限されるべきであることに注意してください。
ああ、HTTP ヘッダーと META タグの両方で明示的に文字セットを設定することを忘れないでください。そうしないと、UTF-7 の脆弱性が残ります...
RSnake のチート シート ( http://ha.ckers.org/xss.html ) を参照してください。
表示する前にすべてのユーザー入力を体系的にエンコードする場合、はい、安全です。それでも 100% 安全ではありません。
(詳細については、@Avid の投稿を参照してください)
さらに、ユーザーが画像や太字のテキスト、またはユーザーの入力をエンコードされていないマークアップとして処理 (または変換) する必要がある機能を投稿できるようにするために、一部のタグをエンコードしないようにする必要がある場合に問題が発生します。
どのタグが許可され、どのタグが許可されないかを決定する意思決定システムをセットアップする必要があり、許可されていないタグを通過させる方法を誰かが見つけ出す可能性は常にあります。
間違ったコードを間違ったように見せるという Joel のアドバイスに従うか、未処理のユーザー データ (静的型付け) を出力するときに警告/コンパイルしないことで言語が役立つ場合に役立ちます。
すべてをエンコードすると、それが可能になります。(プラットフォームと htmlencode の実装によって異なります) しかし、有用な Web アプリケーションは非常に複雑であるため、すべての部分をチェックすることを忘れがちです。または、サードパーティのコンポーネントが安全でない可能性があります。または、エンコーディングを行ったコードパスがそれを行わなかったため、別の場所で忘れてしまった可能性があります。
そのため、入力側でもチェックする必要があるかもしれません。また、データベースから読み取った内容を確認することもできます。
いいえ、一般的なHTMLトークンをエンコードするだけでは、XSS攻撃からサイトを完全に保護することはできません。たとえば、google.comにあるこのXSSの脆弱性を参照してください。
http://www.securiteam.com/securitynews/6Z00L0AEUE.html
このタイプの脆弱性に関する重要な点は、攻撃者がUTF-7を使用してXSSペイロードをエンコードできることです。ページで別の文字エンコードを指定していない場合、ユーザーのブラウザがUTF-7ペイロードを解釈して攻撃スクリプトを実行します。
出力フィルタリングを処理するサードパーティのライブラリを見つけるようにという metavida のアドバイスに賛成です。HTML 文字を無力化することは、XSS 攻撃を阻止するための優れた方法です。ただし、メタキャラクターを変換するために使用するコードは、回避攻撃に対して脆弱になる可能性があります。たとえば、Unicode と国際化を適切に処理しない場合です。
自作の出力フィルターが犯す典型的な単純な間違いは、< と > だけをキャッチして " などを見逃してしまうことです。これにより、ユーザー制御の出力が、Javascript を DOM にアタッチできる HTML タグの属性スペースに分割される可能性があります。
他の誰もが述べたように、すべてのユーザー入力を表示する前にエンコードする限り、安全です。これには、ユーザー入力によって変更できるデータベースから取得されたすべての要求パラメーターとデータが含まれます。
パットが述べたように、すべてのタグではなく、いくつかのタグを表示したい場合があります。これを行う一般的な方法の 1 つは、 Textile、Markdown、またはBBCodeなどのマークアップ言語を使用することです。ただし、マークアップ言語でさえ XSS に対して脆弱である可能性があることに注意してください。
# Markup example
[foo](javascript:alert\('bar'\);)
「安全な」タグを通過させることにした場合は、既存のライブラリを見つけて、出力前にコードを解析およびサニタイズすることをお勧めします。サニタイザーがかなり安全になる前に、検出しなければならないXSS ベクトルがたくさんあります。
もう 1 つチェックする必要があるのは、入力のソースです。(ほとんどの場合) リファラー文字列を使用して、それが自分のページからのものであることを確認できますが、非表示の乱数または何かをフォームに入力してから (おそらくセッション セット変数を使用して) チェックすることも、入力は、フィッシング サイトではなく、自分のサイトからのものです。
HTML Purifier ( http://htmlpurifier.org/ )を提案したいと思います。これは、html をフィルタリングするだけでなく、基本的にトークン化して再コンパイルします。それはまさに産業の強さです。
有効な html/xhtml 出力を保証できるという追加の利点があります。
また、テキスタイルも素晴らしいツールで、私は常に使用していますが、html purifier も使用しています。
トークンに関して私が何を意味するのか理解していないと思います。HTML Purifier は単に「フィルタリング」するだけでなく、実際に html を再構築します。http://htmlpurifier.org/comparison.html
私はそうは思いません。Html Encode は、すべての機能文字 (ブラウザーがコードとして解釈できる文字) を、ブラウザーが解析できないため実行できないエンティティ参照に変換します。
<script/>
上記をブラウザで実行する方法はありません。
**もちろん、ブラウザのバグでない限り.*
myString.replace(/<[^>]*>?/gm, '');
私はそれを使用し、それから成功しました。 テキスト JavaScript から HTML を取り除く