Web Security Scanner は、App Engine、Google Kubernetes Engine(GKE)、Compute Engine の各ウェブ アプリケーションにおけるセキュリティの脆弱性と構成ミスを特定します。アプリケーションをクロールして、開始 URL の範囲内にあるすべてのリンクをたどり、できる限り多くのユーザー入力とイベント ハンドラを処理しようとします。Web Security Scanner は、ファイアウォールの背後にない、公開 URL と IP のみをサポートしています。
Web Security Scanner は、App Engine スタンダード環境と App Engine フレキシブル環境、Compute Engine インスタンス、GKE リソースをサポートしています。
Web Security Scanner は、既存の安全な設計プロセスと開発プロセスを補完することを目的に設計されています。誤検出があると注意がそがれるため、Web Security Scanner はあまり多くの情報が報告されないようになっています。また信頼度が低いアラートは表示されません。Cloud Security Scanner は、人によるセキュリティ レビューに置き換わるものではなく、アプリケーションにセキュリティの欠陥がないことを保証するものでもありません。
構成ミスとして分類された検出結果は、構成を更新することでユーザーの操作によって解決できる問題を表します。これらの検出結果はセキュリティ ポスチャーの改善に重要ですが、実際に悪用される可能性のある弱点を表す脆弱性とは異なります。これらの構成ミスは、Security Command Center の [検出結果] ページで確認できます。詳細については、Web Security Scanner の構成ミスに関する検出結果をご覧ください。
スキャンタイプ
Web Security Scanner は、一般公開された App Engine、GKE、Compute Engine のサービス対象ウェブ アプリケーションにマネージドおよびカスタムウェブ脆弱性スキャンを実行します。
マネージド スキャン
Web Security Scanner のマネージド スキャンは Security Command Center によって構成され、管理されます。マネージド スキャンは、週に 1 回自動的に実行され、一般公開のウェブ エンドポイントを検出してスキャンします。このスキャンは認証を使用せず、公開ウェブサイトにはフォームを送信しないので、GET のみのリクエストを送信します。
マネージド スキャンはカスタム スキャンとは別に実行されます。
Security Command Center を組織レベルで有効にすると、マネージド スキャンを使用して、個々のプロジェクト チームを関与させることなく、組織内のプロジェクトの基本ウェブ アプリケーションの脆弱性検出を一元管理できます。検出が見つかったら、それらのチームと協力してより包括的なカスタム スキャンを設定できます。
Web Security Scanner をサービスとして有効にする場合、マネージド スキャンの検出結果は、Security Command Center の [脆弱性] ページと関連レポートで自動的に利用可能になります。Web Security Scanner のマネージド スキャンを有効にする方法については、Security Command Center サービスを構成するをご覧ください。
マネージド スキャンは、デフォルトのポート(HTTP 接続の場合は 80、HTTPS 接続の場合は 443)を使用するアプリケーションのみをサポートします。アプリケーションがデフォルト以外のポートを使用している場合は、代わりにカスタム スキャンを行います。
カスタム スキャン
Web Security Scanner のカスタム スキャンは、古いライブラリ、クロスサイト スクリプティング、混合コンテンツの使用など、アプリケーションの脆弱性の検出に関する詳細な情報を提供します。
カスタム スキャンはプロジェクト レベルで定義します。
Web Security Scanner のカスタム スキャンを設定するためのガイドを完了すると、Security Command Center でカスタム スキャンによる検出が可能になります。
スキャンの検出結果
このセクションでは、Web Security Scanner の検出結果のタイプと関連するコンプライアンス標準について説明します。
検出機能とコンプライアンス
Web Security Scanner は OWASP トップ 10 のカテゴリをサポートしています。これは、Open Web Application Security Project(OWASP)で決定される、ウェブ アプリケーションで最も重大な 10 個のウェブ アプリケーションのセキュリティ リスクをランク付けして修正するドキュメントです。
コンプライアンス マッピングは参照用として含まれており、OWASP Foundation による提供や審査は行われません。この機能は、コンプライアンス制御違反をモニタリングするためのものです。このマッピングは、規制、業界ベンチマーク、標準に準拠した製品またはサービスの監査、認定、コンプライアンス報告の基礎として使用できるものでも、これらの代用として使用できるものでもありません。
コンプライアンスの詳細については、セキュリティ ベンチマークのコンプライアンスを評価して報告するをご覧ください。
検出結果のタイプ
Web Security Scanner のカスタム スキャンとマネージド スキャンでは、次のタイプの検出結果が識別されます。スタンダード ティアの Web Security Scanner は、ファイアウォールの背後にない公開 URL と IP でデプロイされたアプリケーションのカスタム スキャンをサポートしています。
カテゴリ | 検出結果の説明 | 検出結果のカテゴリ | OWASP 2017 Top 10 | OWASP 2021 Top 10 |
---|---|---|---|---|
|
Git リポジトリが一般公開されている。この検出結果を解決するには、GIT リポジトリへの意図しない公開アクセスを削除します。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A5 | A01 |
|
SVN リポジトリが一般公開されている。この検出結果を解決するには、SVN リポジトリへの意図しない公開アクセスを削除します。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A5 | A01 |
|
ENV ファイルが一般公開されています。この検出結果を解決するには、ENV ファイルへの意図しない公開アクセスを削除します。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A5 | A01 |
|
ウェブ アプリケーションに入力したパスワードは、安全なパスワード ストレージではなく、通常のブラウザ キャッシュに保存できます。 料金ティア: プレミアム |
脆弱性 | A3 | A04 |
|
パスワードがクリアテキストで送信されているため、傍受される可能性がある。この検出結果を解決するには、ネットワーク経由で送信されたパスワードを暗号化します。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A3 | A02 |
|
クロスサイト HTTP または HTTPS エンドポイントは、 料金ティア: プレミアム |
脆弱性 | A5 | A01 |
|
クロスサイト HTTP または HTTPS エンドポイントは、 料金ティア: プレミアム |
脆弱性 | A5 | A01 |
|
レスポンスの Content-Type HTTP ヘッダーに一致しないリソースが読み込まれた。この検出結果を解決するには、 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A6 | A05 |
|
セキュリティ ヘッダーに構文エラーがあり、ブラウザで無視される。この検出結果を解決するには、HTTP セキュリティ ヘッダーを正しく設定します。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A6 | A05 |
|
セキュリティ ヘッダーが重複し、値が一致しないため、未定義の動作が起こる。この検出結果を解決するには、HTTP セキュリティ ヘッダーを正しく設定します。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A6 | A05 |
|
セキュリティ ヘッダーにスペルミスがあるため、無視される。この検出結果を解決するには、HTTP セキュリティ ヘッダーを正しく設定します。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A6 | A05 |
|
HTTPS ページ上で HTTP を介してリソースが提供されている。この検出結果を解決するには、すべてのリソースが HTTPS を介して提供されるようにします。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A6 | A05 |
|
既知の脆弱性があるライブラリが検出された。この検出結果を解決するには、ライブラリを新しいバージョンにアップグレードします。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A9 | A06 |
|
サーバーサイドのリクエスト フォージェリ(SSRF)の脆弱性が検出された。この検出結果を解決するには、許可リストを使用して、ウェブ アプリケーションがリクエストできるドメインと IP アドレスを制限します。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | 該当なし | A10 |
|
クロスドメイン リクエストを行う場合は、ウェブ アプリケーションの 料金ティア: プレミアム |
脆弱性 | A2 | A07 |
|
潜在的な SQL インジェクション脆弱性が検出された。この検出結果を解決するには、パラメータ化されたクエリを使用して、ユーザー入力が SQL クエリの構造に影響を与えないようにします。 料金ティア: プレミアム |
脆弱性 | A1 | A03 |
|
脆弱なバージョンの Apache Struts の使用が検出された。この検出結果を解決するには、Apache Struts を最新バージョンにアップグレードしてください。 料金ティア: プレミアム |
脆弱性 | A8 | A08 |
|
このウェブ アプリケーションのフィールドは、クロスサイト スクリプティング(XSS)攻撃に対して脆弱である。この検出結果を解決するには、信頼されていないユーザーが提供したデータを検証してエスケープします。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A7 | A03 |
|
ユーザーが指定した文字列がエスケープされず、AngularJS によって補間される場合がある。この検出結果を解決するには、信頼されていないユーザーが指定し、Angular フレームワークによって処理されたデータを検証してエスケープします。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A7 | A03 |
|
このウェブ アプリケーションのフィールドは、クロスサイト スクリプティング攻撃に対して脆弱である。この検出結果を解決するには、信頼されていないユーザーが提供したデータを検証してエスケープします。 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A7 | A03 |
|
XML 外部エンティティ(XXE)の脆弱性が検出された。この脆弱性により、ウェブ アプリケーションによりホスト上のファイルが漏洩する可能性があります。この検出結果を解決するには、外部エンティティを許可しないように XML パーサーを構成します。 料金ティア: プレミアム |
脆弱性 | A4 | A05 |
|
このアプリケーションはプロトタイプ汚染に対して脆弱性があります。この脆弱性は、 料金ティア: プレミアムまたはスタンダード |
脆弱性 | A1 | A03 |
|
HTTP Strict Transport Security(HSTS)ヘッダーの構成ミスが検出されました。HTTP 接続でのダウングレード攻撃や盗聴攻撃のリスクを大幅に軽減するには、HSTS ヘッダーの構成ミスを解決します。HSTS ヘッダーは、暗号化されたチャネル(TLS)を介して接続を強制するため、平文 HTTP 接続は失敗します。HSTS ヘッダーの詳細 を確認してください
料金ティア: プレミアム |
構成ミス | 該当なし | 該当なし |
|
コンテンツ セキュリティ ポリシー(CSP)HTTP レスポンス ヘッダーがないことが検出されました。CSP ヘッダーは、信頼できないスクリプトやプラグインが読み込まれないようにすることで、一般的なウェブの脆弱性、特にクロスサイト スクリプティング(XSS)の悪用を軽減します。厳格な CSP ヘッダーを使用することをおすすめします。CSP ヘッダーの詳細 を確認してください
料金ティア: プレミアム |
構成ミス | 該当なし | 該当なし |
|
コンテンツ セキュリティ ポリシー(CSP)HTTP レスポンス ヘッダーの構成ミスが検出されました。CSP ヘッダーは、信頼できないスクリプトやプラグインが読み込まれないようにすることで、一般的なウェブの脆弱性、特にクロスサイト スクリプティング(XSS)の悪用を軽減します。厳格な CSP ヘッダーを使用することをおすすめします。CSP ヘッダーの詳細 を確認してください
料金ティア: プレミアム |
構成ミス | 該当なし | 該当なし |
|
Cross-Origin-Opener-Policy(COOP)HTTP ヘッダーがないことが検出されました。COOP は、新しいウィンドウで開かれたページが元のページのプロパティにアクセスすることを制限するウェブ セキュリティ メカニズムです。COOP は、一般的なウェブ攻撃に対する保護を強化します。
料金ティア: プレミアム |
構成ミス | 該当なし | 該当なし |
|
レスポンス ヘッダーがないことが検出されました。クリックジャッキングを防ぐには、
料金ティア: プレミアム |
構成ミス | 該当なし | 該当なし |
使用上の注意
Security Command Center の IAM ロールは、組織レベル、フォルダレベル、またはプロジェクト レベルで付与できます。検出結果、アセット、セキュリティ ソースを表示、編集、作成、更新する権限は、アクセス権が付与されているレベルによって異なります。Security Command Center のロールの詳細については、アクセス制御をご覧ください。
Web Security Scanner を使用するときは、その他の重要点に留意してください。
- Web Security Scanner は現在も継続的に改善が進められているため、現在のスキャンでは報告されない問題が今後報告される可能性があります。
- アプリケーションの機能やセクションをすべてテストしているとは限りません。
- Web Security Scanner は、検出するすべてのコントロールと入力の有効化と試みます。
- Web Security Scanner は、IPv4 を使用するウェブサイトのみをサポートしています。IPv6 を使用しているウェブサイトはスキャンされません。
- テスト アカウントが権限を持つ状態変更アクションを公開した場合、Web Security Scanner はそのアクションを有効にすることがあります。これは望ましくない結果につながる可能性があります。
- Web Security Scanner のスキャンには、プロジェクトごとに 15 までという制限があります。スキャンは同時に実行されるため、この制限に達した場合は、スキャンごとに複数の開始 URL を追加するか、まだ制限に達していない別のプロジェクトにスキャンを追加することをおすすめします。
セキュリティ スキャンを実行できるユーザー
Web Security Scanner で使用できる Identity and Access Management(IAM)のロールについては、アクセス制御をご覧ください。
セキュリティ スキャンにかかる時間
セキュリティ スキャンはすぐには実行されません。まずキューに追加され、後で実行されます。そのため、システム負荷によっては数時間後になる場合もあります。スキャンの実行が始まったら、その所要時間はアプリケーションのサイズによって異なります。多くの URL が含まれた大規模なアプリケーションのスキャンには、数時間から数日かかることがあります。スキャンが 20 日以内に完了しなかった場合、スキャンは自動的に停止され、スキャン中に検出されたすべてのクロール結果と検出結果がスキャン結果として表示されます。
ターゲットの制限
Web Security Scanner には、スキャンのターゲットをスキャンが作成される特定の App Engine インスタンスに制限するフィルタが導入されています。別の App Engine プロジェクトや外部ドメインの URL を入力すると、エラー メッセージが表示されます。
Compute Engine と GKE のスキャンは、同じプロジェクト用に予約された静的外部 IP アドレスと、同じプロジェクトに属する静的外部 IP アドレスにマッピングされるドメインに限定されます。プロジェクトの IP アドレスを予約する方法については、次のリンクをご覧ください。
Compute Engine: 静的外部 IP アドレスの予約
App Engine には、静的 IP アドレスをアプリにマッピングする方法は用意されていません。ただし、Cloud Load Balancing とサーバーレス ネットワーク エンドポイント グループを使用すると、ロードバランサの静的 IP アドレスを予約して、トラフィックをアプリケーションに転送できます。料金については、ネットワーキングのすべての料金体系をご覧ください。
プロジェクト内では、Web Security Scanner はログアウト URL と、スキャンに悪影響を与える可能性があるその他の汎用的な場所を自動的に回避しようとします。ただし、これを確実に行うため、スキャン設定を使用して手動で URL を除外することもできます。
検証
スキャンの構成は、作成時と各スキャンの前に検証されます。スキャンが正しく構成され、アプリケーションに正常にログインできるようにするため、Web Security Scanner は、Security Command Center の設定とアプリケーションの認証情報を確認します。サポートの範囲内に抑えるため、最大スキャン速度などの構成パラメータも確認されます。
スキャンを作成または更新する前に、エラーを解決する必要があります。初期構成後に変更されたアプリケーションでは、スキャン中にエラーが発生する可能性があります。たとえば、プロジェクトが所有する IP アドレスをドメインが参照していない場合、リソースはスキャンされず、スキャンの構成ページにエラーが報告されます。
ベスト プラクティス
Web Security Scanner を使用すると、フィールドに値が入力される、ボタンが押される、リンクがクリックされる、などのユーザー アクションが行われるため、特に本番環境のリソースをスキャンする際には注意が必要です。また、データやシステムの状態を変更する機能が有効になる可能性があり、望ましくない結果がもたらされる場合があります。
例:
- ブログ アプリケーションで一般からのコメントを受け付けるようにしていると、Web Security Scanner がすべてのブログ記事にコメントとしてテスト文字列を投稿する場合があります。
- メール登録ページで、Web Security Scanner によって多数のテストメールが生成される場合があります。
望ましくない結果を避けるために、個別または組み合わせて使用できる手法を以下に紹介します。
- テスト環境でスキャンを実行します。テスト環境を設定するには、別途 App Engine プロジェクトを作成し、このプロジェクトにアプリケーションとデータを読み込みます。Google Cloud CLI を使用する場合、アプリをアップロードするときにコマンドライン オプションとしてターゲット プロジェクトを指定できます。
- テスト アカウントを使用します。機密データへのアクセスや有害な操作を実行できないユーザー アカウントを作成し、アプリのスキャン時に使用します。多くのアプリケーションでは、ユーザーが初めてログインしたときに、利用規約の同意やプロフィールの作成などの特別なワークフローが提示されます。ワークフローが異なるために、初期ユーザーのテスト アカウントで生成されるスキャン結果が、確立したユーザー アカウントのものとは異なる場合があります。最初のフローが完了した後、アカウントが通常のユーザー状態のときにスキャンを実行することをおすすめします。
- CSS クラス
inq-no-click
を適用して、有効にしない個々のユーザー インターフェース要素をブロックできます。この要素に関連付けられたイベント ハンドラがインラインの JavaScript か、addEventListener
を使用して関連付けられているか、適切なイベント ハンドラのプロパティの設定で関連付けられているかにかかわらず、これらのハンドラはクロールやテストの間に有効になりません。 - バックアップ データを使用します。スキャンする前にデータのバックアップを検討してください。
- URL を除外します。クロールやテストを行わない URL パターンを指定できます。構文については、URL の除外をご覧ください。
スキャンする前に、スキャンする範囲を超えてデータやユーザーやシステムに影響を及ぼす可能性がある機能がないか慎重にアプリケーションを調べてください。
次のステップ
- Web Security Scanner の使用を開始する。