クロスサイトスクリプティングのテスト

クロスサイトスクリプティング（XSS）は、アプリケーションが信頼できないデータを取得し、検証せずにクライアント（ブラウザー）に送信するたびに発生します。これにより、攻撃者は被害者のブラウザで悪意のあるスクリプトを実行し、ユーザーセッションの乗っ取り、Webサイトの改ざん、またはユーザーの悪意のあるサイトへのリダイレクトを引き起こす可能性があります。

簡単な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱点、技術的影響、およびビジネスへの影響を理解しましょう。

XSSの種類

Stored XSS −永続XSSとも呼ばれる保存されたXSSは、ユーザー入力がデータベース/メッセージフォーラム/コメントフィールドなどのターゲットサーバーに保存されたときに発生します。その後、被害者は保存されたデータをWebアプリケーションから取得できます。
Reflected XSS −非永続的XSSとも呼ばれる反映されたXSSは、ユーザー入力がWebアプリケーションによってエラーメッセージ/検索結果または要求の一部としてユーザーによって提供された入力ですぐに返され、ユーザー提供のデータを永続的に保存しない場合に発生します。
DOM Based XSS − DOMベースのXSSは、データのソースがDOMにあり、シンクもDOMにあり、データフローがブラウザーを離れることがない場合のXSSの形式です。

例

アプリケーションは、検証なしで構築に信頼できないデータを使用します。特殊文字はエスケープする必要があります。

http://www.webpage.org/task/Rule1?query=try

攻撃者は、ブラウザのクエリパラメータを次のように変更します-

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

ハンズオン

Step 1− Webgoatにログインし、クロスサイトスクリプティング（XSS）セクションに移動します。Stored Cross-site Scripting（XSS）攻撃を実行してみましょう。以下はシナリオのスナップショットです。

Step 2−シナリオに従って、シナリオ自体に記載されているように、パスワード「tom」を使用してTomとしてログインします。[プロファイルの表示]をクリックして、編集モードに入ります。トムは攻撃者なので、これらの編集ボックスにJavaスクリプトを挿入しましょう。

<script> 
   alert("HACKED")
</script>

Step 3 −更新が終了するとすぐに、トムは「ハッキングされました」というメッセージを含むアラートボックスを受け取ります。これは、アプリが脆弱であることを意味します。

Step 4 −シナリオに従って、jerry（HR）としてログインし、jerryが挿入されたスクリプトの影響を受けるかどうかを確認する必要があります。

Step 5 − Jerryとしてログインした後、以下に示すように「Tom」を選択し、「viewprofile」をクリックします。

ジェリーのアカウントからトムのプロフィールを見ている間、彼は同じメッセージボックスを受け取ることができます。

Step 6 −このメッセージボックスは単なる例ですが、実際の攻撃者はメッセージボックスを表示するだけではありません。

予防メカニズム

開発者は、データが配置される本文、属性、JavaScript、CSS、URLなどのHTMLコンテキストに基づいて、信頼できないすべてのデータを確実にエスケープする必要があります。
入力として特殊文字を必要とするアプリケーションの場合、それらを有効な入力として受け入れる前に、堅牢な検証メカニズムを導入する必要があります。