Web Security Scanner の検出結果の修正

このページでは、Web Security Scanner の結果を解釈、再現、修正する方法について説明します。

Security Command Center の IAM ロールは、組織レベル、フォルダレベル、またはプロジェクト レベルで付与できます。検出結果、アセット、セキュリティ ソースを表示、編集、作成、更新する権限は、アクセス権が付与されているレベルによって異なります。Security Command Center のロールの詳細については、アクセス制御をご覧ください。

脆弱性クラス

Web Security Scanner によって、次のクラスの脆弱性が検出されます。

  • クロスサイト スクリプティング（XSS）
  • サーバーサイドのリクエスト フォージェリ
  • Flash インジェクション
  • 混合コンテンツ
  • 古いライブラリや脆弱なライブラリ
  • クリアテキストのパスワード
  • 保護されていないオリジンの検証
  • 無効なヘッダー
  • ヘッダーのスペルミス
  • アクセス可能なリポジトリ
  • SQL インジェクション
  • XML インジェクション
  • プロトタイプ汚染

こうした脆弱性が検出された場合は、結果がハイライト表示され、詳しい情報を確認できます。

ログへの影響

Web Security Scanner スキャンのトレースは、ログファイルに記録されます。たとえば、Web Security Scanner は ~sfi9876 や /sfi9876 などの一見意味のない文字列のリクエストを生成します。このプロセスより、スキャンによるアプリケーションのエラーページを調査が可能になります。ログには、こうした意図的に無効なページ リクエストが記録されます。

修復後の検出結果の無効化

脆弱性を修正した後、Web Security Scanner は、対応する Security Command Center の検出結果の状態を INACTIVE に自動設定しません。状態を手動で変更しない限り、Security Command Center で Web Security Scanner によって生成された検出結果の状態は ACTIVE のままです。

スタンドアロン バージョンの Web Security Scanner を使用している場合、脆弱性を修正した後に Web Security Scanner で検出できなくなると、後続の脆弱性レポートには脆弱性が含まれません。脆弱性の記録は、過去の脆弱性レポートに残ります。

Web Security Scanner は、マネージド スキャンを毎週実行します。

Web Security Scanner のスキャンの詳細については、スキャンのタイプをご覧ください。

Web Security Scanner の検出結果の修正

このセクションでは、さまざまなタイプの Web Security Scanner の検出結果の修正方法について説明します。OWASP トップ 10 で解説されている一般的なアプリケーション レベルの攻撃から防御するための戦略については、Google Cloud における OWASP トップ 10 緩和策をご覧ください。

XSS

API のカテゴリ名: XSS

Web Security Scanner のクロスサイト スクリプティング（XSS）インジェクション テストでは、悪意のないテスト文字列を編集可能なフィールドに挿入し、さまざまな操作を行うことで、インジェクション攻撃をシミュレートします。このテストを実行すると、カスタムの検知機能がブラウザと DOM を監視して、インジェクションの成否を判断し、悪用の危険性を評価します。

テスト文字列内に含まれている JavaScript が正常に実行された場合は、Chrome デバッガが起動します。テスト文字列を実行できたため、このページに JavaScript を挿入して実行できます。この問題を攻撃者に知られた場合、攻撃者は悪意のあるリンクをクリックしたユーザー（被害者）として、任意の JavaScript を実行できるようになります。

状況によっては、ブラウザでテスト文字列が解析される前に、テスト対象アプリケーションによってテスト文字列が変更されることがあります。たとえば、アプリケーションによる入力の検証や、フィールドのサイズ制限が行われる可能性があります。ブラウザがこの変更されたテスト文字列を実行しようとすると、ブラウザの動作が中断し、JavaScript 実行エラーがスローされる可能性があります。これはインジェクションの問題が発生したことを示します。ただし、これは必ずしも悪用可能とは限りません。

この問題に対応するには、テスト文字列の変更を回避できるかどうかを手動で検証して、この問題が XSS の脆弱性であるかどうかを確認する必要があります。この脆弱性を確認する方法の詳細については、クロスサイト スクリプティングをご覧ください。

この問題を修正するにはさまざまな方法があります。すべての出力をエスケープし、状況に応じた自動エスケープをサポートするテンプレート生成システムを使用することをおすすめします。

XSS angular callback

API のカテゴリ名: XSS_ANGULAR_CALLBACK

ユーザー指定の文字列が Angular によって補完されている場合は、AngularJS モジュールのクロスサイト スクリプティング（XSS）の脆弱性が発生する可能性があります。ユーザー指定の値を AngularJS の補間に挿入すると、次のような攻撃を招くおそれがあります。

  • 攻撃者が、ブラウザによってレンダリングされたページに任意のコードを挿入する。
  • 攻撃者が、攻撃対象のブラウザに代わってページの送信元でアクションを実行する。

この潜在的な脆弱性を再現するには、スキャンを実行した後に、Google Cloud Console で再現 URL のリンクを使用してください。このリンクはアラート ダイアログを直接開くか、文字列 XSSDETECTED を挿入して、攻撃でコードを実行できることを証明します。文字列が挿入される場合、ブラウザのデベロッパー ツールを開き、XSSDETECTED を検索して挿入の正確な位置を特定できます。

XSS error

API のカテゴリ名: XSS_ERROR

XSS_ERROR の検出は、JavaScript の破損に起因する XSS バグの可能性があります。状況によっては、ブラウザで解析される前に、テスト対象アプリケーションがテスト文字列を変更してしまうこともあります。ブラウザがこの変更されたテスト文字列を実行しようとすると、ブラウザの動作が中断し、JavaScript 実行エラーがスローされる可能性があります。このエラーはインジェクションの問題が発生したことを示します。ただし、これは必ずしも悪用可能とは限りません。

この問題に対応するには、テスト文字列の変更を回避できるかどうかを手動で検証して、この問題が XSS の脆弱性であるかどうかを確認する必要があります。この脆弱性を確認する方法の詳細については、クロスサイト スクリプティングをご覧ください。

Server side request forgery

API のカテゴリ名: SERVER_SIDE_REQUEST_FORGERY

SERVER_SIDE_REQUEST_FORGERY の脆弱性により、ウェブ アプリケーション ユーザーは、制限されたサービス エンドポイントに強制的にリクエストを送信（HTTP リクエストなど）することで、内部データにアクセスできます。たとえば、攻撃者はこの脆弱性を悪用して、Google Cloud メタデータ サービスからデータを取得できます。

この問題を解決するには、許可リストを使用して、ウェブ アプリケーションがリクエストできるドメインと IP アドレスを制限します。

Rosetta flash

API のカテゴリ名: ROSETTA_FLASH

Web Security Scanner により、リクエスト パラメータの値が、レスポンスの先頭で表される（たとえば、JSONP を使用するリクエスト）と認識される場合があります。この脆弱性はフラッシュ インジェクションとも呼ばれます。攻撃者は、ブラウザでレスポンスを実行するときに、そのレスポンスを脆弱性があるウェブ アプリケーションから提供された Flash ファイルであるかのように見せかける場合があります。

この問題を修正するには、HTTP レスポンスの先頭にユーザーが制御可能なデータを含めないようにします。

Mixed content

API のカテゴリ名: MIXED_CONTENT

Web Security Scanner は HTTP トラフィックをパッシブに監視し、JavaScript や CSS ファイルに対するリクエストが HTTPS ページのコンテキストでありながら HTTP 経由で実行された場合に報告します。このシナリオでは、中間者攻撃によって HTTP リソースが改ざんされ、リソースを読み込んでいるウェブサイトへの完全なアクセス権が取得されるか、ユーザーの操作をモニタリングされるおそれがあります。

これを修正するには、HTTP の相対リンクを使用します。たとえば、http:// を // に置き換えます。

Outdated library

API のカテゴリ名: OUTDATED_LIBRARY

Web Security Scanner により、含まれているライブラリのバージョンに既知のセキュリティの問題があると判断される場合があります。Web Security Scanner は、シグネチャベースのスキャナと呼ばれるもので、使用中のライブラリのバージョンを特定し、そのバージョンを脆弱性があるライブラリの既知のリストと照合します。バージョンの検出に失敗した場合や、ライブラリに手動でパッチが適用されている場合は、誤検知が発生する可能性もあります。

この問題を解決するには、ライブラリを既知の安全なバージョンに更新します。

Struts insecure deserialization

API のカテゴリ名: STRUTS_INSECURE_DESERIALIZATION

Web Security Scanner により、ウェブ アプリケーションがリモート コマンド インジェクション攻撃に対して脆弱な Apache Struts バージョンを使用している可能性があると報告される場合があります。影響を受けた Struts のバージョンが、攻撃者の無効な Content-Type HTTP ヘッダーを誤って解析する可能性があります。この脆弱性により、悪意のあるコマンドはウェブサーバーの権限で実行できます。

脆弱性のある Apache Struts のバージョンは次のとおりです。

  • 2.3.32 より前の 2.3.x バージョン
  • 2.5.10.1 より前の 2.5.x バージョン

この問題を解決するには、Apache Struts を最新バージョンにアップグレードしてください。

Apache Struts の脆弱性の詳細については、CVE-2017-5638 をご覧ください。

Cacheable password input

API のカテゴリ名: CACHEABLE_PASSWORD_INPUT

Web Security Scanner により、パスワード入力に対して、ウェブ アプリケーションで type 属性を password に設定していない <input> 要素が使用されていると判断される場合があります。この場合、ブラウザが、ユーザーが入力したパスワードを安全なパスワード ストレージではなく、通常のブラウザ キャッシュに保存します。

この問題を解決するには、<input> 要素に type 属性を追加して password に設定します（例: <input type="password">）。この属性は、ユーザーがパスワード フィールドに入力する文字を非表示にします。

Clear text password

API のカテゴリ名: CLEAR_TEXT_PASSWORD

Web Security Scanner により、アプリケーションがパスワード フィールドをクリアテキスト形式で送信している可能性があると報告される場合があります。攻撃者によってネットワーク トラフィックが傍受されて、パスワード フィールドが盗聴される可能性があります。

クライアントとサーバー間で渡される機密情報を保護するには、常に次の予防措置を講じます。

  • TLS 証明書または SSL 証明書を使用します。
  • パスワード フィールドを含むページでは常に HTTPS を使用します。
  • フォーム アクションの属性では常に HTTPS URL を指定します。

Insecure allow origin ends with validation

API のカテゴリ名: INSECURE_ALLOW_ORIGIN_ENDS_WITH_VALIDATION

Web Security Scanner により、クロスサイト HTTP または HTTPS エンドポイントが Origin リクエスト ヘッダーのサフィックスのみを検証し、それを Access-Control-Allow-Origin レスポンス ヘッダーに反映させていることが検出される場合があります。検証が正しく構成されていないと、許可リストに登録されているドメインと同じサフィックスの悪質ドメインへのアクセスがエンドポイントで許可される可能性があります。たとえば、エンドポイント バリデータが *google.com などのドメインを照合するときに、誤って maliciousdomaingoogle.com にアクセス権が付与されることがあります。

この問題を解決するには、想定どおりのルートドメインが Access-Control-Allow-Origin レスポンス ヘッダーに反映される前に、Origin ヘッダー値の一部になっていることを確認します。サブドメインのワイルドカードの場合は、ルートドメインに先頭にドットを追加します（例: .endsWith(".google.com")）。

Insecure allow origin starts with validation

API のカテゴリ名: INSECURE_ALLOW_ORIGIN_STARTS_WITH_VALIDATION

Web Security Scanner により、クロスサイト HTTP または HTTPS エンドポイントが Origin リクエスト ヘッダーのプリフィックスのみを検証し、それを Access-Control-Allow-Origin レスポンス ヘッダーに反映させていることが検出される場合があります。検証が正しく構成されていないと、許可リストに登録されているドメインと同じプリフィックスの悪質ドメインへのアクセスがエンドポイントで許可される可能性があります。たとえば、エンドポイント バリデータにより、要求側のドメインに google.com が含まれているかどうかのみが検証される場合、誤って google.com.maliciousdomain.com にアクセス権が付与されることがあります。

この検出結果を解決するには、想定どおりのドメインが Access-Control-Allow-Origin レスポンス ヘッダーに反映される前に、Origin ヘッダー値に完全に一致しているかどうか確認します。例: .equals(".google.com")

Session ID leak

API のカテゴリ名: SESSION_ID_LEAK

Web Security Scanner により、ウェブ アプリケーションのクロスドメイン リクエストの Referer リクエスト ヘッダーでセッション識別子が検出されることがあります。Referer を受信するドメインは、セッション ID を使用して（トークンを使用して）ユーザーの権限を借用するか、ユーザーを一意に識別することができます。

検出結果を修正するには、セッション ID を URL ではなく Cookie に格納します。また、以下の属性を使って Cookie を保護します。

  • HTTPOnly: Cookie がクライアント側のスクリプトにアクセスできなくする属性
  • Secure: Cookie を HTTPS でのみ転送可能にする属性。

Invalid content type

API のカテゴリ名: INVALID_CONTENT_TYPE

Web Security Scanner により、レスポンスの Content-Type HTTP ヘッダーと一致しないリソースが読み込まれたと判断される場合があります。このシナリオでは、アプリケーションは無効なコンテンツ タイプを含む機密コンテンツ、または X-Content-Type-Options: nosniff ヘッダーのない機密コンテンツを返します。

この問題を解決するには、次のことを行います。

  • JSON レスポンスが Content-Type ヘッダー application/json で返されるようにする
  • その他の機密情報を含むレスポンスが適切な MIME タイプで返される
  • コンテンツ提供に HTTP ヘッダー X-Content-Type-Options: nosniff が使用されるようにする

Invalid header

API のカテゴリ名: INVALID_HEADER

Web Security Scanner により、セキュリティ ヘッダーで構文エラーが検出され、ヘッダーの形式が正しくないか、無効と判断されることがあります。その結果、これらのヘッダーはブラウザによって無視されます。

以降のセクションでは、有効なヘッダーについて説明します。

Referrer-Policy ヘッダー

有効なリファラー ポリシーには、次のいずれかの値が含まれます。

  • 空の文字列
  • no-referrer
  • no-referrer-when-downgrade
  • same-origin
  • origin
  • strict-origin
  • origin-when-cross-origin
  • strict-origin-when-cross-origin
  • unsafe-url

X-Frame-Options ヘッダー

有効な X-Frame-Options ヘッダーには、次の値のみが含まれます。

  • DENY: すべてのフレーム処理を禁止
  • SAMEORIGIN: トップレベルの URL が同一の基点である場合にフレーム処理を許可
  • ALLOW-FROM URL

Chrome は ALLOW-FROM URL では使用できません。複数の X-Frame-Options は許可されません。

X-Content-Type-Options ヘッダー

有効な X-Content-Type-Options ヘッダーに含めることができる値は nosniff のみです。

X-XSS-Protection ヘッダー

有効な X-XSS-Protection ヘッダーは 0（「無効」）または 1（「有効」）で始まっている必要があります。そのうえで、保護を有効にする場合にのみ、最大 2 つのオプションを追加できます。

  • mode=block は、XSS をフィルタリングする代わりに、空白ページを表示する
  • report=URL は URL にレポートを送信する

オプションはセミコロンで区切ります（例: 1; mode=block; report=URI）。末尾にセミコロンがないことに注意してください。

Misspelled security header name

API のカテゴリ名: MISSPELLED_SECURITY_HEADER_NAME

Web Security Scanner によって、セキュリティ ヘッダー名のスペルミスが検出されることがあります。スペルミスがあるとそのセキュリティ ヘッダーは無効になるので、修正する必要があります。

この脆弱性を再現するには、ブラウザのデベロッパー ツールの [ネットワーク] タブでスペルミスをチェックしてください。

Mismatching security header values

API のカテゴリ名: MISMATCHING_SECURITY_HEADER_VALUES

Web Security Scanner により、レスポンスに重複して値が競合するセキュリティ関連のレスポンス ヘッダーがあると判断される場合があります。一部のセキュリティ関連の HTTP ヘッダーでは、一致しない値とともにレスポンスで 2 回宣言された場合、未定義の動作が行われます。

この問題を修正するには、これらの一致していないヘッダーのいずれか 1 つだけを残します。

アクセス可能なリポジトリ

Web Security Scanner により、アプリケーション内でアクセス可能な GIT または SVN リポジトリを検出する場合があります。この状態により、構成やソースコードの漏洩が発生する可能性があります。

この脆弱性を再現するには、検出結果レポートの再生用 URL をクリックしてください。

XXE reflected file leakage

API のカテゴリ名: XXE_REFLECTED_FILE_LEAKAGE

Web Security Scanner により、ユーザー入力から XML を解析するウェブ アプリケーションで XML 外部エンティティ（XXE）の脆弱性が見つかることがあります。攻撃者から外部エンティティを含む XML が提供される可能性があります。この外部エンティティは、アプリケーションがアクセスできるコンテンツ（アプリケーションのホストマシン上のファイルなど）を参照できます。アプリケーションの XML パーサーが悪質な XML を処理し、ホスト上のファイルの内容が流出する可能性があります。

この検出結果を解決するには、外部エンティティを許可しないように XML パーサーを構成します。

この脆弱性の詳細については、XML 外部エンティティ（XXE）の処理をご覧ください。

SQL injection

API のカテゴリ名: SQL_INJECTION

Web Security Scanner により、SQL インジェクションの脆弱性が見つかることがあります。攻撃者は、サーバーで実行される SQL クエリのクエリ構造を操作する入力を作成できます。これらの入力を使用すると、データベースからデータを抽出することが可能になります。また、データが変更される可能性もあります。この問題を解決するには、パラメータ化されたクエリを使用して、ユーザー入力が SQL クエリの構造に影響を与えないようにします。

この脆弱性の詳細については、SQL インジェクションをご覧ください。

Prototype pollution

API のカテゴリ名: PROTOTYPE_POLLUTION

Web Security Scanner により、オブジェクト プロパティに攻撃者が制御可能な値が割り当てられているウェブ アプリケーションで、プロトタイプの汚染という脆弱性が見つかることがあります。攻撃者は、クロスサイト スクリプティングやその他のクライアント側の脆弱性に対してアプリケーションの脆弱性を高める入力を作成できます。

この脆弱性を修正するには、非推奨の proto プロパティを削除し、Object.prototype オブジェクトを不変にします。この軽減策がコードに適さない場合は、脆弱なコード部分を変更して、攻撃者が制御可能な入力から想定される値のみをコピーするようにしてください。

問題の確認

Web Security Scanner により問題が報告された場合は、問題の場所を確認する必要があります。このセクションでは、検出結果レポートを使用して脆弱性を再現し、検証する方法について説明します。

  1. Google Cloud コンソール の [Web Security Scanner] ページに移動します。

    Web Security Scanner に移動

  2. プロジェクトを選択します。ページにマネージド スキャンとカスタム スキャンのリストが表示されます。

  3. [スキャンの構成] で、確認する検出結果が含まれるスキャンを選択します。スキャンの詳細が記載されたページが開きます。

  4. [結果] タブに移動し、カテゴリを展開し、検出結果を選択して詳細を確認します。

  5. 確認方法は、検出結果のカテゴリによって異なります。テストブラウザを使用して、次の説明に沿って確認します。

    • クロスサイト スクリプティング: [再現 URL] では、ブラウザに空のポップアップが生成され、スキャンで良性のコードがスクリプトに正常に挿入されたことが示されます。
    • 古いライブラリ: [脆弱性がある URL] では、「Exploited」というテキストを含むページが返され、スキャンで良性のコードがスクリプトに正常に挿入されたことが示されます。
    • 混合コンテンツ: [HTTPS ページの URL] では、混合コンテンツの脆弱性に関する警告が返されます。検出結果レポートでは、[HTTP で提供されるリソースの URL] で、脆弱性があるリソースが識別されます。
    • Flash インジェクション: Web Security Scanner がこのカテゴリの検出結果を返すことがありますが、最新のブラウザのほとんどは Flash インジェクションから保護されています。こうした検出結果が悪用される可能性はまずありません。
    • プロトタイプの汚染: [再現 URL] フィールドの URL に従って、ペイロードによって生成された Object.prototype オブジェクトの変更を次の JavaScript スニペットで検索します
      • ({}).__secret_injected_property
      • ({}).__defineGetter__.__secret_injected_property
      • ({}).hasOwnProperty.__secret_injected_property

Content Security Policy（CSP）を適用していると、JavaScript コードの実行が阻止される場合があります。この状態によって、XSS の再現が難しくなることがあります。この問題が発生した場合は、ブラウザのログコンソールを開いて、発生した CSP 違反の詳細を確認してください。