#概要
App Engine、GKE、GCE上で動作するWebアプリケーションに対して、脆弱性を検知するためのスキャンを実行できるツール。開始URLを指定することで、その中に存在する全てのリンクの中から、できる限り多くのユーザー入力とイベントハンドラ（ボタンやリンクのクリックなど）の実行を試みる。
このサービスは、OWASP（Open Web Application Security Project）などの脆弱性からアプリケーションを保護するために使用される。Web Security Scannerはアプリケーションに脆弱性がないと保証するわけではないので、セキュリティ対策の一環として使用することが推奨される。
※Web Security Scannerはファイアーウォールで保護されていないパブリックIP, パブリックURLのみをサポートしている。って書いてあるけど、後述するプレビュー版の機能を使用すれば、ファイアーウォールの背後にあるアプリケーションにもスキャンを実行できる。
OWASPについて
OWASPというものを初めて聞く人もいるかと思うので、OWASP Top10のドキュメントを軽くまとめる。OWASP Top10は、Webアプリケーションにとって最もCriticalな脆弱性を記述しているドキュメント。2017年版だが、Googleの公式ドキュメントで紹介されていたのでこれを使用する。
https://owasp.org/www-project-top-ten/
※ここでは脆弱性の概要だけを記述しており、コード例を用いた解説や対策は言及しない。いつかここで挙げられている脆弱性についての記事を出すかも。
No1. Injection
SQLインジェクションはよく聞くが、ここではOSインジェクションやLDAPインジェクションなども記述されている。インジェクションとは、悪意のあるユーザーがインプットフィールドなどで、コマンドやクエリをアプリケーションの内部に送信し、意図しないコマンドを実行させたり、適切な権限がないデータにアクセスしたりすること。
https://ja.wikipedia.org/wiki/SQL%E3%82%A4%E3%83%B3%E3%82%B8%E3%82%A7%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3
No2. Broken Authentication
認証やセッション管理を行うアプリケーションの機能が適切に実装されていないことにより、発生する脆弱性。攻撃者がパスワードや鍵を操作・取得したり、セッション情報から機密情報を取得したり、他の欠陥を使用して他のユーザーを乗っ取ったりすること。
No3. Sensitive Data Exposure
PIIや金融系の情報などの機密情報が適切に保護されていないことで、攻撃者により盗まれたり、変更を加えられたりすること。機密情報は保存時や転送時に暗号化などの処理を実装しないと、危険にさらされる可能性がある。
No4. XML External Entities(XXE)
XML構文の中で外部のエンティティを参照することにより発生する脆弱性。外部エンティティによって内部ファイルの公開やリモートでのコード実行やサービス拒否攻撃に使用される可能性が指摘されている。
https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing
No5. Broken Access Control
認証されたユーザーのみが行える操作を適切に制限できていないせいで、攻撃者が機密情報や他のユーザーのデータなどの承認されていないデータにアクセスできてしまうこと。Broken Authenticationと似ているが、これは「パスワードや鍵を変更・取得されることで、認証されているユーザーとしてアクセスされてしまうこと」なので少し異なる。Broken Access Controlは「そもそも適切に制限できていないこと」を表す。
No6. Security Misconfiguration
これはよく見られる脆弱性で、デフォルトの設定や不完全な設定、機密情報を含むエラーメッセージなどが原因となる脆弱性。OS、ライブラリ、アプリケーションは適切に設定されており、随時パッチやアップグレードが行われることが推奨される。
No7. XSS
ユーザーからのインプットを検証したり、エスケープしたりせずに新しいWebページで表示させることで、攻撃者がそのWebサイトの訪問者に悪意のあるスクリプトを実行させるように誘導することを許してしまうこと。例えば、ユーザーセッションを乗っ取ったり、悪意のあるサイトにリダイレクトしたりできる。
No8. Insecure Deserialization
Deserializationとは外部から受け取ったシリアライズされたデータをDeserializeしたときに、十分な検証をせずに使用することで発生する欠陥。これにより、権限昇格やリモートコード実行などが実行される可能性がある。
https://yamory.io/blog/about-insecure-deserialization/
No9. Using Components with Known Vulnerabilities
ライブラリやフレームワークなど、アプリケーションと同じ権限で実行されるコンポーネントに脆弱性が含まれていた場合、攻撃者によってサーバーの乗っ取りやデータの破壊、取得などが行われる可能性がある。
No10. Insufficient Logging and Monitoring
十分にロギング、モニタリングされていない、またインシデントが起きた時に対応できていない、その効果がないことが原因で、攻撃者が侵入できたとしてもそれに気づかない可能性がある。多くの侵入調査では侵入に検知するまでに200日以上かかり、さらにプロセスや監視システムによって検知されるのではなく、外部の人によって検知されていることが多い。
スキャンの種類
マネージドスキャン
この機能はSecurity Command Centerのプレミアムティアでのみ利用できる機能で、週に一回自動的にセキュリティスキャンが実行される。カスタムスキャンはプロジェクトレベルで定義されるのに対して、マネージドスキャンは組織レベルで定義される。
カスタムスキャン
マネージドスキャンは自動で実行されるのに対して、カスタムスキャンは手動で実行するスキャン。以下の値を設定してスキャンする。
| 項目 | 説明 |
|---|---|
| 開始URL | 通常は開始URLは一つだけだが、複雑なJavascriptを必要とするWebサイトやページが多数あるWebサイトでは全てのページが検出されない場合があるので、その場合は開始URLを追加してスキャンの範囲を広げる必要がある。 |
| 除外URL | 除外するURL |
| 認証 > Googleアカウント | Googleアカウントを使用してスキャンするように設定できる（２要素認証はサポートされていない） |
| 認証 > IAP | IAPで保護されたアプリケーションに接続する場合は、Web Security ScannerのサービスアカウントをIAPに追加する。次にOAuthクライアントIDをスキャンに追加することで、Web Security Scannerは保護されたアプリケーションのみをスキャンするようになる |
| 認証 > Google以外のアカウント | ユーザー名とパスワードとログインフォームのURLを指定する。スキャンを継続させるために認証Cookieが生成される必要がある。パスワードを使用しないログインフォームや認証Cookieが生成されない場合は失敗する。 |
| スケジュール | 毎日、毎週、2週間毎、4週間毎の中から設定Loveケイル。 |
| 事前定義されたソースIPのセットからスキャンを実行する(Preview版） | これを設定することでファイアーウォールの背後にあるアプリケーションにもスキャンを実行することができるようになる。このソースIPを許可するファイアーウォールを構成する必要がある。 |
| HTTPステータスエラーを無視 | ４００ Bad Requestなどが発生したときにスキャンが失敗したとして報告するかどうかを設定できる。デフォルトではステータスエラーが閾値を超えると、スキャンは失敗として報告される。 |
カスタムスキャンめっちゃ優秀やん、、、全然無料版でいい気がする、、、
検出結果のタイプ
まとめ
Webアプリケーションの脆弱性を検出するサービスとしてめっちゃ優秀なプロダクトだった。無料版でも十分機能すると分かったので、GCE、GAE、GKEでアプリケーションを公開する場合は必須と言えると思う。スキャンするときに実際にフィールドに値を入力したり、ボタンを押したりするので、本番環境でやると何かしたらの不都合が生じる場合があるので注意。（例えば、コメント欄にテストテキストが表示されるなど）