0

SO でのクロスサイト スクリプティングに関して多くの質問があることを理解しており、最も投票されたものを読み込もうとしました。いくつかの Web ページも読んだことがありますが、この攻撃の種類が使用できるすべての可能性についてまだ確信が持てません。入力をサニタイズする方法を尋ねるのではなく、何が期待できるかを尋ねます。

SO および他のページに示されているほとんどの例には 2 つの方法があり、最も単純な方法 (たとえば、これは PHPMaster のもの<script>)は、Cookie を盗むために使用されるコードを挿入することです。

ここでユーザー Babaが提示したもう 1 つの方法は、完全なコード構造を挿入する<form>ことですが、ユーザーがフォームを送信するまでは機能しないようですが、JavaScript イベントのようなもの... onmouseover='form.submit()'...が使用される可能性があります。

私が確認できたすべてのネットワークの例は、JavaScript コードを使用した方法にすぎません。

他の方法を使用することは可能ですか。たとえば、何らかの方法で HTML を変更したり、サーバー側のスクリプトを変更したりすることはできますか?

SQL インジェクションまたはサーバーのハッキングによってこれを取得できることは知っていますが、GET、POST リクエスト、またはその他のリクエストを操作する (誤って処理する) ことによってのみ意味しますか?

4

3 に答える 3

2

クロスサイト スクリプティングは、JavaScript コードを Web ページに挿入するだけではありません。これは、脆弱な Web ページのコンテキストでブラウザによって解釈されるコードの挿入の一般的な用語です。CWE-79を参照してください。

ページ生成中、アプリケーションは、JavaScript、HTML タグ、HTML 属性、マウス イベント、Flash、ActiveX など、Web ブラウザで実行可能なコンテンツがデータに含まれることを防ぎません。

たとえば、攻撃者は独自のログイン フォームを既存のログイン ページに挿入し、資格情報を自分のサイトにリダイレクトする可能性があります。これは XSS とも呼ばれます。

ただし、JavaScript を挿入すると、ドキュメントと被害者のブラウザーの両方を制御できるため、多くの場合、JavaScript を挿入する方が簡単で有望です。JavaScript を使用すると、攻撃者は Cookie を読み取って被害者のセッション Cookie を盗み、被害者のセッションを乗っ取ることができます。場合によっては、攻撃者は被害者のマシンで任意のコマンドを実行することさえできます。

XSS の攻撃ベクトルはさまざまですが、不適切に処理された入力によって可能になるという共通点があります。これは、GET または POST を介して提供されるパラメーターによるものですが、HTTP 要求に含まれるその他の情報 (Cookie やその他の HTTP ヘッダー フィールドなど) によるものもあります。単一の注入ポイントを使用するものもあれば、複数の注入ポイントに分割するものもあります。直接的なものもあれば、間接的なものもあります。自動的にトリガーされるものもあれば、特定のイベントが必要なものもあります。等

于 2013-05-17T18:08:56.367 に答える
1

XSS は JavaScript に関するものです。

ただし、悪意のある JavaScript コードを挿入するには、サーバーまたはクライアント側にあるページ コードの脆弱性を利用する必要があります。

CSP (コンテンツ セキュリティ ポリシー)を使用して、最新のブラウズで XSS を防ぐことができます。

XSS Cheat Sheetにも XSS トリックのリストがあります。ただし、これらのトリックのほとんどは、最新のブラウザーでは機能しません。

リクエストの一部でもある場合、Webkit は JavaScript を実行しません。たとえばdemo.php?x=<script>alert("xss")</script>、script タグが dom に挿入されても、アラート ボックスは表示されません。代わりに、次のエラーがスローされます。「JavaScript スクリプトの実行を拒否しました。リクエスト内にスクリプトのソース コードが見つかりました。」

于 2013-05-17T14:49:04.077 に答える
1

SQL インジェクションまたはサーバーのハッキングによってこれを取得できることは知っていますが、GET、POST リクエスト、またはその他のリクエストを操作する (誤って処理する) ことによってのみ意味しますか?

GET パラメータと POST ボディは、HTTP リクエストを介して Web アプリケーションを攻撃するための主要なベクトルですが、他にもあります。ファイルのアップロードに注意しないと、トロイの木馬をアップロードできる可能性があります。アップロードされたファイルをウェブサイトと同じドメインで単純にホストする場合は、JS または HTML をアップロードして、同じオリジンの権限で実行できます。リクエスト ヘッダーも攻撃者が操作する可能性のある入力ですが、それらを悪用する攻撃が成功したことは知りません。

コード インジェクションは、XSS、SQL インジェクション、シェル インジェクションなどを含む攻撃のクラスです。

攻撃者によって制御される GET または POST パラメーターがコードまたはプログラミング言語のシンボルに変換されるたびに、コード インジェクションの脆弱性が発生する危険があります。

GET または POST パラメーターが単純に SQL の文字列に挿入されると、SQL インジェクションのリスクがあります。

GET または POST パラメーター (またはファイル アップロードのファイル名のようなヘッダー) がシェルに渡されると、シェル インジェクションとファイル インクルードのリスクが生じます。

アプリケーションがサーバー側の言語に相当evalする信頼できないパラメーターを使用する場合、サーバー側のスクリプト インジェクションのリスクがあります。

すべての入力を疑い、それらをプレーン テキスト文字列として扱い、別の言語で文字列を作成するときは、エスケープしてプレーン テキスト文字列をそのターゲット言語の部分文字列に変換する必要があります。フィルタリングは、ここで多層防御を提供できます。

XSS - JavaScript を使用することによってのみ可能ですか?

いいえ。VBScript は IE に挿入できます。Javascript は、URL および CSS を介して間接的に挿入できます。挿入された画像は、リファラー URL に隠された秘密を漏らす可能性があります。挿入されたメタ タグまたは iframe は、サイトのフィッシング バージョンにリダイレクトされる可能性があります。

HTTP 応答ヘッダーの分割に対して脆弱なシステムは、リダイレクト URL や Set-Cookie ディレクティブなどの応答ヘッダーに挿入された HTML およびスクリプトによって破壊される可能性があります。

HTML には非常に多くの言語が埋め込まれているため、信頼できないソースから HTML のスニペットを含める場合は十分に注意する必要があります。サイトに外部の HTML を含める必要がある場合は、ホワイトリストのサニタイザーを使用してください。

于 2013-05-17T15:19:23.017 に答える