ハクソク

世界を動かす技術を、日本語で。

Google セーフブラウジングのインシデント

227日前原文(statichost.eu)

概要

  • 2025年9月25日、約6時間にわたり statichost.euドメイン全体 がGoogle Safe Searchで 危険サイト扱い。
  • 利用者は 警告表示やアクセスブロック を受け、カスタムドメインにも影響。
  • 原因はフィッシングサイトの増加 によるGoogleの自動検出。
  • サイト運営者は 迅速に対応し、数時間でブロック解除。
  • Googleの 影響力と監視体制の問題点 についての考察。

statichost.euがGoogle Safe Searchで危険サイト扱いされたインシデント

  • 2025年9月25日、 statichost.eu全体がGoogle Safe Searchによって「詐欺サイト」認定。
  • 約6時間にわたり、 Google Safe Search利用者はstatichost.euへのアクセスが警告またはブロック。
  • 一部のカスタムドメイン も影響を受け、正常なサービス提供が困難な状況。
  • Hacker Newsでも議論が発生 し、注目を集めた事例。

インシデント発生から対応までの流れ

  • 月曜日の朝、 複数ユーザーから「セキュリティ警告でアクセス不可」と報告。
  • 自身でstatichost.euにアクセス、 TLSや技術的問題は未検出。
  • 問題の共通点が「Google」 であることに気付き、Chromiumで検証。
  • Google検索でstatichost.euが検索結果から消失、異常を認識。
  • Google Search Consoleで「セキュリティ問題」の巨大エラーメッセージ を確認。
  • 週末に発生したフィッシングサイトが原因 で、statichost.eu全体がブラックリスト入り。
  • Googleから問題サイトのリスト提供 を受け、速やかに該当サイトを削除。
  • Googleへのレビュー申請 を実施し、数時間後に自動的にブロック解除。
  • 解除通知はSearch Console内のみ、メール連絡等は一切なし。

Google Safe Browsingの仕組みと影響力

  • Google Safe Browsingの目的は 「世界中の情報を安全にアクセス可能にする」 こと。
  • 実態は Googleが不適切と判断したサイトの巨大なブラックリスト。
  • このリストは 主要ブラウザや多くのサービスで利用 されており、 「50億台以上」の端末に影響。
  • Google ChromeはデフォルトでアクセスURLをGoogleへ送信。
    • 「高度な保護」設定ではページ内容も一部送信、大規模な監視体制。
  • 多くのブラックリスト入りサイトは確かに危険 だが、 誤検知（false positive）も存在。
  • 全てのフィッシングサイトを網羅できていない現実。

Googleの支配力・監視体制への懸念

  • Googleはインターネットの多くのやり取りを「コントロール/監視」。
  • Googleの判断だけに依存する危険性。
  • 友好的なブランドイメージや過去の実績に惑わされない警戒心 の重要性。
  • Googleに「誰を信じるか」を委ねず、自らの判断力・ネットリテラシーを重視。

今後の対策と改善策

  • 今後はstatichost.euではなくstatichost.pageドメインで新サイト作成。
    • Public Suffix Listへの追加申請中、さらなるセキュリティ強化を目指す。
  • 同様のインシデント発生時の影響範囲縮小 を図る運用体制。

まとめ

  • Google Safe Browsingの意義は認めつつも、その巨大な影響力と誤検知リスクは無視できない問題。
  • サービス運営者はGoogle依存を減らし、複数の対策と独自判断力を持つことが重要。
  • 利用者側も警告やブロック表示に盲目的に従わず、慎重な情報判断を心掛ける必要性。

Hackerたちの意見

大手SNS企業じゃない限り、ユーザーコンテンツを受け入れるのはどんどんリスクが大きくなってる気がする。

└

もともとそうだったよ。アップロード一回とISPやGoogle、AWS、MSへのクレームがあれば、アカウントが停止される可能性があるからね。

ユーザーコンテンツを別のドメインに置いて、そのドメインをパブリックサフィックスリストに追加するのはいいアドバイスだよ。実際、インフラ提供者なら最初から知っておくべきことだと思う。ここには著者の無知から来る誤解が多いね。

└

もちろん、これは真実だよ！こういう事件が起きないと、なかなか気づかないもんだよね。 :)

└

その通り、これは何年も前から知られていることだし、数十年にもわたって文書化されてる。Githubや他の大手ユーザー生成コンテンツの提供者は、リスクやその軽減方法についての公開文書を持ってる。そういう実践を無視するホスティングプロバイダーは、自分たちと顧客を危険にさらしてるってことだね。

└

正直言って、私はこの分野に約20年いるけど、公共サフィックスリストのことを聞いたのは初めてだ。

└

ここには著者自身の無知から外れた多くの悪意がある。あなたが言いたいのは、著者の無知に向けられるべきだということだと思うけど、そうじゃなくてそれを引き起こした状況に向けられるべきだと思う。

└

何かが事実上の標準だと思うなら、公共サフィックスリストは今のところちょっと生煮えな感じがする。思いついた2つの人気の公共サフィックス、'livejournal.com'と'substack.com'をチェックしたけど、どちらも載ってなかった。もしかしたら私が間違ってるのかもしれないけど、バグじゃなくてこれらのサフィックスは含まれるべきじゃないのかもしれない。でも、その理由が思いつかないんだよね。

└

PSLって、問題が起きた後に初めて知るものだよね。正直言って、変なもので、ブラウザがサブドメインを違う扱いする基準にはどこにも載ってないGithubのリポジトリなんだ。こういう情報は、ホスティングを始めたからって急に頭に浮かぶわけじゃないし、存在を知らなかったら、こんなプロジェクトを探そうとも思わなかっただろうな。みんなが使えるオープンなもので、しかも現代のインターネット対応のコンピュータやマルウェア対策サービスに組み込まれてるなんて、全く予想外だった。

一般的には良いアドバイスだけど、今回のケースでSafe Browsingが何か悪いことをしたとは思えない。まず、実際にフィッシングサイトを一時的にホスティングしていたみたいだし：> statichost.euのすべてのサイトはSITE-NAME.statichost.euのドメインを持っていて、週末にはフィッシングサイトが急増してた。次に、彼らはパブリックサフィックスリスト（https://publicsuffix.org/）を使って、ドメイン全体がタグ付けされないようにすべきだった。サブドメインが異なるユーザーに属していることをGoogleがどうやって知るの？それがPSLの役割だから。私の読みでは、Safe Browsingはこのケースで正しく機能していて、脅威が取り除かれた後はすぐにサイトを復旧させたよ。

└

GoogleやSafe Browsingが特に何か悪いことをしたとは言ってないよ。私の言いたいことは、Googleがインターネットに対して持っている力が大きすぎるってこと。実際に起こったことは、私が悪者からの防御に十分な努力をしていなかったからだって分かってる。新しい別のドメインはPSLへの追加待ちだけどね。追記：上で言ってる「努力」は、コンテンツのリアルタイムモデレーションのことを指してるよ。

└

公共サフィックスリストに載るのは、言うほど簡単じゃないよね。[1] 彼らは気が向けば「ノー」と言えるし、「プロジェクト」としてその権利を維持しようとしてるから、ビジネスとは違うんだよね。[2] それには利点も欠点もあるけど。[1] https://github.com/publicsuffix/list/blob/main/public_suffix... [2] https://groups.google.com/g/publicsuffix-discuss/c/xJZHBlyqq...

別のドメインがここでの主な問題を解決するとは思えないな。その別のドメインで何かがフラグ付けされたら、そのドメイン上のすべてのユーザーコンテンツに影響が出るし。もしビジネスがそういうユーザーコンテンツを提供することなら、メインのドメインは生きてても、ビジネスの主なサービスはダウンしちゃうよ。

└

そうだね、すべてのユーザーに影響が出るのはその通りだよ。保留中のPSLの追加が完了するまではね。でも、今は自分のリソース、例えばstatichost.euのウェブサイトやダッシュボードをそれから分けられるようになったよ。

└

別のドメインを使っても、ユーザーのコンテンツがブロックされるのを防げるわけじゃないけど、管理インターフェースのブロックは防げるかもしれないね。これがあれば、影響を受けた顧客がコンテンツを取り戻しやすくなるし、サービス側も状況を知らせるバナーを出しやすくなると思う。

CISOとして、Googleが作る多くの保護策には満足してるよ。彼らは独自の立場にいて、これができるのは多分彼らだけだと思う。ただ、大きな力には大きな責任が伴うってことだね。彼らは他の組織よりも優れていて、私たちが想像できないような制約の中で働いている。でも、週に何回かは「このメールはフィッシングです」っていう誤った警告が来るんだ。顧客や見込み客からのメールが「スパム」に入れられて、「危険なリンクが含まれています」って赤いセキュリティバナーが表示される。これは主にドメインの評判の問題で、メールスキャン製品を使っているとすべてのメールがブロックされちゃうんだ。これらの製品はURLをラップして、メールが読まれるときにスキャンできるようにしてるから、ウイルスを検出しないと、実質的にウイルスの供給元になっちゃう。だから、そのドメイン全体が危険と見なされるんだ。これを5月にGoogleに伝えて、ほぼ毎日メールのやり取りをしてる。新しいセキュリティ製品がブラックリストに載ったことを指摘したり、新しい担当者に状況を説明したりしてる。これって、彼らが私たちのスタッフにセキュリティ警告は一般的に誤報だって教えてることになるし、見込み客や顧客からの重要なメールを見逃してることにもなる。私たちの顧客は大企業が多いから、メールを見逃すってのはB2Cの会社とはわけが違うんだ。今のところ、この問題は解決してないし（今は10月だよ！）、最近は返事も来なくなった。私たちの組織はアメリカ政府じゃないってことは理解してるけど、それでも「Google Workspace Enterprise」アカウントに年間20Kドル以上払ってるんだから、もうちょっと期待してたんだよね。もしGoogleの中の誰かがこれを読んでたら、早く直してほしい。

└

私は年寄りだ。セキュリティの仕事を長いことやってる。1990年代から始めたんだ。ここ30年で学んだことは…セキュリティアラートや警告の半分（それ以上）が誤検知だってこと。脆弱性スキャナーが存在しない問題について文句を言ったり（Apacheのバージョンだけで…パッケージメンテナーによってバックポートされたもの）、デロイトのインターンが生成したAIレポート、あるいは誰かがwww.example.comをGoogle Safe Browsingに悪質だと報告したりすることがある。報告される内容の少なくとも半分は間違ってる。こういうのを見抜くには、ある程度の技術的な知識が必要だし、無駄を排除する必要がある。こういったことに基づいてアクセスをブロックするツールは、逆に害を及ぼすことが多いよ。

公共サフィックスリストについての議論がたくさんあるから、ちょっと指摘しておくけど、単にドメインを追加できるウェブフォームってわけじゃないんだ。追加するドメインには十分なユーザーベースが必要っていう重要な基準がある、承認プロセスがあるんだよ。十分なユーザーベースがあると、詐欺師も増えてくる。ここで起こったことはそういうこと。基本的には、ユーザーベースの増加 -> 悪質なコンテンツの増加 -> PSLにドメインを提出する能力、って感じかな。セキュリティの観点から言うと、私にとってはユーザーと同じドメインにいることに問題はない。私のクッキーは自分のサブドメインにスコープされてるし、HTTPSだけだし。私にとってはブロックされることが唯一の問題だったけど、それが思ったよりも大きな問題だったって正直に認めるよ。だから、PSAなんだ。 :)

└

どのくらいの規模が必要なんだろう？私のオープンソースプロジェクトは日々のユーザーがいるけど、数千人はいないんだ。悪意のあるコンテンツを引き寄せるには十分だと思うけど、実際には多くの人が自分に送ってるみたい（ファイアウォールで隔離されたマルウェア分析用のVMに転送するために、パブリックウェブサイトを探してる感じ）。でも、それでもコンテンツは数時間サイトに残ることになる。10年以上ホスティングしてきたけど、誰かがページをウイルススキャナーにかけたみたいで、今はブロックされまくりで、終わりが見えない。もしこれが解決策なら、メインドメインの短いリンクの代わりに、すべてのユーザーにユニークなサブドメインを与えて、ルートをPSLに載せるのもいいと思う。

└

私のクッキーは自分のサブドメインにスコープされています。ドメインオプションのことを言ってるなら、それだけじゃ足りないよ。Host-プレフィックスを使わないと。

将来の同様の問題の影響を制限するために、statichost.euのすべてのサイトは今後、statichost.pageドメインで作成されることになりました。これ、ホラー小説のダークなひねりみたいだね - .pageのTLDはGoogleが管理してるんだ！ https://get.page/

└

信頼を築く一つの方法だね。

└

このハッカー的で鋭いコメント、ありがとう！<3 本当に、ここにあるコメントは著者や他のハッカーにとって楽しいものばかりじゃないから。Googleが提供するものにお金を払うのって、実際素晴らしい気分だよね！

PSA: 提出したタイトルは「PSA: ユーザーコンテンツには別のドメインを使うべき」です。 https://news.ycombinator.com/newsguidelines.html に従って変更しました。文脈を知っておくといいかも。

この投稿が欠けているのは、あなたのウェブサイトをブロックできるのはGoogleだけじゃないってことだね。いろんなアクターができるし、ユーザー生成コンテンツをホストできるサービスは、HTMLだけじゃなくて（単一の画像でも十分）、リスクがあるんだ。実際、どんなサービスでもリスクがある。私はそういうケースにたくさん対処してきたよ：ISPが大きなIPプレフィックスを誤ってブロックしたり、DPIソフトウェアがトラフィックを止めたり、ランダムなアンチウイルスソフトがハッシュ衝突でJSチャンクをブロックしたり、小さな町のISPが自動報告でドメインを沈めたり、他にもいろいろ。著者の場合、少なくとも問題を再現できたけど、多くの場合、問題は小さな地理的地域に限定される。でも、大きなインターネットサービスにとっては、小さな町でも何千人もの人がサポートに連絡してくるけど、全体のトラフィックグラフには問題が見えないことがある。これらの問題に反応できるようにするためにできる一番簡単なステップは：1. 完全に別のインフラに行くNELログを設定すること、2. 問題を再現してトレースルートを取得するためにRIPE Atlasや類似のサービスを使うこと。私はNELログを収集するためのホスティングサービスを作ろうとしたこともあるけど、あまりにもニッチすぎたみたい。[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Net...

超面白い記事だね！先週の月曜日にまさに同じ問題に直面してたよ。それについても少し書いてみた： https://muetsch.io/how-google-accidentally-took-us-off-the-i....