Secure by Design の原則に基づいたGoogleの高信頼性を確保するWEBフレームワークとは？

はじめに

Googleは、大規模なWebアプリケーションのエコシステムを抱えており、そのセキュリティは非常に重要です。
過去10年間でWebアプリケーションの数は大幅に増加しましたが、Googleはセキュリティ脆弱性、特にXSS（クロスサイトスクリプティング）の数を大幅に削減することに成功しました。
この成果は、「Secure by Design」の原則に基づいた高保証Webフレームワークの採用によるものです。Webセキュリティには、もともとプラットフォームに内在する3つの課題（暗号化の欠如、インジェクション、分離の欠如）があり、これらが様々な脆弱性の原因となっています。Googleは、プラットフォーム自体を改善すると同時に、これらの問題を緩和するために高保証Webフレームワークを開発しました。　　 このフレームワークは、安全なコーディング、適応性、および可観測性の3つの重要な要素で構成されており、開発者がセキュリティを意識せずに安全なアプリケーションを構築できることを目指しています。　　 　　 どのようなフレームワークなのか？

Googleの高保証Webフレームワークは、以下の3つの要素を中心に構成されています。

1. 安全なコーディング (Safe Coding)

   • 開発者がセキュリティを意識せずに安全なコードを書けるようにすることを目指します。
   • デフォルトで安全な動作を保証し、セキュリティ上の後退を防ぐためのガードレールを設けます。
   • コードがコンパイルされ、正常に実行されれば、セキュリティも保証されることを目指します。
   • 開発者のエクスペリエンスを損なうことなく、これを実現することは困難ですが、非常に重要です。
   • 開発者が「No」ではなく「Yes! 安全な方法は...」と言えるように、開発者への共感を重視します。

2. 適応性 (Adaptability)

   • Webプラットフォームやセキュリティ研究の変化に柔軟に対応できるように、セキュリティ対策を常に進化させる必要があります。
   • 新たなセキュリティ脆弱性に対して、継続的に詳細な調査を行い、フレームワークを更新します。
   • 新しいセキュリティメカニズムを設計し、最初にフレームワークやライブラリでテストを行い、効果を検証します。
   • 検証後、そのソリューションをWebプラットフォームにアップストリームし、より多くの人に恩恵をもたらすことを目指します。
   • 新しいセキュリティ対策をデフォルトで有効にし、セキュリティの後退を防ぐためのガードレールを追加します。
   • 大規模な変更を実装して、既存のサービスに新しいセキュリティ対策を適用します。
   • 展開状況を測定して、セキュリティ対策の適用範囲を把握します。
   • 高保証Webフレームワーク上に構築されたアプリケーションは、セキュリティの進歩に追従する必要がなく、新しいセキュリティ対策は透過的に中央で適用されます。

3. 可観測性 (Observability)

   • セキュリティチームがすべてのアプリケーションのセキュリティ体制を深く理解するために、不可欠です。
   • 手動での可観測性はスケールしないため、フレームワークとインフラストラクチャに可観測性機能を組み込みます。
   • フレームワークの動作、セキュリティ機能の導入状況などを把握します。
   • Googleでは、Webセキュリティを測定可能にするために、Security Signalsという仕組みを利用しています。

主要なセキュリティ制御

高保証Webフレームワークでは、以下のセキュリティ制御が自動的に有効になります。これらの機能は、セキュリティチームによって管理されており、アプリケーションの所有者はこれらの機能を意識する必要はありません。

• 暗号化 (Encryption)
  • Secure cookies: 全てのクッキーはSecure属性を使用し、HTTPSを使用するページのみで利用可能にします。
  • HTTPS Redirects: 全てのHTTPレスポンスは、HTTPリクエストをHTTPSにリダイレクトします。
  • HSTS: 全てのHTTPレスポンスはHSTSを使用し、ブラウザがデフォルトでHTTPS URLを使用するようにします。
• 隔離 (Isolation)
  • XSRF Protection: 全ての状態を変更するエンドポイントは、XSRF脆弱性に対する強力な保護を実装します。
  • SameSite cookies: 全てのクッキーはSameSite属性を使用し、クロスサイトリクエストに付与されないようにします。
  • Framing Protections: 全てのページは、信頼できない第三者によるiframeの利用を防ぐためのフレーミング保護を実装します。
  • Cross-Origin Opener Policy (COOP): 全てのページはCOOPを実装し、信頼できない第三者のページがポップアップで開き、それらとやり取りすることを防ぎます。
  • Fetch Metadata Protections: 全てのページは、デフォルトでクロスサイトリクエストをブロックするために、Fetch Metadata保護を実装します。
  • Cross-Origin Resource Policy (CORP): 全てのページはCORPヘッダーを設定し、予期しないクロスサイトコンテキストでロードされるのを防ぎます。
  • Hostname Validation: 全てのサービスはHostヘッダーを検証し、予期しない値を持つリクエストを拒否します。
• インジェクション (Injection)
  • JS/TS Conformance: 全てのサービスは、コンパイル時の適合を使用して、安全でないパターンを使用するJS/TSコードをブロックします。
  • SafeResponse Types: 自動適合チェックにより、すべてのHTTPレスポンスがXSSフリーな方法で構築されていることを保証します（例：安全な自動エスケープテンプレートシステム）。
  • Contextual Auto-Escaping Template System: 全てのHTMLレスポンスは、コンテキストに応じた自動エスケープをサポートするテンプレートシステムによって構築され、レスポンスがXSS脆弱性がないことを保証します。
  • Default Content-Type: 全てのHTTPレスポンスは、明示的にContent-Typeヘッダーを設定します。欠落している場合は、安全なデフォルト値（例：text/plain）に設定します。
  • HttpOnly cookies: 全てのクッキーはHttpOnly属性を使用し、クライアント側のJSからアクセスできないようにします。
  • Strict CSP: 全てのページは、XSS脆弱性を軽減するために厳密なnonceベースのCSPを実装します。
  • Trusted Types: 全てのページは、DOM XSS脆弱性を軽減するためにTrusted Typesを実装します。
  • Allowlist CSP: 全てのページは、レビュー済みの信頼できるJS提供ホストに許可されたJSソースのセットを制限するために、許可リストCSPを実装します。これにより、ランタイムサプライチェーン攻撃を軽減できます。
  • Strict dependency controls: ビルド時に消費されるすべてのライブラリは、ビルドタイムのサプライチェーン攻撃を軽減するためにレビューされます。
  • JS Integrity Validation: 全てのページは、含まれる全てのスクリプトの整合性を検証し、ビルドタイムとランタイムの間で変更されていないことを保証します。
  • Prototype Pollution Mitigations: 全てのページは、プロトタイプ汚染に対する緩和策を実装します。

XSS緩和のケーススタディ

これらのセキュリティ制御がどのように連携して、高保証の保護を提供するかの事例として、XSSの緩和策について説明します。

• 古典的なXSSベクター
  • Reflected & Persistent XSS: SafeResponse Types, Contextual Auto-Escaping Template System、およびStrict CSPによって緩和されます。これらのXSSを発生させるためには、SafeResponseのバイパス、テンプレートシステムの脆弱性、およびStrict CSPのバイパスが必要になります。
  • DOM XSS: JS/TS Conformance, Strict CSP、およびTrusted Typesによって緩和されます。これらのXSSを発生させるためには、コンパイル時のJS/TS適合、Strict CSP、およびTrusted Typesのバイパスが必要になります。
• その他のXSS
  • Prototype Pollution → XSS: プロトタイプチェーンを凍結およびシールすることで緩和されます。
  • Supplychain attacks → XSS: Allowlist CSPによって緩和されます。

これらの緩和策により、高保証Webフレームワーク上に構築されたアプリケーションには、XSSの欠陥がないという高い確信を持つことができるようになったようです。

まとめ

Googleの高保証Webフレームワークは、安全なコーディング、適応性、および可観測性の3つの要素を組み合わせて、Webアプリケーションのセキュリティを大幅に向上させています。

安全なコーディングは、開発者がセキュリティを意識せずに安全なコードを記述できるように、デフォルトで安全な動作を保証し、セキュリティ上の後退を防ぐためのガードレールを提供します。適応性は、Webプラットフォームの変化や新たなセキュリティ脅威に対して、継続的にセキュリティ対策を進化させ、最新の状態に保つことを可能にします。可観測性は、セキュリティチームがアプリケーションのセキュリティ体制を理解し、問題が発生した場合に迅速に対応できるようにします。

このフレームワークは、暗号化、隔離、およびインジェクションに関連する多くの脆弱性に対処するためのさまざまなセキュリティ制御を提供します。これらの制御は、クッキーの保護、HTTPSリダイレクト、HSTS、XSRF保護、SameSiteクッキー、フレーミング保護、COOP、Fetch Metadata保護、CORP、Hostname Validation、JS/TS Conformance、SafeResponse Types、Contextual Auto-Escaping Template System、Default Content-Type、HttpOnlyクッキー、Strict CSP、Trusted Types、Allowlist CSP、Strict dependency controls、JS Integrity Validation、Prototype Pollution Mitigationsなど、広範なセキュリティ対策を網羅しています。

Googleは、これらのセキュリティ制御を組み合わせることで、XSS脆弱性を大幅に削減し、高保証のWebアプリケーションを構築することに成功しています。特に、XSSのケーススタディでは、古典的なXSSベクターだけでなく、プロトタイプ汚染やサプライチェーン攻撃のような、その他のXSSも緩和されていることが示されています。

このフレームワークの利点は、脆弱性の減少、多層防御、開発者の生産性の向上、およびメンテナンス性の向上です。Googleは、このフレームワークがWebセキュリティにおける長年の課題を解決する上で非常に有効であると考えており、今後、このアイデアをオープンソースのWebエコシステムにも提供することを目指しています。 こういう風に作られたフレームワークを利用することで、開発者はセキュリティの詳細を気にすることなく、製品の開発に集中できるようになります。
また、セキュリティチームは、すべてのアプリケーションのセキュリティ体制を監視し、新しい脅威に迅速に対応できるようになります。