この記事は Rohit Bhatia、Mollie Bates による Google Security Blog の記事 "How Hash-Based Safe Browsing Works in Google Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ユーザーはウェブをブラウジングするときに、さまざまな脅威に遭遇します。誤認させるサイトや偽物のサイトにパスワードなどのプライベートな情報を入力するように欺かれる場合があり、これはフィッシングとも呼ばれます。マルウェアと呼ばれる悪意のあるソフトウェアをインストールさせられ、個人データを収集されたり、身代金を要求されたりすることもあります。Google Chrome（以降は Chrome と記述します）は、このようなインターネット上の脅威からユーザーを守ります。Chrome ユーザーがセーフ ブラウジング保護をオンにしてウェブをブラウズすると、Chrome は Google のセーフ ブラウジング サービスを使ってさまざまな脅威を特定して回避します。

セーフ ブラウジングは、ユーザーの設定によって動作が異なります。特に一般的なのは、Chrome がセーフ ブラウジング サービスのプライバシーに配慮した Update API（アプリケーション プログラミング インターフェース）を使うケースです。この API はユーザーのプライバシーを念頭に置いて開発され、Google は可能な限り最小のユーザーの閲覧履歴しか取得しない仕組みになっています。ユーザーが [保護強化機能]（以前の投稿で取り上げました）や [検索とブラウジングを改善する] をオンにしている場合、Chrome はユーザーの保護を強化することのみを目的として、一部の追加データをセーフ ブラウジングと共有します。

この投稿では、Update API の技術的な実装や詳しいプライバシー配慮の仕組みを適宜示しながら、Chrome の Update API の実装方法について説明します。ここで紹介する内容は、セーフ ブラウジングによってどのように保護されているかをユーザーが理解したり、興味があるデベロッパーが実装を参照したりする際に役立つはずです。保護強化機能に使われる API については、今後の投稿で取り上げたいと思います。

インターネット上の脅威

ユーザーがインターネット上のウェブページを開くと、ブラウザがインターネット上のホストに保存されているオブジェクトを取得します。こういったオブジェクトには、ウェブページの構造（HTML）、スタイル設定（CSS）、ブラウザの動的な動作（Javascript）、イメージ、操作によって始まるダウンロード、メインページに埋め込まれた他のウェブページなどがあります。これらはリソースとも呼ばれ、URL（Uniform Resource Locator）と呼ばれるウェブアドレスが割り当てられています。また、URL が読み込まれると、別の URL にリダイレクトされることもあります。そういったそれぞれの URL に、フィッシング サイト、マルウェア、望まないダウンロード、悪意のあるソフトウェア、不正な課金などの脅威が潜んでいる可能性があります。Chrome でセーフ ブラウジングをオンにすると、URL、リダイレクト、インクルードされるリソースのすべてがチェックされるので、そのような脅威を特定してユーザーを保護できます。

セーフ ブラウジング リスト

セーフ ブラウジングは、脅威からユーザーを守るため、インターネット上の脅威のリストを提供します。Chrome が使う完全なリストは、PC プラットフォームから chrome://safe-browsing/#tab-db-manager にアクセスすると参照できます。

リストには安全でないウェブの完全なアドレス（URL とも呼ばれます）は含まれていません。デバイスの限られたメモリにすべてを保持するのは、あまりに高価すぎて不可能だからです。URL は非常に長くなる可能性があるので、暗号ハッシュ関数（SHA-256）によって URL を固定長の一意な文字列にマッピングします。この固有の固定長文字列はハッシュと呼ばれ、これを使って限られたメモリにリストを効率的に格納します。Update API はハッシュ形式でのみ URL を扱うため、この投稿ではハッシュベース API と呼んでもいいでしょう。

さらに、リストには完全なハッシュが保存されているわけでもありません。この方法でも、メモリを使いすぎてしまうからです。実際には、データを Google と共有しない場合やリストが小さい場合を除き、ハッシュのプレフィックスのみを保持しています。ここでは、オリジナルのハッシュを完全ハッシュ、ハッシュのプレフィックスを部分ハッシュと呼びます。

リストは Update API のリクエスト頻度セクションの内容に従って更新されます。失敗のレスポンスを受け取った場合、Chrome はバックオフ モードにも従います。このアップデートは、サーバーが設定したリスト更新レスポンスの最小待機時間に従って、およそ 30 分ごとに行われます。

関連するソースコードに興味がある方のために、閲覧すべき場所をお知らせします。

ソースコード

1. GetListInfos() には、すべてのリストに加えて、関連する脅威の種類、使われているプラットフォーム、ディスク上のファイル名が含まれます。
2. HashPrefixMap はリストの格納方法とメンテナンス方法を示します。二分探索ベースの高速な検索ができるように、リストはプレフィックス長でグループ化されたうえで連結されます。

ハッシュベースの URL 検索の仕組み

セーフ ブラウジング リストの例として、マルウェア用のリストがあるとします。ここには、マルウェアをホストしている URL の部分ハッシュが含まれています。通常、部分ハッシュの長さは 4 バイトですが、説明のため、ここでは 2 バイトのみを表示します。

['036b', '1a02', 'bac8', 'bb90']

ある URL に移動したときなど、Chrome が Update API でリソースの評判を確認するときは、検索をするためにセーフ ブラウジングに未加工の URL（やその一部）を提示することはありません。Chrome は URL（と URL の組み合わせ）の完全ハッシュを使い、ローカルに保持されているセーフ ブラウジング リストの部分ハッシュを検索します。そして、一致した部分ハッシュのみをセーフ ブラウジング サービスに送信します。このようにすることで、Chrome はプライバシーを尊重しながらユーザーを確実に保護します。このハッシュベースの検索は、以下の 3 ステップで行われます。

ステップ 1: URL の組み合わせと完全ハッシュを生成する

Google は、セーフ ブラウジング リストに登録することで、安全でない可能性があるリソースをホストする URL をブロックします。すると、悪意のある人物は、そのリソースを別の URL にホストするかもしれません。または、さまざまなサブドメインを使い回して新しい URL を作るかもしれません。セーフ ブラウジングはホストのサフィックスを使い、サブドメインにマルウェアをホストしている悪意のあるドメインを特定します。同様に、悪意のある人物はさまざまなサブパスも使い回して新しい URL を作るかもしれません。そこで、セーフ ブラウジングはパスのプレフィックスも使って、さまざまなサブパスにマルウェアをホストするウェブサイトを特定します。これにより、悪意のある人物がサブドメインやパスを使い回して悪意のある URL を新たに作ることを防げるので、確実かつ効率的に脅威を特定できます。

ホストのサフィックスとパスのプレフィックスに対応するため、Chrome はまず URL の完全ハッシュと、URL から算出できるいくつかのパターンを計算します。Chrome は、セーフ ブラウジング API の URL とハッシュの仕様に従い、以下の手順によって URL の組み合わせの完全ハッシュを計算します。

1. まず、Chrome は URL を仕様で定義されている正規形に変換します。
2. 次に、その URL に対して最大 5 つのホストのサフィックス / バリアントを生成します。
3. 次に、その URL に対して最大 6 つのパスのプレフィックス / バリアントを生成します。
4. 次に、その 30 個のホストのサフィックスとパスのプレフィックスの組み合わせのそれぞれについて、完全ハッシュを生成します。

ソースコード

1. V4LocalDatabaseManager::CheckBrowseURL はハッシュベースの検索を行う例です。
2. V4ProtocolManagerUtil::UrlToFullHashes は、ある URL に対してさまざまな URL の組み合わせを作成し、それらの完全ハッシュを計算します。

例

たとえば、ユーザーが https://evil.example.com/blah#frag にアクセスしようとしているとします。正規化した URL は、https://evil.example.com/blah です。試すべきホストのサフィックスは evil.example.com と example.com です。パスのプレフィックスは / と /blah です。4 つの URL の組み合わせは、evil.example.com/、evil.example.com/blah、example.com/、example.com/blah です。

url_combinations = ["evil.example.com/", "evil.example.com/blah","example.com/", "example.com/blah"]
full_hashes = ['1a02…28', 'bb90…9f', '7a9e…67', 'bac8…fa']

ステップ 2: ローカルリストで部分ハッシュを検索する

次に Chrome は、URL の組み合わせの完全ハッシュと、ローカルに保持されているセーフ ブラウジング リストを照合します。このリストには部分ハッシュしか含まれていないので、悪意があると決定的に判定することはできません。しかし、URL に悪意がないと考えられるかどうかはすばやく特定できます。URL の完全ハッシュがローカルのリストのどの部分ハッシュとも一致しなければ、URL は安全であると考えられ、Chrome は読み込み処理に進みます。チェックされる URL の 99% 以上がこの手順に従います。

ソースコード

1. V4LocalDatabaseManager::GetPrefixMatches は、URL とその組み合わせの完全ハッシュに一致する部分ハッシュを取得します。

例

3 つの完全ハッシュ 1a02…28、bb90…9f、bac8…fa が、ローカルの部分ハッシュに一致することがわかります。これはデモ目的であり、実際にここで一致が起きることはほとんどありません。

ステップ 3: 一致する完全ハッシュを取得する

次に Chrome は、セーフ ブラウジング サービスの fullHashes.find メソッドに、一致した部分ハッシュのみを送信します（完全な URL や URL の一部、その完全ハッシュは送信しません）。その応答として、すべての悪意のある URL の完全ハッシュが返されます。この完全ハッシュは、Chrome が送信した部分ハッシュのいずれかで始まるものです。Chrome は、取得した完全ハッシュと、URL の組み合わせから生成した完全ハッシュを照合します。一致する場合、その URL は完全ハッシュに対応したさまざまな脅威や重大度を持つ URL であると特定されます。

ソースコード

1. V4GetHashProtocolManager::GetFullHashes は一致した部分ハッシュに対応する完全ハッシュを検索します。

例

Chrome は一致した部分ハッシュ 1a02、bb90、bac8 を送信し、完全ハッシュを取得します。サーバーは部分ハッシュに一致する完全ハッシュとして、1a02…28, bb90…ce, と bac8…01 を返します。完全ハッシュの 1 つがチェック対象の URL の組み合わせの完全ハッシュと一致するので、Chrome はこの URL がマルウェアをホストする悪意のある URL であると特定します。

まとめ

セーフ ブラウジングは、インターネット上のさまざまな悪意や脅威から Chrome ユーザーを守ります。これらの保護を提供する一方で、Chrome はメモリ容量の制約、ネットワーク帯域幅の使用量、ダイナミックな脅威の状況といった課題に直面します。さらに、ユーザーのプライバシーの選択にも配慮し、Google と共有するデータを可能な限り少なくしています。

今後の投稿では、Chrome が [保護強化機能] をオンにしたユーザーに提供する高度な保護について説明したいと思います。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google アカウント セキュリティ チーム、ソフトウェア エンジニア、Daniel Margolis による Google Online Security Blog の記事 "Taking on the Next Generation of Phishing Scams" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

セキュリティ技術は毎年向上しており、ブラウザが進化して、ウェブの暗号化が普及し、認証が強固になっています。しかし、フィッシングは依然として脅威であり続けています（米国労働省への先日のフィッシング攻撃からもわかります）。その原因は、単純なパスワードだけで世界中どこからでもオンライン アカウントにログインできる状態が続いているところにあります。そこで今回の I/O では、フィッシングのリスクを減らす新たな方法として、Google ドキュメント、スプレッドシート、スライドのフィッシング保護の拡大、2 段階認証の自動登録の継続などについてお知らせしました。このブログでは、フィッシングの手法と、それがどのように進化しているかについて詳しく説明します。

フィッシングの広がりとともに、攻撃者が多要素認証を狙うことが多くなっています。たとえば、正規の「ワンタイム パスコード」（攻撃者が被害者のアカウントにログインしようとして送られたもの）の後に「先ほど受信したコードを返信してください」というなりすましメッセージを送ることで、SMS コードを直接盗み取ろうとする場合があります。

左 : 正規の Google SMS 認証。 右 : 認証コードを共有することを求めるなりすましメッセージ。

また、それよりも高度な動的フィッシング ページを使ってリレー攻撃が行われることもあります。この攻撃では、通常のフィッシング攻撃と同じように、ユーザーは目的のサイトにログインしていると思いこんでいます。しかし、単なる静的なフィッシング ページで被害者がログインしようとしたときにメールとパスワードを取得しようとするのではなく、情報を盗むと同時に実際のウェブサイトにログインするウェブサービスが使われています。

最も簡単な方法は、既製の「リバース プロキシ」をほぼそのまま利用することです。これが「中間者」として動作し、入力を正規のページに転送し、正規のページからの応答をブラウザに送り返します。

こういった攻撃を防ぐのは困難です。攻撃者に提示される追加の認証画面（SMS コードのプロンプトなど）も被害者にリレーされ、被害者の応答も本物のウェブサイトにリレーされるからです。この方法では、どんな認証が行われても、被害者がそれを解決してくれることになります。

従来の PIN コードによる多要素認証では、このような攻撃には対抗しきれません。スマートフォンに同意画面を提示するという認証は、SIM スワップ攻撃には効果的ですが、こういったリアルタイム盗聴を防ぐことはできません。

ソリューション領域

ここ数年間で、デバイスベースの 2 要素認証の自動有効化を始めています。この認証方法は、従来のパスワード漏洩に効果があるだけでなく、技術の向上に伴い、前述のような高度な形態のフィッシングからの保護にも役立つようになっています。

大まかに分けると、ほとんどのフィッシング対策は次のように分類されます。

• ブラウザの UI を改善し、ユーザーが正規のウェブサイトを見分けられるようにする。
• パスワード マネージャでログイン前にウェブページが本物かどうかを検証する。
• メール（最もよく使われる配信チャンネル）とブラウザの両方でフィッシングを検知し、疑わしいウェブページについて警告する。
• 自動ログインを防ぐことで、前述の中間者攻撃を防止する。
• セキュリティ鍵やスマートフォンの Bluetooth 接続を利用して、フィッシングに強い FIDO 認証をする。
• Google Prompt 認証を強化し、ユーザーが疑わしいログイン試行を特定できるようにしたり、フィッシングに対抗するための追加手順を導入したりする（別のウェブアドレスに移動する、ログインしているコンピュータと同じワイヤレス ネットワークに接続するなど）。

フィッシングに強い認証を多くのユーザーに展開する

この 10 年間、私たちは FIDO Alliance の一員として、たくさんの業界パートナーの協力のもと、フィッシングに強い認証メカニズムの展開を懸命に進めてきました。こういった取り組みを通じて、Titan セキュリティ キーなどの物理 FIDO セキュリティ鍵を導入しました。これを使うと、ログインするウェブサイトが本物かどうかを検証することで、フィッシングを防ぐことができます（この検証により、前述の「中間者」フィッシングを防ぎます）。先日には、FIDO Alliance、Apple、Microsoft とともに、フィッシングに強い真にパスワードレスな未来に向けて、大きな節目となる発表をしました。すなわち、FIDO ログイン標準のサポートを拡大します。

セキュリティ鍵はたいへん効果的ですが、あらゆる人がキーホルダーにつけて持ち歩くようになるとは思えません。

そこで、このレベルのセキュリティをより身近なものにするため、セキュリティ鍵をスマートフォンに組み込みます。USB でデバイスに接続しなければならない物理 FIDO セキュリティ鍵とは違い、Bluetooth を使ってスマートフォンがログインするデバイスのそばにあることを確認します。これにより、物理セキュリティ鍵と同じく、遠くにいる攻撃者がユーザーを欺いてブラウザのログインに同意させることはできなくなります。「中間者」攻撃は SMS や Google Prompt にも有効ですが、このセキュリティ層が追加されることで、このような攻撃を防ぐことができます。

（なお、Bluetooth の範囲内にあるコンピュータがユーザーとしてログインできるようになるわけではありません。ユーザーがそのコンピュータからログインすることに同意できるようになるだけです。また、この仕組みは、スマートフォンがログインしようとしているデバイスの近くにあることを確認するためだけに使います。そのため、Bluetooth をオンにする必要があるのはログインの間だけです）

今後の数か月間で、この技術を多くの場所に展開する予定です。そのため、この追加セキュリティ チェックが行えるように、ログイン時に Bluetooth を有効にするリクエストが表示されることがあるかもしれません。Android スマートフォンで Google アカウントにログインしている場合は、Google Prompt と同じように、スマートフォンを自動登録できます。そのため、一切追加設定をすることなく、この追加のセキュリティ層を多くのユーザーに提供できます。

ただし、この安全なログイン方式は、どこでも利用できるわけではありません。Bluetooth をサポートしていないコンピュータや、セキュリティ鍵をサポートしていないブラウザにログインする場合は利用できません。そのため、すべての人がフィッシングに強いセキュリティを利用できるようにするのであれば、セキュリティ鍵が利用できない場合のバックアップを提供する必要があります。そして、そのバックアップも、攻撃者に利用されることがないように、十分に安全なものでなければなりません。

フィッシング対策として既存の認証を強化する

ここ数か月の間に、従来の Google Prompt 認証をフィッシングに強くする実験を始めています。

現時点で、すでに状況に応じて認証操作が変わるようになっています。たとえば、「許可」と「拒否」のクリックに加えて、PIN コードと画面に表示されている内容を照合することが求められる場合があります。これは、認証に同意させようとする静的フィッシング ページへの対策として有効です。

また、リスクが高い状況でさらに多くの操作を求める実験も開始しています。たとえば、フィッシング攻撃者のものと思われるコンピュータからログインしている場合に、目立つように警告を表示します。あるいは、スマートフォンとログイン操作を行っているコンピュータが確実に近くにあることを確認するため、両方が同じ Wi-Fi ネットワークに接続することを求めます。この対策により、セキュリティ鍵に Bluetooth を使う仕組みと同じように、意図せずに「中間者」フィッシング ページにログインしてしまうことを防止できます。

すべてを統合する

ここで紹介した方法は、いずれもアカウントのセキュリティを劇的に高めるものです。しかし、当然ながら、これが難しいユーザーもいます。そのため、ユーザビリティにも注目したリスクベースのアプローチの一環として、これらの方法を徐々にロールアウトしています。リスクが高いと判断されたアカウントや、異常な動作が見られたアカウントには、先ほどのような追加セキュリティ対策が導入される可能性が高くなります。

今後、FIDO2 認証がさらに普及すれば、多くのユーザーに対してそれをデフォルトにできると考えています。すると、今回説明したような既存の認証をさらに強固にしたものを使って、安全なフォールバックを提供できるようになります。

ブラウザの自動処理を検知して「中間者」攻撃を防ぐ、Chrome や Gmail でユーザーに警告する、Google Prompt の安全性を強化する、Android スマートフォンを使いやすいセキュリティ鍵として自動的に有効化するなど、ここで紹介した新手法を連携すれば、ユーザーをフィッシングから守る仕組みをさらに強化できます。

フィッシング攻撃は古くからの根強い脅威ですが、最新技術によって、オンラインでの安全を享受できるユーザーを増やすための画期的な対策を実現できるようになっています。
Reviewed by Eiji Kitamura - Developer Relations Team