Coded Chords - Security

VIVANT #23で気になったこと

2026-11-02T03:39:08+09:00

Table of Contents

TBSの日曜劇場で放映されている『VIVANTシーズン2』も残すところ最終話のみとなりました。11月1日に放映された第23話では最終話に向け、遂に世界中の諜報機関が探していた科学者エリシャに主人公乃木らがリーチします。そんな緊迫した中で、私が気になったのは凄腕のハッカー Blue@walkerが発したセリフ、「このハッシュ値を復号化して」です。

シーンの解説

このシーンでは、日本の別班が謎の富豪に5千億円を振り込むと同時に、Blue@walkerがハッキングでその金を取り戻します。別班はスーパーコンピュータHAYATOを所有していますが、HAYATOはハッキングには使えない設定です。そのため、ハッキングはBlue@walkerが担当し、HAYATOはそれを支援する役回りです。

セリフから推察すると、次のことが行なわれています。

Blue@walkerが富豪側の何らかのデータをハッキングして入手
HAYATOに解析を依頼し、データから財務担当者を特定
Blue@walkerが財務担当者のアカウントを特定し、そのパスワードのハッシュ値を入手
ハッシュ値からパスワードを復元するため、HAYATOに「このハッシュ値を復号化して」と依頼
Blue@walkerが復元したパスワードを使って、富豪の銀行口座から5千億円を奪い返す

多くのシステムでは、ログインなどを安全に行なうために、ユーザーIDとパスワードで「たしかにこのユーザーですね」と確かめます。この確認処理を認証と呼びます。パスワードをそのままシステムに保存すると危険なので、ハッシュ化という処理でハッシュ値と呼ばれる値に変換してから保存しています。パスワードが入力されると、同じようにハッシュ値を計算し、保存しているハッシュ値と一致すれば認証が成功します。

flowchart LR
    A[設定したパスワード] -->|ハッシュ化| B[(保存したハッシュ値)]
    C[ログイン時に入力したパスワード] -->|ハッシュ化| D[ハッシュ値]
    B --> E{突き合わせ}
    D --> E
    E -->|一致| F[認証成功]

なぜこのセリフが気になったか

このセリフが気になったのは、ハッシュ値が技術的に復号できない（不可逆）からです。そもそもハッシュ化と暗号化は別の処理なので、「復号」という言葉自体が当てはまりません。

たとえば、my-password-is-123456789-password というパスワードのハッシュ値は1f1ea0e5880b52d64b88e8d286d6e454で、MD5というロジックで算出しています。しかし、1f1ea0e5880b52d64b88e8d286d6e454という値から元のパスワードmy-password-is-123456789-passwordを逆算できません。このように、ハッシュ値から元の値を見つけ出すことが極めて難しい性質を原像耐性と呼びます。ハッシュ値を「像」、元のパスワードを「原像」に見立てた呼び方です。

この原像耐性があるため、パスワードをそのまま保存するのではなくハッシュ値で保存することが安全とされている訳です。これは桁違いの計算能力を持つ量子コンピュータをもってしても変わりません。

ハッシュ値から元のパスワードを優秀なハッカーとスーパーコンピュータで復号できるとするならば、核融合技術以上のGame Changerとなること、間違いありません。

それが劇中でサラっと出てきたので、ストーリー展開より気になったのです。

総当たりならパスワードを割り出せるか

ただし、ハッシュ値から元のパスワードにたどり着く方法がまったくない訳ではありません。候補となるパスワードを片っ端からハッシュ化し、手元のハッシュ値と一致するものを探す総当たりです。これは復号ではなく推測ですが、パスワードが短ければ現実に見つかってしまいます。

MD5は計算が非常に速く、公開されているベンチマークでは市販の高性能GPU（RTX 4090）1枚で1秒間に約1,600億回計算できます。英大文字・小文字、数字、記号の約95種類の文字を使ったパスワードを総当たりすると、すべて試し終えるまでの時間は次のとおりです。

パスワードの長さ	組み合わせの数	すべて試す時間
6文字	約7.4×10¹¹	約5秒
8文字	約6.6×10¹⁵	約11時間
10文字	約6.0×10¹⁹	約12年
12文字	約5.4×10²³	約10万年

8文字なら半日足らずです。HAYATOのようなスーパーコンピュータなら、さらに短い時間で済むでしょう。セリフが「復号して」ではなく「総当たりで割り出して」であれば、あり得る話になります。

もっとも、実際のシステムではMD5よりも計算に時間のかかるbcryptなどのパスワード専用のロジックが使われています。bcryptでは同じGPUでも1秒間に数千回程度しか計算できず、MD5の数千万分の1の速さです。さらに、ユーザーごとに異なるランダムな文字列（ソルト）を加えてからハッシュ化するので、あらかじめ計算しておいたハッシュ値の対応表も使えません。なお、MD5には別々の入力から同じハッシュ値を作れてしまう弱点が見つかっており、この点からもパスワードの保存には使われなくなっています。一方、原像耐性は実用上、今も破られていません。

まとめ

第23話の「このハッシュ値を復号化して」というセリフは、技術的に不可能とされているため、恐らく日本中のエンジニアが画面に向かってツッコミを入れていたことでしょう。「ハッシュ」と「復号」という言葉が並んでいなければ、ここまで違和感はなかったと思います。

この話は、私たち利用者への教訓にもなります。どのハッシュのロジックでも、パスワードが短いほど総当たりで見つかりやすくなります。1文字増えるごとに組み合わせは約95倍になり、表のとおり12文字あればMD5でも10万年かかります。原像耐性を活かせるかどうかは元のパスワードの長さ次第です。長くても、誕生日や単語の組み合わせのように推測しやすいものは、よく使われるパスワードから順に試す辞書攻撃で先に見つかってしまいます。推測されにくい長いパスワードを設定しましょう。

References

RFC Editor. "RFC 1321: The MD5 Message-Digest Algorithm"
RFC Editor. "RFC 6151: Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms"
USENIX. "A Future-Adaptable Password Scheme"
OWASP. "Password Storage Cheat Sheet"
GitHub Gist. "Hashcat v6.2.6 benchmark on the Nvidia RTX 4090"

GMOデスクトップクラウド不正アクセス、攻撃者による個人情報の公開が始まった

2026-10-27T20:59:10+09:00

Table of Contents

GMOインターネットが提供する「お名前.com デスクトップクラウド」への不正アクセスで、攻撃者はGMOに金銭を要求し、応じなければ利用者の情報を公開すると脅していました。GMOは要求に応じない方針を示し、期限の10月27日正午を迎えました。そして同日12時30分、攻撃者とみられる者がGMOと利用者に関する情報と称するものを公開したことを、GMO自身が確認しました。報道によれば、公開されたのは氏名や電話番号などを含む1人分の情報で、攻撃者は今後も毎日正午に順次公開すると予告しています。

要求額は、攻撃者の声明では100万ドルとされていました。一方、GMOインターネットグループの熊谷正寿代表は、ブログで5,000万ドル（約80億円）の要求を受けたと明かしています。

何が起きたのか

お名前.com デスクトップクラウドは、GMOが「FX自動売買専用VPS」として販売しているWindowsのクラウドデスクトップです。MT4/MT5といった取引ツールに対応し、累計20万件以上の利用実績をうたっています。GMOの発表によると、10月19日に利用者からの問い合わせを受けて調査を始め、翌20日に一部の利用者のサーバーに第三者による不正なプログラムが設置されているのを確認しました。21日午前4時からは全プランのサーバーを順次停止しています。影響を受けた可能性があるサーバーは26,739台です。

GMOは「本サービスのシステムにセキュリティ上の問題が存在」したことを認めていますが、侵入経路は公表していません。攻撃者は声明で、顧客の仮想サーバー群がActive Directoryでまとめて管理されており、共通の管理者権限を使って次々に侵入できたと主張しています。この主張が正しければ、攻撃者はGMOの環境だけでなく、利用者全員のデスクトップを掌握していたことになります。

被害は取引口座と手元のPCにまで及ぶ

「FX自動売買専用」という性格が、被害を一段と深刻にしています。自動売買ツールは、人が画面の前にいなくても注文を出し続けるためのものです。そのためには、取引ツールに証券会社やFX会社の口座のログイン情報を保存し、口座にログインしたまま24時間動かしておく必要があります。FX専用として売られていたこのサービスでは、多くのサーバーに取引口座のログイン情報が保存され、口座につながったままの取引ツールが動いていたことになります。GMOも、取引ツールに保存されていたこうしたログイン情報などが第三者に取得され、不正に利用された可能性があると認めています。

ふつうの個人情報の漏えいであれば、攻撃者が盗んだ情報を金銭被害につなげるまでには、なりすましメールで利用者をだますといった段階を踏む必要があります。今回はサーバーに侵入した時点で、攻撃者は利用者の取引口座を直接操作できました。実際に利用者の口座では身に覚えのない取引が行われています。攻撃者は、国内外の70を超える証券会社やFX会社に開設された口座への不正な注文で、口座残高を毀損し続けると脅しています。GMOが利用者に、パスワードの変更はこのサーバー以外の端末から行うよう求めているのも、サーバーそのものが信用できなくなったからです。

被害はクラウド上のサーバーの中だけにとどまりません。リモートデスクトップには、手元のPCのドライブをクラウド側から読み書きできるようにするドライブ共有の機能があります。攻撃者は、利用者に配布されたRDPの設定でこの機能が有効になっていたと主張しています。声明とともに公開されたログには、接続元PCのドライブからブラウザーの閲覧履歴や保存されたログイン情報をコピーした記録が含まれていたとされます。ログが本物かどうかは確認されていません。それでも、GMOが受けた脅迫の中に「本サービスに接続したお客様のPCに関する情報の不正公開と、ランサムウェア攻撃の実行」が含まれていたのは事実です。GMOは期限の前に、PCのバックアップを取ってからケーブルを抜き、電源を落とすよう利用者に呼びかけました。協力を得られた利用者の端末は、GMOが預かって解析しています。

9月に発覚したタイムズカーの不正アクセスでは、約663万件の個人情報と約146万件の運転免許証などの画像が外部に送信されたと同社が発表しています。件数ではGMOの事案をはるかに上回ります。10月に修正版が公開されたPHPの脆弱性PHP2Shellも、多くのWebサイトに影響する深刻なものでした。しかしGMOの事案では、侵入がそのまま取引口座の不正操作につながり、手元のPCのデータまで抜かれた可能性があり、個人情報の公開も始まっています。被害の深刻度は、タイムズカーやPHP2Shellをも上回ると私は考えます。

ホワイトハッカーを抱えるGMOでなぜ起きたのか

GMOインターネットグループは、2022年に「国内最大規模のホワイトハッカー組織」を持つイエラエセキュリティを傘下に収め、セキュリティ事業を展開してきました。高い技術力を持つホワイトハッカーは、GMOが売りにしてきたものです。

そのGMOで、攻撃者の主張どおり顧客の仮想デスクトップまでActive Directoryで一元管理し、その管理者権限を抜かれたのだとしたら、今どき「マジですか」と言いたくなるお粗末さです。しかも熊谷代表は、社内のホワイトハッカーが改善すべき課題を事前に現場へ指摘していたことを認めています。現場がサービスの継続や他の課題との優先順位を考えて対応を進めた結果、「対応の深度とスピードが十分ではなく、攻撃者にその間隙を突かれてしまいました」とのことです。技術者がいても、指摘を受けて動けなければ意味がありません。

補償はどこまで受けられるのか

GMOは、利用者全員への一律5,000円の見舞金と、不正取引による実現損失の補償を発表しました。さらに、攻撃者が公開した情報の中に自分の情報が含まれていた利用者には、情報の区分ごとに10,000円から25,000円、合計で最大300万円の特別見舞金を支払うとしています。ランサムウェアの被害を受けた利用者には、同等の性能の新しいPCを提供する方針も報じられています。

ただし、利用規約では補償はごく限られています。お名前.com レンタルサーバーサービス会員規約の第14条では、デスクトップクラウドの利用に関して会員に生じた損害について、GMOは責任を負わないとしています。第34条では損害賠償の上限を利用料金の1か月分とし、事業者会員に対しては一切責任を負わないと定めています。今回の見舞金や補償は、規約とは別の特別措置という位置づけです。

不正取引の補償も、対象は実現損失（取引の差損と手数料など）に限られます。市場の変動による損失や得られたはずの利益は含まれず、まずは利用者自身が取引所などに取り消しや返金を相談するよう求められています。手元のPCから抜かれたかもしれないデータは、公開されない限り見舞金の対象にもなりません。ご愁傷様です。

まとめ

GMOは国内最大規模のホワイトハッカー組織を抱え、そのホワイトハッカーは改善すべき課題を事前に現場へ指摘していました。それでも対応は追いつかず、攻撃者にその隙を突かれました。被害を受けたのは、取引口座のログイン情報をサーバーに預け、手元のPCをつないでいた利用者です。

いくら技術力の高い集団がいたからといって、組織にバカがいないという証左にはなりません。今回の事案は、そのことを示す教訓だったと思います。

PHP2Shell収束後に検討すべき「情報発信サイトの脱CMS」

2026-10-25T22:55:00+09:00

Table of Contents

2026年10月21日、PHPの開発チームは、認証なしで任意のコードを実行できる深刻な脆弱性2件を修正したバージョンを公開しました^[1]。脆弱性の中身と、すぐに更新できない場合の対処は「高市首相が「大至急」と呼びかけるPHPの脆弱性PHP2Shellとは」にまとめています。WordPressをはじめとする、Webサイトの構築に使うContent Management System（以下、CMS）の多くはPHPの上で動いているため、影響は数えきれないほどのWebサイトに及びました。まともな企業であれば、すでにパッチを当て終えて一段落している頃でしょう。

では、次に同じような脆弱性が見つかったら、また慌ててパッチを当てるのでしょうか。この記事では、企業の製品情報やニュース、自治体のお知らせなど、記事が中心の情報発信サイトに絞って、長期的な再発防止策を考えます。

なお、情報発信ではなく業務に使うシステムは、動的な仕組みが必要になることがあるため、本記事では扱いません。

パッチを当てて終わりでよいのか

PHP2Shellでこれほど被害が広がったのは、PHPで動くCMSが多くの組織のメインサイトで使われていたからです。WordPressに代表されるこうしたCMSで作られたサイトは、いたるところにあります。

パッチを当てれば、今回のPHP2Shell問題は塞げます。しかし、防げるのはその脆弱性だけです。PHP、CMS本体、プラグインのいずれにも、まだ見つかっていない脆弱性が残っています。PHP2Shellの発見には生成AIが使われました^[2]。生成AIの活用が広がれば、こうした脆弱性が見つかる頻度は今後大幅に上がっていくはずです。公開サーバーでPHPのような動的な仕組みが動いている限り、新しい脆弱性が見つかるたび、攻撃者より早くパッチを当てるという無限に続く競争に加わるしかありません。

しかも、その競争に毎回勝てるとは限りません。キャンペーンのために作って放置したサイトや、ブランド統合で使わなくなった旧サイトには、担当者すらいないことがあります。こうしたサイトはパッチ対応から漏れやすく、被害はたいていそこから広がります。

ここで一度立ち止まって考えてみてください。そもそも、そのサイトに動的な仕組みは必要なのでしょうか。

情報発信サイトに動的な仕組みは必須ではない

企業のメインサイトに載っているのは、製品情報やニュース、会社概要といった記事です。これらは誰がいつ見ても同じ内容で構いません。閲覧者ごとに表示を変える必要はありません。

内容が変わるのは、記事を更新したときだけです。更新が1日に何度あっても、そのたびにHTMLを書き出しておけば足ります。それなのにCMSで作ったサイトは、閲覧されるたびにサーバー上でPHPを動かし、DBから記事を取り出してページを組み立てています。この用途には過剰な構成です。

PHP2Shellの修正版が出た直後には、国税庁や気象庁、東京都や大阪市なども、一部のWebサービスを予防的に止めました^[3]。被害を防ぐための判断としては正しいでしょう。

しかし、自治体のサイトこそ、誰が見ても同じ情報を出すだけのサイトの典型です。それなのに多くの自治体は、技術構成が公開されていないパッケージCMSを、中身を把握しないまま調達しています。同じ構成のままなら、災害情報や行政手続きの案内を住民が必要とするときにも、同じ判断を迫られかねません。

情報発信サイトは静的サイトで十分

こうした情報発信サイトは、静的サイトで十分です。静的サイトとは、あらかじめ書き出したHTMLを配信するだけのサイトです。

静的サイトの公開側には、PHP、DB、管理画面のいずれもありません。PHP2Shellのような脆弱性は、そもそも届きようがありません。書き出したファイルは、静的ファイルの配信だけを行うホスティングサービスやCDNに置きます。Amazon S3とCloudFrontの組み合わせや、Cloudflare Pagesなどです。パッチを当てるべきサーバーを、自分たちで持つ必要はありません。

問い合わせフォームやサイト内検索のように、「動的でないと無理」と思われがちな機能もあります。これらも別の手段で賄えます。

CMSに頼らず静的サイトを運用する方法を、3つ紹介します。公開側の構成はどれも同じで、違うのは記事を書いてHTMLを書き出すまでの編集側です。どの方法を選ぶかは、誰が記事を書くか、既存の記事をどれだけ移行する必要があるか、移行にどれだけコストをかけられるかで決まります。

静的サイトジェネレーター

HugoやAstroに代表される静的サイトジェネレーターを使う方法です。原稿をMarkdownで書いてGitで管理し、ビルドするとサイト全体のHTMLが書き出されます。サーバー側で動くものが何もないので攻撃面が小さく、費用も安く済みます。ただし、書き手がMarkdownやGitに慣れていないと運用が回りません。社内にエンジニアがいて、書き手も技術に抵抗がない組織に向いています。

flowchart LR
  subgraph edit["編集側（社内）"]
    W["書き手"] -->|Markdownで執筆| G["Gitリポジトリ"]
    G -->|変更を反映| B["ビルド
Hugo・Astroなど"]
  end
  subgraph pub["公開側"]
    C["静的ホスティング／CDN"]
  end
  B -->|HTMLを配置| C
  C -->|HTMLを配信| R["閲覧者"]

ヘッドレスCMSと静的サイトジェネレーター

ヘッドレスCMSと静的サイトジェネレーターを組み合わせる方法です。ヘッドレスCMSとは、記事を書いて管理する編集画面だけを提供し、閲覧者に見せるページは持たないCMSです。microCMSやContentfulがSaaSとして提供しています。

編集者はヘッドレスCMSの画面で記事を書き、静的サイトジェネレーターはビルドのときにAPIで記事を取り出してHTMLを書き出します。ヘッドレスCMSから更新を通知させておけば、記事を更新するたびにビルドが自動で走り、数分で公開側に反映されます。従来のCMSに近い操作で書けるので、エンジニアでない担当者が更新するサイトでも無理なく移行できます。

代わりに、SaaSのアカウントという新たに守るべき対象が生まれます。多要素認証を必須にし、権限を必要な人に絞っておく必要があります。

flowchart LR
  subgraph edit["編集側"]
    E["編集者"] -->|ブラウザで執筆| H["ヘッドレスCMS
SaaS"]
    H -->|更新を通知| B["ビルド
Hugo・Astroなど"]
    B -->|APIで記事を取得| H
  end
  subgraph pub["公開側"]
    C["静的ホスティング／CDN"]
  end
  B -->|HTMLを配置| C
  C -->|HTMLを配信| R["閲覧者"]

委託先から原稿を受け取る

そもそもCMSの利点は、HTMLの知識がない担当者でも、自分たちで記事を書いて更新できることにあります。ところが、CMSでサイトを作っておきながら、記事の執筆は外部に委託している企業や自治体が少なくありません。委託先が原稿を書き、CMSへの入力まで代行していることもあります。「Webサイトを作るにはCMSが必要」という程度の理由でCMSを選び、その利点をまったく使っていないのです。

使っていない利点のために、PHPやDB、管理画面、プラグインという攻撃の入口を抱えているわけです。それなら社内に編集画面を置く必要はありません。委託先から原稿を受け取り、静的に公開すれば足ります。委託先にはHTMLで納品してもらい、公開作業だけを社内で管理します。

flowchart LR
  subgraph edit["編集側"]
    V["委託先"] -->|HTMLを納品| S["社内の担当者"]
  end
  subgraph pub["公開側"]
    C["静的ホスティング／CDN"]
  end
  S -->|確認してアップロード| C
  C -->|HTMLを配信| R["閲覧者"]

動的な機能の扱い

問い合わせフォームは、フォーム用のSaaSを使うか、送信だけを受け付ける小さなサーバーレス関数で賄えます。サイト内検索は、ビルドのときに索引を作っておき、ブラウザ側で検索する方法があります。外部の検索サービスを使う手もあります。こうするとリスクは外部サービスやビルド時の依存パッケージに移ります。それでも、常時インターネットに公開されるサーバーを自分たちで抱えることはありません。

まとめ

記事中心の情報発信サイトは、静的サイトを既定にすべきだと考えます。CMSは、使う理由がはっきりしている場合にだけ選ぶ、という順番です。

CMSを否定しているわけではありません。使う理由が明確で、抱えるリスクに見合うと判断できるなら、採用すればよいのです。ただしその場合は、動的な仕組みを持つ分の管理と責任を引き受けることになり、それに対応できる体制と仕組みも欠かせません。CMSやプラグインがどのような言語のどのバージョンに依存しているかすら把握できない組織には、残念ながら、もはやCMSを使う資格はありません。

ここで挙げた3つの方法は、どれも明日から切り替えられるものではありません。既存の記事の移行、デザインの作り直し、委託契約の見直しと、それなりの手間と予算がかかります。だからこそ、次年度に向けた計画を今から始めるべきです。多くの企業や自治体では、秋から冬にかけて次年度の予算を組みます。PHP2Shellの記憶が新しい今なら、予算も通しやすいはずです。

まず手をつけるべきは棚卸しです。自分たちの組織のどこでPHPが動いているかを洗い出し、放置されたサイトは廃止してください。そのうえで、残すサイトごとに移行先を決め、次年度の計画に載せます。

パッチ対応が一段落した今こそ、次の脆弱性に備えて構成を見直す時期です。

高市首相が「大至急」と呼びかけるPHPの脆弱性PHP2Shellとは

2026-10-22T03:14:44+09:00

Table of Contents

2026年10月21日22時台（日本時間）、PHPプロジェクトはPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開しました。修正されたのは、認証なしでリモートからコードを実行される（RCE）脆弱性2件です。どちらもCVSS v4.0で9.2の「Critical」と評価されています。この2件は「PHP2Shell」と呼ばれています。

高市首相が21日夜にXで「今夜に対応して頂きたい大至急のお願い」と呼びかけるほどの深刻な脆弱性です。多くの企業では、本番障害と同じ扱いで夜を徹してパッチを当てています。あなたの組織は大丈夫ですか。

2件の脆弱性の中身

CVE	名称	原因
CVE-2026-109618	RCE via OOM corruption	メモリ不足（OOM）のとき、PHPは`longjmp()`でリクエスト処理から抜ける。初期化が終わっていないデータが残り、リクエストの終了処理がそれを正しいデータとして扱ってしまう
CVE-2026-109619	RCE via stale global state	前のリクエストが使っていたグローバル状態が、メモリを解放した後も残る。同じワーカーが次のリクエストを処理するとき、初期化より前にその古い状態を使ってしまう（use-after-free）

CVE-2026-109618では、攻撃者がmultipartのリクエストを細工して、わざとメモリ不足を起こします。Content-Lengthを持たないリクエストでpost_max_sizeの検査をすり抜けたり、1つのパートに大量のヘッダーを詰め込んだりする手口が、公式アドバイザリで挙げられています。CVE-2026-109619は、エラーやメモリ不足で処理が中断したリクエストの「残骸」を、次のリクエストに使わせる攻撃です。既定で有効になっているセッションのアップロード進捗機能が、その経路の1つとして確認されています。

2件の評価は同じで、ネットワーク経由で攻撃でき、認証とユーザー操作は必要ありません。攻撃の難易度は「高」とされていますが、PHP 8.5.12などの修正版が出た時点で、すでに実証済みの攻撃手順がありました。成功すると、攻撃者はWebサーバーのワーカーの権限で任意のコードを実行できます。

影響を受ける環境

PHPプロジェクトは、Webリクエストを処理するすべてのPHPが対象だとしています。

PHPはWebサイトのサーバー側で最も広く使われている言語です。W3Techsの2026年10月21日時点の集計では、サーバー側の言語が判明しているサイトの69.3%がPHPで動いています。全Webサイトの39.6%を占めるWordPressをはじめ、Drupal、MediaWiki、Moodle、EC-CUBEもPHPで書かれています。Laravelで作られた業務システムも同様です。自社でPHPを書いた覚えがなくても、ブログや会員サイト、ECサイトがこれらで動いていれば対象になります。

アプリケーション側に脆弱性がなくても攻撃は成立します。特にApacheのmod_phpでは、アプリケーションのコードが1行も動く前に、認証なしのリクエストだけで攻撃が成立すると実証されています。

「リモートからコードを実行される」とは、インターネットの向こうにいる攻撃者が、Webサーバー上で好きなプログラムを動かせるということです。攻撃者に必要なのは、細工した通信をサイトに送ることだけです。IDやパスワードを盗む必要も、利用者に怪しいリンクをクリックさせる必要もありません。

乗っ取られたサーバーでは、そのサイトのプログラムが読める情報を攻撃者も読めます。WordPressであれば設定ファイルにデータベースのパスワードが書かれているので、会員の氏名やメールアドレス、注文履歴が入ったデータベースにそのまま手が届きます。ページを書き換えて、訪問者をフィッシングサイトへ誘導したり、マルウェアを配ったりもできます。社内のネットワークにつながったサーバーなら、そこから社内への侵入の足がかりにもなります。

修正版公開までの経緯

PHPプロジェクトは10月21日22時台（日本時間）、予告していた23時を前倒しして、サポート中のすべての系列で修正版を緊急リリースしました。

問題は、この修正版が出る前から起きていました。脆弱性は通常、修正版と同時に公表されます。先に知られると、守る手段がないまま攻撃を受けるからです。今回も10月22日に公表される予定でしたが、10月20日には脆弱性の番号がインターネット上で出回り始めました。PHPプロジェクトは21日未明、その日のうちに修正版を出すと予告しました。

それでも修正版の公開より先に、攻撃の手順を示すプログラムや解説が出回りました。Cloudflareは、修正版が出る前の時点で攻撃が始まっていることを確認しています。

さらに、修正版と同時に、どんな通信を送ると何が壊れるのかを具体的に説明した技術情報も公開されました。これまで攻撃の手順を知らなかった攻撃者も、これを読めば攻撃を組み立てられます。修正版を当てるまでの時間が、そのまま攻撃を受ける時間になります。

国内の緊急対応

21日21時55分ごろ、高市首相がXで次のように呼びかけました。

皆様に、今夜に対応して頂きたい大至急のお願いです。

多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。

公開しているウェブサイトでPHPを使用しているか確認し、今夜、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします。

修正パッチを速やかに適用することが困難な場合は、例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つと考えられます。

— 高市早苗首相、X

高市首相のツイートは一発でITリテラシーが低い人にも、その深刻さを納得させることができたでしょう。いまだに技術的なリスクが経営を直撃するインパクトになり得ることを理解できない経営層が日本には多いので、現場は非常に助かったと思います。

政府機関や自治体、銀行は、首相の投稿より前の21日夕方から、Webサイトやサービスを次々に止めていました。厚生労働省は16時から、介護サービス情報公表システムを「緊急の脆弱性対応」のため翌日12時まで停止しました。財務省もホームページの一部コンテンツを止め、管理下のWebサーバーの緊急点検と修正の適用に入りました。

自治体では、札幌市が21時に公式ホームページを止め、簡易サイトに切り替えました。会津若松市はホームページの一部機能や公共施設予約システム、除雪運行システムなど16のサービスを停止し、日野市も問い合わせフォームを止めています。

銀行も同様です。静岡銀行はホームページとスマートフォンアプリを、第四北越フィナンシャルグループは銀行・証券・カード会社の一部サービスを、七十七銀行はホームページを含む一部サービスを止めました。静岡銀行と七十七銀行は、いずれも「予防的な措置」と説明しています。

千葉県内では、京葉銀行がPHPへの注意喚起を理由に、ネットバンキングなど一部を除いてサービスを止めました。千葉銀行も21日付で、住宅ローンの申込や来店予約など、ホームページ上の16のサービスを「システムメンテナンス」として休止しています。一方、千葉県と千葉市の公式サイトは22日未明の時点で通常どおり表示されており、サービス停止の告知も出ていません。

まとめ

修正版の公開を受けて、政府機関や自治体、銀行をはじめ、多くの組織が夜を徹して更新を進めています。PHPプロジェクトは、更新だけが完全な対策だとしています。すぐに更新できない環境向けの設定も公表されていますが、更新までの時間を稼ぐためのもので、攻撃を防ぎきれるわけではありません。

一方で、自社のWebサイトがPHPで動いているかどうかを把握していない組織も少なくないはずです。ホームページやECサイト、会員サイトの制作や運用を外部に任せていれば、なおさらです。経営層の方は、首相が直接呼びかけるほどの脆弱性だと受け止めてください。そのうえで、自社のサイトがPHPを使っているか、誰がいつ更新するのかを、今日のうちに確かめてください。更新の目途が立たないなら、首相の呼びかけにあるとおり、サイトを一時的に止めることも選択肢になります。

続報(2026-10-22 16:30)

私自身の利用したことのあるサイトでいうと、次のようなサイトが本日対応のため一時停止していました。

ScanSnap Home/Cloud/Cloud+ (PFU)
メニコン会員サイト
JRE MALL
CLIP STUDIO
リンクシェア
CoSTORY

修正版の公開から1日たち、攻撃と被害の状況も見えてきました。

Amazonは、公表の4日前にあたる10月17日の時点で、同社が攻撃の観測用に置いているおとりのサーバーがPHP2Shellを狙った攻撃を受けていたと公表しました。修正版の公開後は、複数の攻撃者による攻撃を観測しており、すでに広く悪用されていると評価しています。侵害の有無を調べるときは、公表日ではなく10月17日までさかのぼるよう勧めています。

国内では、POSシステムや勤怠管理などのクラウドサービスを提供するバルテックが22日、「PHPの脆弱性を標的としたサイバー攻撃」による不正アクセスで、顧客情報が流出したとみなされる事実を確認したと公表しました。同社は悪用された脆弱性を明らかにしておらず、PHP2Shellによるものかは分かっていません。20を超えるサービスを止めており、復旧は早くても10月26日の見込みです。

PHPを書いた覚えがなくても対象になるという話は、ネットワーク機器にも当てはまります。Palo Alto Networksは、ファイアウォールのOSであるPAN-OSと管理製品のPanoramaも影響を受けると公表しました。影響は管理画面に限られますが、修正版の公開時期は未定です。それまでは、管理画面に接続できる相手を信頼できる社内のアドレスに絞るよう求めています。こうした製品は、サーバーのPHPを更新しても直りません。

JPCERT/CCは22日の注意喚起で、侵害を調べる観点を示しました。不自然に長いPHPSESSIDのCookie、不審なmultipart/form-dataのリクエストとその前後のメモリ不足エラーやHTTP 500、PHPのワーカープロセスが異常終了や再起動を繰り返した痕跡などです。こうした痕跡がなくても、攻撃を受けていないとは断定できないとしています。修正版を当てたら終わりではなく、当てる前に侵入されていないかを確かめる段階に入っています。

References

PHP. "Security advisory: Critical remote code execution vulnerabilities, update now"
PHP. "[ANNOUNCE] Upcoming Critical PHP Security Release"
GitHub php/php-src. "RCE via OOM corruption (GHSA-w8hw-w9fx-j79w)"
GitHub php/php-src. "RCE via stale global state (GHSA-6wmf-4rv5-p3rp)"
IPA. 「【事前準備のお願い】PHPのセキュリティリリース公開予定について」
IPA. 「PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)」
JPCERT/CC. 「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」
Amazon Web Services. "Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot"
Palo Alto Networks. "Impact of Critical Vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619) on Palo Alto Networks Products"
バルテック. 「不正アクセスによるお客様情報流出の可能性および一部サービス停止のお知らせ」
財務省. 「PHPの脆弱性対応に伴うWebサイト・一部コンテンツの一時停止のお知らせ」
厚生労働省. 「介護サービス情報公表システムシステムメンテナンスに関するお知らせ」
札幌市. 「公式ホームページ緊急メンテナンス」
会津若松市. 「市インターネットサービスの一時停止について」
日野市. 「ホームページのお問い合わせ専用フォーム及び市政にひとことの一時停止について」
静岡銀行. 「ホームページ、『しずぎんアプリ』一時停止のお知らせ」
第四北越銀行. 「システムのセキュリティ強化に伴う一部サービスの一時停止について」
七十七銀行. 「臨時システムメンテナンスによる一部サービスの利用停止について」
京葉銀行. 「システムメンテナンスのお知らせ」
千葉銀行. 「当行ホームページのシステムメンテナンスに伴う一部サービスの休止について」
W3Techs. "Usage statistics of PHP for websites"
W3Techs. "Usage statistics and market share of WordPress"
Tenable. "php2shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions About Critical PHP Remote Code Execution Vulnerabilities"

警察による匿流スマホ遠隔解析は技術的に可能か

2026-10-16T18:04:48+09:00

Table of Contents

時事通信によると、2026年10月16日、政府は警察官職務執行法（警職法）の改正案を閣議決定しました。匿名・流動型犯罪グループ（匿流、トクリュウ）が犯行に使うスマートフォンの中の情報を、警察が遠隔で解析できるようにするものです。今の臨時国会で成立すれば、公布から6か月以内に施行されます。

匿流の指示役は、秘匿性の高い通信アプリを使って実行役を集め、犯行を指示しています。警察がそのやりとりを「遠隔解析」で読むと聞いて、暗号を破るのだろうか、そもそもそんなことが技術的にできるのだろうか、と疑問に思った人も多いのではないでしょうか。

この記事では、報道されている遠隔解析が技術的にどういうものなのかを、セキュリティの専門家ではないエンジニアにも分かるように解説します。目的は仕組みを理解することで、手口を再現できるような説明はしません。

暗号解読は不可能

匿流がよく使うとされる通信アプリの1つがSignalです^[1]。Signalでは、すべてのメッセージがエンドツーエンド暗号化（E2EE）されています。では、警察はこの暗号を解読してメッセージを読めるのでしょうか。

もちろん、そんなことは不可能です。

E2EEでは、メッセージは送信者の端末で暗号化され、受信者の端末で初めて復号されます。復号に使う鍵は両端の端末にしかなく、運営元のサーバにもありません。通信を途中で傍受しても、運営元にデータの提出を求めても、手に入るのは意味をなさない暗号文だけです。現代の暗号を計算で破ることは、警察はもちろん、国家の情報機関にとっても現実的ではありません。

警察庁の有識者検討会も提言の中で、通信アプリの暗号化技術のため、通信事業者の協力を得ても犯行グループの通信内容を解明するのは困難だと認めています。

では、警察はどうやって対象者のメッセージを遠隔解析するのでしょうか？

ヒントは、E2EEが守っているのはあくまで通信の経路であるということです。

犯人のスマートフォンを乗っ取る

経路で読めないのなら、端末で読めばよい。これが遠隔解析の発想です。

E2EEで守られたメッセージも、送信者が文字を打ち込んでから暗号化されるまでと、受信者の端末で復号されてからは平文です。画面に表示できる以上、端末の中ではメッセージは読める状態にあります。端末そのものに入り込めば、暗号を破らなくてもメッセージを読めるわけです。このように通信の両端（エンドポイント）を狙う手法は、「エンドポイント攻撃」と呼ばれます。

警察庁の提言でも、遠隔解析は犯行グループが使う端末にアクセスし、端末内の情報を確認して必要な情報を複写・取得するものとされています。検討会の提言には、実施手法について「端末の脆弱性を突いたり、端末の利用者を欺罔する手段を用いざるを得ない場面等があ」るという意見も記されています。要するに、遠隔解析とは警察が法律に基づいて行うハッキングです。

ドイツの事例では、刑事訴訟法や州の警察法に基づいて捜査当局が端末から直接情報を取得することが認められています。そのために容疑者の端末へ送り込むソフトウェアは「国家トロイ（Staatstrojaner）」と呼ばれています。

どうやってスマートフォンを乗っ取るのか

他人のスマートフォンをそんなに簡単に「ハッキング」できるものなのでしょうか？

相手に気づかれないまま端末へ入り込むには、多くの場合、OSやアプリの脆弱性を突く必要があります。スマートフォンのOSは、アプリがほかのアプリのデータを読んだり、システムを書き換えたりできないように厳しく制限しています。この制限をくぐり抜ける手段が脆弱性です。特に、メーカーがまだ把握しておらず、修正もされていない脆弱性を「ゼロデイ」と呼びます。脆弱性を突いて端末に入り込む攻撃は、入り口の違いで大きく2つの型に分けられます。

1つ目はワンクリック型です。SMSやメールで細工したリンクを送り、相手がそれを開いた瞬間にブラウザなどの脆弱性を突いて侵入します。フィッシング詐欺でもおなじみの手口ですが、相手にリンクを開かせる必要があります。しかし、メッセージのやりとりにSignalのようなアプリを使うほど警戒心が強い相手ですから、そのような誘導は容易でないでしょう。

2つ目がゼロクリック型です。こちらは、攻撃者が相手のスマートフォンにメッセージを送ります。相手が何も操作しなくても、メッセージを受信しただけで侵入が成立します。

受信しただけで侵入されるのは、iOSやAndroidが、受け取ったメッセージをユーザーが開く前に自動で処理しているからです。画像や動画のサムネイルを作る、リンクのプレビューを生成する、添付ファイルの形式を判別する、といった処理です。そのためには、受け取ったデータを解析（パース）し、画像や動画としてデコードしなければなりません。このデコーダに脆弱性があると、細工したデータを送りつけるだけで、デコードの最中に攻撃者のコードが動き出します。

つまり、ゼロクリック攻撃で狙われるのは、メッセージアプリそのものというより、その下で動いている画像や動画などを処理する共通の部品です。こうした部品はOSの奥深くにあり、多くのアプリから使われています。

ゼロクリック攻撃は理論上の話ではなく、実際に見つかっています。

1つはiPhoneを狙ったFORCEDENTRYです。2021年にCitizen Labが、サウジアラビアの活動家のiPhoneから見つけました。iMessageで画像に見せかけたファイルを送りつけ、画像を処理する部品の脆弱性を突いて、スパイウェアPegasusを送り込みます。Appleは同じ年の9月にiOS 14.8で修正しました。

もう1つはAndroidのStagefrightです。2015年に見つかった、動画を処理する部品の脆弱性で、細工した動画をMMSで送るだけで端末に侵入できました。必要なのは相手の電話番号だけで、当時のAndroid端末の95%が影響を受けるとされました。

この2つの例から分かるように、多くのスマートフォンがゼロクリック攻撃の対象になり得ます。特にAndroidは端末メーカーや機種が多く、OSのアップデートが届くまでに時間がかかったり、古い機種には届かなかったりします。そのため、脆弱性が修正されないまま残りやすいという事情もあります。

さらに、侵入に成功したスパイウェアは、攻撃に使ったメッセージや通知を削除して痕跡を消します。そのため、利用者が攻撃に気づくことはまずありません。

乗っ取りが可能な条件

ゼロクリック攻撃が実在するのなら、警察はいつでも匿流のスマートフォンを乗っ取れるのでしょうか。

そうではありません。乗っ取りを成功させるには、次の条件がすべてそろわなければなりません。

対象者を特定できる
その対象者が使っている端末を特定できる
その端末まで攻撃を届ける経路がある
端末のOSやアプリに未公表の脆弱性（ゼロデイ）があり、それを使える
その脆弱性がアップデートでまだ塞がれていない
侵入の痕跡を隠せる

まず、誰を狙うのかが決まらなければ始まりません。匿流の指示役は実行役の前にも姿を現さず、正体を隠しています。警察庁の資料では、被害者からの通報、仮装身分捜査、犯罪組織から抜けた人の供述、過去の捜査情報などをもとに、犯人の端末を特定する流れが示されています。それでも指示役が端末や電話番号を頻繁に替えれば、特定した端末はすぐに使われなくなります。

次に、特定した端末に攻撃を届ける経路が必要です。ゼロクリック攻撃であれば、電話番号やメッセージアプリのアカウントが分かれば届けられる場合があります。

いちばん高いハードルはゼロデイです。メーカーが把握している脆弱性は、すでに修正されているか、近いうちに修正されます。ゼロクリック攻撃を成立させるには、受信データの処理に始まり、OSの制限の突破、端末への常駐まで、いくつものゼロデイをつなぎ合わせた「チェーン」が必要です。これを見つけて実際に使える形に仕上げるには、高度な専門知識と時間がかかります。

しかも、ゼロデイは使えば減っていく消耗品です。FORCEDENTRYは見つかってから間もなくiOS 14.8で修正され、使えなくなりました。攻撃に使うほど見つかる危険は高まり、見つかれば修正されます。乗っ取りの能力を保ち続けるには、新しいゼロデイを次々に手に入れなければなりません。

最後に、痕跡を隠す技術も必要です。侵入に成功しても、相手に気づかれて端末を捨てられれば、それ以上の情報は得られません。

これらの条件がすべてそろって、初めて乗っ取りが可能になります。遠隔解析は技術的に可能ですが、誰の端末にでも、いつでも使える手段ではありません。

制度面の制約

乗っ取りのハードルは高いものの、技術的に可能であることに変わりはありません。その能力を誰に、どんな条件で使わせるのかは、法律で厳格に定め、司法が監督すべきものです。

毎日新聞の報道によると、改正案には次のような歯止めが盛り込まれています。

実施する前に裁判官の許可状を得る
対象は、犯人同士の連絡や、被害が切迫している人への連絡に使われたと認める合理的な理由がある端末に限る
数人が共謀する犯罪で、緊急の必要があり、ほかの方法では情報を速やかに集めるのが著しく困難な場合に限る
解析は、警察庁長官が指名する「被害防止電子計算機調査官」が行う
許可されていない情報を取得した場合は消去し、公安委員会に報告する
端末の利用者には、罪名、許可状の発付日、解析の実施日を事後に通知する

一見すると十分な歯止めに見えますが、気になる点が4つあります。

遠隔解析は捜査ではなく、犯罪を予防するための行政権限として警職法に置かれる。刑事訴訟法に基づく捜査なら、集めた証拠は裁判で検証され、違法な手続きで得た証拠は排除される。予防のための行政調査は、こうした刑事手続きの歯止めをそのまま受けない。提言は「捜査目的で権限を行使することは許されない」とするが、共同通信の報道によると、警察庁は解析で犯罪が確認された場合に「必要に応じて捜査に活用する場合もある」と説明している。予防と捜査の線引きが、運用の中で緩んでいくおそれがある。
ゼロデイをどう調達するのかが見えない。乗っ取りにはゼロデイが欠かせず、ゼロデイには表の市場もある。脆弱性ブローカーは、ゼロデイを見つけた研究者やハッカーから買い取り、政府機関などのごく限られた顧客に売る仲介業者だ。その1つであるZerodiumは2019年、Androidでゼロクリックかつ端末に常駐できる攻撃チェーンを最大250万ドル、iOSの同等のものを最大200万ドルで買い取ると公表した。しかも、ゼロデイは賞味期限が短い。高額で買っても、メーカーに見つかって修正されれば、すぐに使えなくなる。日本の警察がこうした市場から買うにせよ、自前で開発するにせよ、多額の公費を使い続けることになる。
脆弱性を温存するジレンマがある。警察が使うためにゼロデイを手元に置けば、その脆弱性はメーカーに報告されず、修正されないまま残る。同じ脆弱性を犯罪者や外国の情報機関が見つけて悪用すれば、匿流とは無関係な一般のユーザーまで危険にさらされる。ドイツでも、ハッカー団体のカオス・コンピュータ・クラブ（CCC）などがこの点を批判してきた。
外から検証できない。具体的な手法は、犯行グループに対抗措置をとられないよう秘匿される。秘匿すること自体には理由があるが、その結果、警察が何をどこまでできるのかを国民が確かめる手段はなくなる。

制度の問題とは別に、私自身の危惧を2つ書いておきます。

1つは、今の日本の警察に、遠隔解析できるだけの技術的な能力があるのかという疑問です。ここまで見てきたように、ゼロクリック攻撃を成立させるには、ゼロデイを見つけるなり買うなりして実際に使える形に仕上げ、痕跡を残さずに運用する高度な技術が要ります。これまで国家の情報機関やNSO Groupのような専門企業が担ってきた領域です。法律ができても、それを担える人材と技術がなければ、制度は絵に描いた餅で終わるか、外部の業者へ丸投げされかねません。

もう1つは、警察が暴走して冤罪を生む可能性です。思い出すのはWinny事件です。2004年、京都府警ハイテク犯罪対策室は、ファイル共有ソフトWinnyを開発した金子勇氏を、著作権法違反幇助の疑いで逮捕しました。金子氏は2011年に最高裁で無罪が確定しましたが、それまでに7年以上の歳月を奪われました。この事件によって、日本のP2P技術の発展は20年以上遅れたと私は考えています。私は京都府警ハイテク犯罪対策室を一生許しません。

当時、ハイテク犯罪対策は警察にとって新しい領域でした。同じ対策室は、金子氏の逮捕の前年にもWinnyの利用者を逮捕しており、その後も「全国初」となるサイバー犯罪の摘発を重ねています。新しい領域で成果を求めるあまり暴走したのではないか、と私は見ています。遠隔解析も、専門の調査官という新しい仕組みを作って始める新しい領域です。成果を求める圧力が、同じような暴走を生まないかが心配です。まして遠隔解析は、外から検証できない手法で行われるのです。

まとめ

報道されている匿流スマホの遠隔解析は、暗号を破るものではありません。端末に入り込み、暗号化される前や復号された後のメッセージを読むものです。相手が何もしなくても端末を乗っ取るゼロクリック攻撃は実際に存在し、使われてきました。その意味で、遠隔解析は技術的に可能です。

ただし、誰の端末にでも、いつでも使える手段ではありません。対象者と端末を特定し、高価ですぐに使えなくなるゼロデイを手に入れ続けて、ようやく実現する能力です。そもそも、今の警察にその能力があるのかも疑問です。

それでも、技術的に可能である以上、この能力を誰に、どんな条件で使わせるのかは制度の設計にかかっています。予防と捜査の線引き、ゼロデイの調達と温存、外から検証できない手法をどう扱うのか。Winny事件のような暴走を繰り返さないためにも、国会の審議ではこうした点にこそ目を向けてほしいと考えています。

References

確認日はいずれも2026年10月16日。

警察庁. 「匿名・流動型犯罪グループによる犯罪被害対策のための技術的措置に関する有識者検討会提言（要旨）」(PDF)
警察庁. 「匿名・流動型犯罪グループによる犯罪被害対策のための技術的措置に関する提言」(PDF)
警察庁. 「有識者検討会第2回英・独における類似制度紹介説明資料」(PDF)
Citizen Lab. "FORCEDENTRY: NSO Group iMessage Zero-Click Exploit Captured in the Wild" (2021)
Zimperium. "Experts Found a Unicorn in the Heart of Android" (2015)
ZERODIUM. "Exploit Acquisition Program"（2019年9月時点のアーカイブ）
Chaos Computer Club. "Stellungnahme zur Erweiterung des Einsatzes von staatlicher Schadsoftware" (2017)

たまにTelegramを安全だと信じて今でも使っている阿呆がいます。Telegramの通常のチャットは、端末とサーバの間で暗号化されているだけで、E2EEではありません。メッセージはTelegramのサーバに保存されていて、運営元が技術的には読める状態にあります。E2EEになるのは、ユーザーがシークレットチャットを開始した場合だけで、これは1対1の会話に限られます。 ↩

タイムズカーへの問い合わせ結果

2026-10-14T21:33:50+09:00

Table of Contents

先日のタイムズカーの個人情報漏えいを受けて、タイムズモビリティの「退会者様専用お問い合わせフォーム」から問い合わせました。私はこの7年間で2度自家用車を買い替え、その都度タイムズのカーシェアを利用しています。退会者として運転免許証の画像が残されていた可能性が高いからです。

タイムズモビリティからの回答

以下が返信されてきた回答です。

2026年9月25日に発覚いたしました、タイムズカーWebシステムへの不正アクセスによる個人情報の漏えいにより、多大なるご心配とご迷惑をおかけしておりますことを、深くお詫び申し上げます。

先般、お問い合わせフォームよりご提供いただきました情報をもとに調査いたしましたが、ご提供内容に該当するタイムズカー会員様を特定することができませんでした。そのため、大変恐れ入りますが、お客様の情報の漏えいの有無につきましても、確認できておりません。

後日、あらためて弊社のタイムズカー会員情報と照合させていただきたく、お客様の登録情報をお伺いするための専用フォームの準備を進めております。準備が出来次第、弊社より追ってメールでご連絡差し上げる予定ですので、何卒ご理解を賜りますようお願い申し上げます。

このたびは、多大なるご心配をおかけしておりますことを、あらためてお詫び申し上げます。

— タイムズモビリティ、問い合わせへの回答メール

タイムズカーの個人情報管理の問題

タイムズカーの問題については、先日記事にまとめました。今回の回答で改めて問題点が明らかになりました。

報道では退会者の情報を法的根拠なく「なりすまし対策や問い合わせ対応」のために残していたとされています。2019年以降に会員であった私の運転免許証画像は、当然保持されていたはずです。

問い合わせフォームは、詳細な個人情報に加えて当時の会員番号まで入力させるものでした。

タイムズカーの問い合わせフォーム

このような情報提供にもかかわらず、回答は該当するタイムズカー会員様を特定することができませんです。漏えいの有無までは確認できないかもしれないと予想していましたが、まさか会員番号まで伝えても本人を特定できないとは思いませんでした。

会員情報はシステムから削除済みだったとしか考えられません。会員情報は削除しているのに、免許証画像は保持しているとはどういうことなのでしょうか？　本当に「なりすまし対策や問い合わせ対応」のためだったのかも疑いたくなります。

単に「消す」というプロセスがなかったか、機能していなかったかのどちらかでしょう。

こんな企業が大量の個人情報を扱っていたのかと思うとぞっとします。もっとも、私が昨年関わった公益財団法人はさらに酷く、問題を指摘しても誰ひとり動きませんでした。それを目の当たりにした身としては、同じような組織は決して珍しくないのだろうと思います。

相次ぐ情報漏えいは異常事態か

2026-10-08T08:09:00+09:00

Table of Contents

先日タイムズカー個人情報漏えいが公表されましたが、その後も数十の企業・組織が情報漏えいや不正アクセスを公表しています。異常なペースで起きている印象があったので、まとめてみました。

直近数日の情報漏えい

2026年10月1日から8日までに公表された国内の情報漏えい・不正アクセスの事案を一覧にしました。候補は、NHK・日本経済新聞・共同通信・時事通信などの主要報道とYahoo!ニュースの記事、ScanNetSecurityなどのセキュリティ専門メディア、事案をまとめた一覧サイトから集めました。そのうえで、各社の公式発表や報道と照らし合わせ、公表日と内容を確認しています。9月以前に公表された事案は除き、10月に続報が出たものだけ「続報」と記して残しました。日付は公表日で、件数は各社の発表どおり「可能性」「最大」を含みます。内容は2026年10月8日時点の公表情報にもとづきます。

日付	社名	概要
10/01	日本原子力研究開発機構	研究支援サイトから175人分・367ファイル（身分証画像・健康診断結果・マイナンバー含む）が不正ダウンロード
10/01	らしんばん	不正アクセスで顧客情報（口座情報・本人確認書類番号を含む）が漏えいした可能性。件数は未公表
10/01	ローソン	メールサーバーを不正利用され、不審メール約70万件（推計）を送信。個人情報の流出は未確認
10/01	ニッポンレンタカーサービス	アプリに9/26公表分とは別手法の不正アクセス。55人分の会員情報が閲覧された可能性（続報）
10/01	佐川急便	「お荷物問い合わせサービス」に不正アクセス。約100日分の荷物の送り主・届け先情報が流出した可能性（9/30初報の続報）
10/01	スターツ出版（オズモール）	海外からの大量アクセス。会員メールアドレスなど最大442,779名分が閲覧された可能性（9/27初報の続報）
10/01	チケットプラス	Webキャッシュの設定不備で他人の情報が表示。最大107名分（閲覧した側は最大322名）
10/02	第一ライフグループ・第一生命保険	人事システムへの不正アクセス。従業員・退職者約12万人分が流出したおそれ
10/02	ヤマト運輸	「クロネコ代金後払いサービス」に不正アクセス。氏名・住所・請求金額などが漏えいした可能性（9/29初報の続報）
10/02	ムーンスター	システムサーバーに不正アクセス。顧客の氏名・住所・注文情報が漏えいのおそれ（3/26初報の続報）
10/02	ジャパンタイムズ	グループ会社が管理するサーバーに不正アクセス。ランサムウェアグループEclipseが犯行を主張（同社は認めていない）
10/02	JOGMEC（エネルギー・金属鉱物資源機構）	不正アクセスでメールアドレス約8,500件（役職員約1,100件・外部約7,400件）が漏えいのおそれ
10/02	サミーネットワークス（777CON-PASS）	不正アクセスで利用者情報が漏えいした可能性
10/02	講談社BECK	旧講談社ビーシー時代の従業員アカウントに不正アクセス。不審メール50件を送信、情報漏えいの可能性
10/02	セーファーインターネット協会	利用していたさくらのレンタルサーバへの不正アクセスが波及。閲覧・取得は未確認
10/02	日本エネルギー経済研究所	フィッシング起点でMicrosoft 365の6アカウントに不正アクセス。パスポート13件の漏えいを確認、メールアドレス759件も漏えいの可能性（9/11初報の続報）
10/02	グリーンコープ生協ふくおか	車上荒らしで業務用PCを盗まれ、33,526件の個人情報が流出のおそれ
10/02	ニチイ学館	問い合わせデータのバックアップが外部から取得可能な状態だった。583名分（うち99名は健康情報）
10/03	アバハウスインターナショナル	会員・注文情報に不正アクセス。注文内容と一致する返金詐欺メールも確認
10/03	リクルート（スタディサプリ）	仕様の不備を突かれ、登録メールアドレス3,687件が特定された可能性
10/04	日本経済新聞社	社員のGoogle Workspaceに不正ログインし1,646人分が漏えいの疑い。別件でMicrosoft 365からもなりすましメール約9,000件を送信
10/04	日経BP	従業員メールアカウントがフィッシングで乗っ取られ、26件の個人情報が漏えいした可能性
10/05	物語コーポレーション（焼肉きんぐ）	公式アプリの会員情報10,788,963件が漏えい。ほぼ全会員分に相当
10/05	GMOリサーチ&AI（infoQ）	サイトの脆弱性を突かれ最大948,498件を持ち出された。ポイントもAmazonギフトコードへ不正交換
10/05	大和証券	委託先サーバーへの不正アクセス。約11万人分（約22万件）の氏名・口座番号などが漏えいした可能性
10/05	ホワイトエッセンス	予約サイトの脆弱性から侵入され、約105万アカウントの個人情報が流出（8月公表分の続報）
10/05	大起水産	公式アプリに不正アクセス。174,933人分が漏えいした可能性
10/05	大阪公立大学	ランサムウェアで約500台のサーバーが停止。少なくとも13万人分の個人情報が流出のおそれ
10/05	i-plug（OfferBox）	設定不備で学生の氏名・メールアドレスが利用企業から閲覧可能に。最大314,009人
10/05	くふうカンパニー	「くふうまちトークβ版」に不正アクセス。サービスを停止
10/06	ミスターマックス	アプリ・オンラインストア会員最大1,735,154人分（会員ID・氏名・メール・電話番号）が流出した可能性
10/06	シチズン時計	委託先サーバーへの不正アクセス。問い合わせフォームの顧客情報約10万人分が漏えいした可能性
10/06	スカラコミュニケーションズ	FAQシステム「i-ask」のサーバーに不正アクセス。最大5社分、延べ最大713,126件が対象の可能性（大和証券・シチズン・損保ジャパン・東武鉄道の委託先）
10/06	旭化成セラピューティクス	医療従事者向けサイトへの攻撃。最大約55.8万人分（うち医療従事者約51.4万人）が漏えいした可能性
10/06	楽天モバイル（楽天ドライブ）	管理者アカウントの認証情報を不正取得され、約1.5万アカウントの保存データが閲覧された
10/06	ニモカ	利用履歴照会サービスへの攻撃。カード番号など521件が漏えい
10/06	気象キャスターネットワーク	Webサイトに不正アクセス・改ざん。最大15,959件が漏えいした可能性
10/06	アクティブ	通販サイトにSQLインジェクション攻撃。最大54,916件が漏えいのおそれ
10/06	エバーグリーン・マーケティング	従業員メールアカウントの不正利用で計1,000件（取引先237件・法人顧客763件）が閲覧された可能性（7/31初報の続報）
10/06	CINRA（CINRA JOB）	脆弱性悪用で認証情報を取得され、21,508人分が漏えい（8/27初報の続報・最終報告）
10/06	山口大学	教職員メールアカウントがフィッシングで乗っ取られ、連絡先967件が漏えい
10/06	関西国際大学	eポートフォリオから過去の在籍学生の情報が外部に流出（9/30初報の続報）
10/06	ナカバヤシ	採用管理サービス「ApplyNow」に不正アクセス。応募者情報1,826件が漏えい
10/07	戸田建設	支払管理システムなどに不正アクセス。従業員4,778人分、取引データ最大6,000件、取引先メール最大7,200件が漏えい
10/07	損害保険ジャパン	委託先サーバーへの不正アクセス。顧客情報延べ約6万件が漏えいした可能性
10/07	エイチ・アイ・エス	タイ現地法人への不正アクセス。最大627人分のパスポート情報などが流出した可能性。検知は2025年12月
10/07	IDCフロンティア	IDCFクラウドに第三者の不正アクセス（報道ではランサムウェアとみられる）。東日本第1リージョンで障害。漏えいは未発表
10/07	東武鉄道	委託先スカラコミュニケーションズへの不正アクセスで、問い合わせ情報が漏えいした可能性
10/07	ポイントインカム	不正アクセスで195件の個人情報が閲覧された可能性
10/07	富山県立大学	学生のMicrosoft 365アカウントが乗っ取られ迷惑メール1,092件を送信
10/08	アドバンテスト	2月のランサムウェア攻撃で持ち出されたデータに個人情報が含まれていたと確認。米国の対象者に通知、人数は非公表（続報）

上の表の中で、特に問題が大きいと感じたのは次のとおりです。

エイチ・アイ・エス：パスポート情報と公表の遅さ
- 最大627人分のパスポート情報とアレルギー情報に流出の可能性がある。パスポートは本人確認書類そのもので、なりすましや偽造に使われると被害を受けた本人が自力で防ぐ手段はほとんどない。アレルギー情報は、要配慮個人情報に当たる可能性がある。さらに問題なのは、不正アクセスの検知から公表まで約10カ月かかったことである。そのあいだ対象者は、パスポートの再発行などの対策を取れなかった。
大和証券・シチズン時計・損害保険ジャパン・東武鉄道：委託先経由の漏えい
- この4社の漏えいは、問い合わせ管理を委託していたスカラコミュニケーションズのFAQシステム「i-ask」が10月2日夜から3日朝にかけて不正アクセスを受けたことが原因である。大和証券・シチズン時計・損害保険ジャパンの3社は、自社システムへの侵入は確認されていないと説明している。スカラの公表では、同じサーバーを使っていた最大5社、延べ最大713,126件が対象になる可能性がある。自社のセキュリティをいくら固めても、顧客情報を預けた委託先が破られれば漏えいは防げない。問い合わせ窓口のような周辺業務ほど外部サービスに任せがちで、そこに口座番号や問い合わせ内容といった機微な情報がたまっていく。委託先の選定と監督まで含めて自社のセキュリティだと考える必要がある。
その他の深刻な事案
- 物語コーポレーション（焼肉きんぐ）：漏えいは10,788,963件で、公式アプリ会員のほぼ全員にあたる。10月公表分で最大の規模
- 日本原子力研究開発機構：身分証画像、健康診断結果、マイナンバーが含まれる。件数は175人分だが、漏れた情報の性質が重い
- 第一ライフグループ・第一生命保険：人事システムが狙われ、従業員と退職者約12万人分が対象。うち約7万人は退職者で、連絡先が変わっている人への通知が課題になる
- 楽天モバイル（楽天ドライブ）：管理者アカウントを乗っ取られ、15,382アカウントの保存データ（写真・文書など）が1月から9月までの約8カ月間閲覧・取得されうる状態だった。氏名やメールアドレスではなく、ファイルの中身そのものが対象になっている
- GMOリサーチ&AI（infoQ）：最大948,498件の持ち出しに加え、611件・約287万円分のポイントがAmazonギフトコードに不正交換された。情報漏えいが実際の金銭被害につながった例
- 大阪公立大学：ランサムウェアで約500台のサーバーが停止し、バックアップの多くも暗号化された。10月8日まで全授業を休講とし、少なくとも13万人分の個人情報について流出のおそれがある

多発の実態と背景

漏えいの集中は報道による錯覚、だが件数は増え規模も拡大している

連日の漏えい報道は、タイムズカーの件以降にメディアの関心が集中したことで増幅されています。上の表の51件のうち11件は9月以前の事案の続報で、公表が重なったにすぎないものも含まれます。

件数そのものは増えています。共同通信が報じたトレンドマイクロの集計では、国内で公表された不正アクセス被害は2024年が644件、2025年が593件でした。2026年は9月末時点で約600件と前年1年分に並び、年換算では約800件、前年比3割強の増加となるペースです。2022年4月に漏えいの報告が義務化されて以降、事案が表に出やすくなっている面もあります。ただし、桁が変わるような急増ではありません。

異常なのは規模です。東京商工リサーチの上場企業を対象とした集計では、100万件以上の漏えいが2025年の6件に対し2026年は10月5日時点で10件、1,000万件以上は2025年までの14年間で3件だったのに対し今年だけで3件に達しました。同社はこれを「異常事態」と表現しています。

多発の主な原因

上の表から読み取れる多発の原因は、大きく3つです。いずれも新しい攻撃手法ではなく、以前から知られている弱点が突かれています。

第一に、委託先を経由した被害の連鎖です。上の表では、問い合わせ管理システムを提供する委託先1社への不正アクセスが、4社の漏えい公表につながりました。侵入は1回でも、そのシステムを使っていた企業がそれぞれ公表するため、表の上では複数の事案として現れます。業務の外部委託が広がるほど、1社の弱点が多くの企業に波及しやすくなります。

第二に、Microsoft 365やGoogle Workspaceなど、クラウドの業務アカウントの乗っ取りです。報道機関、研究機関、大学など、業種を問わず多くの組織がフィッシングメールで認証情報を盗まれていました。乗っ取られたアカウントからは取引先や関係者に向けてなりすましメールが送られ、次の組織が狙われます。被害が組織から組織へ広がるため、件数が増えやすくなります。フィッシング自体は古くからある手口で、パスキーのようなフィッシングに強い多要素認証を導入すれば被害の多くは防げます。それでも被害が続いているのは、基本的な対策が徹底されていない組織がまだ多いことを示しています。

第三に、公開しているWebサイトやアプリの脆弱性です。ソフトウェアの既知の脆弱性や、SQLインジェクションのような古典的な攻撃で侵入された事案が並んでいます。脆弱性を探す作業はツールで自動化でき、攻撃者は多数のサイトを一度に調べて、弱いところから順に侵入できます。更新の遅れや設計上の不備を放置しているサイトは、いずれ見つかると考えるべきです。

3つに共通するのは、攻撃者の側の手間が小さく、守る側の基本的な対策の不足がそのまま被害につながっている点です。多発の背景にあるのは攻撃の高度化ではなく、防御の基本ができていない組織の多さだと考えます。

大型化の主な原因

多発の原因が「侵入の入口が弱いこと」だとすれば、大型化の原因は「侵入された先に、大量のデータがまとめて、長く置かれていること」だと考えます。入口の弱さは以前からあるものです。変わったのは、1回の侵入で手に入るデータの量です。

第一に、データが1か所へ集まるようになりました。かつて顧客情報は店舗や部門ごとに分かれ、紙や個別のシステムに散らばっていました。いまは公式アプリやポイントサービスを通じて会員を一元管理するのが当たり前になり、1社が数百万から1,000万人規模の会員データベースを持っています。マーケティングには便利な仕組みですが、攻撃者から見れば、一度入り込めば全件を持ち出せる宝庫です。上の表にも、アプリ会員のほぼ全員分が一度に漏えいした事案があります。

第二に、複数の企業が同じ基盤を共有するようになりました。問い合わせ管理やメールのような業務は外部のサービスに任せるのが一般的で、何社分ものデータが1つの基盤に載っています。攻撃者にとっては、企業を1社ずつ攻めるより基盤を1回破るほうが効率的で、被害も利用企業の分だけ合算されて大きくなります。

第三に、使い終わったデータが消されずに残っています。退会した会員や、10年以上前の問い合わせ者の情報まで漏えいの対象になった事案が複数あります。ストレージが安くなり、データを持ち続けるコストはほとんどかかりません。そのため「いつか使うかもしれない」データが消されないまま積み上がります。こうなると漏えいの規模は、いまの顧客数ではなく、過去に一度でもその企業と関わった人の数で決まります。

第四に、侵入に長く気付かない事案が目立ちます。表の中には、半年以上にわたって保存データにアクセスされていた事案や、入口の予約サイトから基幹システムまで侵入を広げられた事案があります。攻撃者は気付かれないあいだに内部を調べ、より多くのデータがある場所へ移っていきます。持ち出される量は、侵入されている期間に比例して増えます。

この4つは、いずれも企業がデータを集めて活用しようとしてきた流れの裏返しです。どれも以前からある構造なので、今年になって大型の漏えいが急に増えた理由までは説明できません。それでも、1回の侵入で失うものが大きくなり続けていることが、大型化の土台にあると考えます。

AIの悪用は現時点では可能性にとどまる

NHKや産経新聞は、7月以降に被害が増えていることからAIが攻撃に悪用されている可能性を伝えています。ただし、トレンドマイクロの担当者も直近の事案との関係は「不明」としており、現時点で明確な証拠はありません。

とはいえ、脆弱性の探索やフィッシングメールの作成はAIが得意とする作業です。今後はAIを悪用した攻撃が増えていくと考えます。

見立て：問題は個別の脆弱性より、防御設計の遅れ

これらの分析から個人的に感じたことです。

脆弱性をゼロにできない以上、侵入はある程度起きるものと考えるべきです。問題は、侵入されたあとに大量のデータが持ち出され、しかも長く気付かれないことです。AWSなどのモダンなプラットフォームでベストプラクティスに沿って構築していれば、侵入から大量漏えいまでの道のりは険しくなります。権限は最小限に絞られます。機微な項目は個別に暗号化され、鍵の管理とデータへのアクセスも別々の権限で扱われます。大量の読み出しや復号は記録され、監視を設計しておけば異常として検知できます。侵入されても、持ち出せる範囲を限り、気付くまでの時間を短くできます。

上の表からは、そうした設計になっていない様子がうかがえます。例えば、プレースホルダを徹底すれば原理的に防げる、古典的なSQLインジェクションで侵入された事案があります。10年以上前の問い合わせや退会者の情報が残っていた事案もあります。数カ月にわたって侵入に気付かなかった事案もあります。持ち出しが確認された事案では、攻撃者は読める形でデータを手にしています。暗号化されていなかったのか、正規の権限で復号できる経路を奪われたのかは公表文からは分かりませんが、いずれにしても「持ち出されても使えない」設計にはなっていなかったことになります。

漏えいした企業では、個別の脆弱性があったかどうか以上に、侵入を前提とした防御設計への移行、つまりモダナイゼーションが遅れているのではないかと考えます。ただし、AWSなどのクラウドに移るだけでは足りません。クラウドでも、権限の与えすぎや設定ミスから大規模な漏えいは起きています。問題はプラットフォームだけでなく、アーキテクチャー全体がセキュリティを織り込んだベストプラクティスに従っているかどうかです。

デジタル大臣の呼びかけは問題を矮小化している

古川俊治デジタル大臣は10月6日の会見で、相次ぐ漏えいを受けて「サイバー攻撃は、企業や組織だけの問題ではございません」と述べました。そのうえで「自分の情報は自分で守る」という意識を国民に求め、パスワードの使い回しをやめる、多要素認証を使う、不審なメールに注意するという3つの対策を呼びかけています。

自ら「唯一の理系大臣」と称し、デジタル大臣とサイバー安全保障担当を兼ねる人物の発言としては、問題の本質をつかんでいないと言わざるを得ません。

まず、呼びかけの中身が今回の漏えいと合っていません。漏れたのは企業のデータベースにある氏名や連絡先で、個人がパスワードをどう管理しようと防げるものではありません。呼びかけ自体が誤っているわけではありません。しかし、企業のセキュリティの水準が問われている事象に対して、サイバー安全保障を担う大臣が個人の心がけを説くのは、その役割に期待される認識とずれています。

次に、企業に対する具体的な行動が示されませんでした。企業に向けた言葉は「基本的な安全対策の徹底」だけで、何をどう徹底するのかは示されませんでした。国としての対応も、各社の調査結果を見て判断するという姿勢にとどまっています。前の節で述べたように、今回の現象の背景には個別の脆弱性よりもアーキテクチャー刷新の遅れがあると考えます。サイバー安全保障を担う大臣には、関係機関と連携して企業に防御設計の点検を求めるといった行動を期待していました。それが個人のパスワード管理と並べた「注意しましょう」で終わっているのを見ると、大臣の中でこの状況が矮小化されていることがうかがえます。

しかも、デジタル庁自身も同じ問題を抱えています。9月11日、デジタル庁は自ら運用する政府共通基盤「GSS」への不正アクセスにより、約24.6万件の個人情報に漏えいの可能性があると発表しました。侵入経路はVPN機器の脆弱性で、6月下旬に検知してから公表まで2カ月半かかっています。古川大臣の就任前の事案ですが、国民に自衛を求める前に、まず足元の防御設計を見直すべきではないでしょうか。

References

確認日はいずれも2026年10月8日。

東京商工リサーチ. 「上場企業「個人情報漏えい」、過去最悪ペース～ 100万件以上、2026年はすでに10件の異常事態～」
個人情報保護委員会. 「令和4年度上半期における個人情報保護委員会の活動実績について（概要）」
デジタル庁. 「古川大臣記者会見（令和8年10月6日）」
デジタル庁. 「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」

タイムズカー個人情報漏えいに個人でできる対策

2026-10-02T13:46:13+09:00

Table of Contents

タイムズカーの会員情報約660万件が不正アクセスで流出し、免許証など本人確認書類の画像も約160万件含まれています。退会済みでも対象になり得るため、会社の続報を待たずに個人でできる対策を整理しました。信用情報機関(CIC・JICC)への本人申告の手順と注意点を中心に、開示請求についても触れます。

今回何がまずいのか？

漏えいしたのは約660万アカウントで、退会者や入会手続きを完了しなかった人も含まれます。氏名・住所・生年月日・電話番号などに加えて、約160万アカウントでは運転免許証などの本人確認書類の画像も漏れています。

銀行口座やクレジットカード、ローンでは、犯罪収益移転防止法で本人確認が義務付けられています。そのため、流出した画像を送るだけで手続きが通ることはありません。ただし、流出情報をもとにした偽造免許証で口座を開設される恐れはあります。画像を使うネットでの本人確認が、2027年3月末までは認められているためです。

それ以外のサービスの本人確認は事業者任せのため、流出画像によるなりすましの恐れがあります。また、本物の個人情報を使ったフィッシングにも悪用され得ます。

タイムズは、画像が漏れた会員には9月29日から、退会者には10月1日から、順次メールで個別に通知しています。しかし、全員への通知がいつ終わるかは示されていません。

通知が来ていなくても、自分が対象外かどうかは確かめようがありません。そのため現時点では、退会者を含め、タイムズカーを利用したことのある人全員がリスクを抱えていると考えるべきです。

個人でできる対応策

タイムズはFAQで「今すぐ行う必要がある手続きや対策はあるか？」という問いを立てていますが、回答では不審なメールやSMS、電話、郵便物への注意を呼びかけているだけです。名義の悪用に備える信用情報機関への本人申告や、信用情報の開示請求には触れていません。免許証画像まで流出させた会社の案内としては不十分です。

上記のように悪用されるリスクがあるため、なるべく被害に遭わないよう、次の対策を取りましょう。

ご留意ください

以下の対策は筆者個人の見解で、法律や信用情報の専門家としての助言ではありません。手続きの詳細は各機関の案内で確認してください。

信用情報機関に本人申告する

本人申告は、本人確認書類の紛失・盗難・漏えいで名義を悪用される恐れがあることを、自分の信用情報に登録しておく制度です。クレジット会社や貸金業者は、カードやローンの審査で信用情報を確認します。そのとき申告情報も目に入るため、なりすましの申込みに対して審査を慎重にしてもらうことが期待できます。

主な申告先は、指定信用情報機関のCIC(株式会社シー・アイ・シー)とJICC(株式会社日本信用情報機構)です。両機関は申告情報を相互に交流していますが、加盟している会社が異なるため、それぞれに申告することが推奨されています。

CICでは、申告するコメントとして「盗まれました」を選びます。CICは、本人確認書類のデータが第三者に渡った場合はこれを選ぶよう案内しています。ネットで申告する場合の手数料は1,000円です。ただし事前に、CICに登録済みの電話番号(クレジット契約時に届けた番号)から電話をかけ、受付番号を取得する必要があります。郵送の場合は、紛失・盗難情報登録用紙に本人確認書類のコピーと1,000円分の定額小為替を添えて送ります。

JICCでは「名義の悪用防止」を選びます。JICCは、免許証の現物が手元にあって画像だけが流出した場合はこのコメントを選ぶよう案内しています。ネットでの申告はスマホアプリから行い、手数料は700円です。郵送の場合は、Webフォームで作成した申込書と本人確認書類のコピー2点を、コンビニで購入する本人申告利用券(1,111円)と一緒に送ります。

私の場合、CICは電話が混み合っていて受付番号を取得できませんでした(CICも9月30日に電話がつながりにくいと告知しています)。JICCはアプリのインストールが必要でした。そのため、どちらも郵送で手続きしました。

銀行のローンも気になる人は、全国銀行協会が運営する全国銀行個人信用情報センターにも申告できます。ネットで申告する場合はマイナンバーカードが必要で、手数料は500円です。

ただし、本人申告には限界やデメリットもあります。申告情報はあくまで審査の参考情報で、なりすましの申込みを必ず止められるわけではありません。またクレジットやローンの審査で使われる情報なので、偽造免許証による預金口座の開設は防げません。

デメリットは、自分自身でローンやカードを申し込むときにも審査が慎重になり、確認に時間を要する可能性があることです。申告情報は登録から5年間有効ですが、本人がいつでも削除できます。近々ローンを組む予定がある人は、申込先に事情を伝えておくとよいでしょう。

信用情報を開示請求する

漏えいから1週間が経過しているため、すでに悪用されていないかが気になる人は、開示請求で確認できます。私自身は開示請求をしていません。

開示請求をすると、信用情報機関に登録されている自分の情報を確認できます。対象は、クレジットやローンの契約内容と支払状況、それに新規の申込みを受けた会社が信用情報を照会した記録(申込情報)です。CICの場合、申込情報は照会日から6か月間保有されます。そのため、身に覚えのない会社からの照会がないかを見れば、自分の名義で勝手に申込みがされていないかを確認できます。

ネットで開示する場合の手数料は、500円(CIC)、700円(JICC、スマホアプリ)、800円(全国銀行個人信用情報センター)です。CICのネット開示も、本人申告と同じく登録済みの電話番号から受付番号を取得する必要があります。郵送でも開示を請求できます。

対応費用と補償、集団訴訟について

漏えいした情報による被害は今のところ確認されておらず、実際の被害額はわかりません。一方で、対策にかかった費用はすでに発生しています。私が郵送で本人申告をするのにかかった費用は次のとおりです。

費目	金額(円)
JICC 本人申告利用券	1,111
CIC 定額小為替(発行手数料200円を含む)	1,200
郵送料(速達・2通)	1,240
計	3,551

本人申告の手数料は損害として請求できる可能性がある、と指摘する弁護士もいます。ただし、タイムズはまだ補償の方針を示しておらず、こうした対策費が補償の対象になるかはわかりません。しかも、自分が漏えいの対象者かどうかわからないまま手続きせざるを得ない状況です。結果的に対象外だった場合に費用を請求できるのかは、さらに不透明です。

集団訴訟については、弁護士が参加希望者を募っている段階で、まだ提訴はされていません。過去のベネッセの漏えい事件で認められた賠償額は1人あたり数千円程度で、弁護士費用を差し引くと費用倒れになる恐れがあります。参加するかどうかは、費用の条件が示されてから判断しても遅くありません。

エンジニアから見た今回の漏えいについて

個人情報を扱うシステムを設計・開発してきたエンジニアの立場から、今回の漏えいについて考えてみます。

ご留意ください

侵入経路の詳細は現時点でタイムズから発表されていません。以下の侵入経路や暗号化に関する記述は、エンジニアとしての経験にもとづく個人的な推量にすぎない点をご了承ください。

漏えいした情報は、個人情報保護法でいう「要配慮個人情報」(病歴や犯罪歴など)にはあたりません。ただし、運転免許証の番号は、それだけで特定の個人を識別できる「個人識別符号」として政令で定められています。顔写真付きの免許証画像は、なりすましに直結するという点で、特に慎重に扱うべき情報です。

システム設計では、こうした情報はできるだけ持たない、不要になったら消す、持つなら暗号化するのが基本です。個人情報保護法も、利用する必要がなくなった個人データは遅滞なく消去するよう、事業者に求めています(努力義務)。

タイムズは、退会者の情報を7年間保管していた理由として、氏名・住所・生年月日は税法等、免許情報と画像はなりすまし対策や問い合わせ対応を挙げています。しかし、カーシェア(法律上はレンタカー)の事業者に義務付けられているのは、貸渡簿に運転免許証の番号などを記録して、少なくとも2年間保存することです。免許証の画像そのものを退会後7年間も持ち続ける必要が本当にあったのかは疑問です。

暗号化についても説明が見当たりません。タイムズはパスワードについて「復元できない形式で保管していた」と説明していますが、免許証画像などそれ以外の情報には触れていません。そもそもパスワードを復元できないハッシュ値で保存するのは業界の常識で、一般的な認証基盤を使えば標準でそうなります。タイムズ独自の対策とは言えません。

個人情報保護委員会の規則では、高度な暗号化などで保護された個人データは、漏えいしても委員会への報告義務の対象外です。タイムズが報告と本人への通知を進めていることからすると、免許証画像などはこの意味で保護されていなかった可能性があります。

侵入経路としては、データベースや画像ストレージから直接抜き取られた場合と、アプリケーション経由で抜き取られた場合が考えられます。直接抜き取られた場合、データが暗号化されていれば中身は読めないので、タイムズはその旨を発表するはずです。一方、アプリケーション経由であれば、アプリケーションは正規の処理としてデータを復号するため、暗号化されていても中身ごと取り出されてしまいます。ただ、アプリケーションを通じて約660万件の会員情報や約160万件の画像を抜き出せば、異常なトランザクションとして検知されるはずなので、アプリケーション経由の可能性はかなり低いと考えます。そうなると、免許証画像などを暗号化せず、平文のまま保管していた可能性すらあるのではないかと思えてしまいます。

全体として、これだけの個人情報を管理するシステムとしては、データの持ち方に不可解な点が多いと感じます。

まとめ

今回の漏えいでは、退会者を含め、タイムズカーを利用したことのある人全員が、なりすましのリスクを抱えています。

タイムズからの通知には期限がなく、自分が対象かどうかすぐには確かめられません。通知を待たずに、CICとJICCへの本人申告で備えておくのが現実的です。費用は自己負担で、補償の対象になるかもまだわかりません。集団訴訟も、費用の条件を見てから判断すれば十分です。

タイムズには、侵入経路や免許証画像の保管方法について、早期の説明を求めたいところです。

References

確認日はいずれも2026年10月2日。

タイムズモビリティ. 「「タイムズカーWebサイト」への不正アクセスによる個人情報漏えいの可能性について」(第2報・第3報・よくあるご質問へのリンクあり)
e-Gov法令検索. 「犯罪による収益の移転防止に関する法律・同施行令・同施行規則」(2027年4月1日施行の改正を含む)
CIC. 「本人申告とは」
JICC. 「不正利用防止の届け出」
全国銀行個人信用情報センター. 「本人申告の手続き」
牧野法律事務所. 「タイムズカー情報漏洩集団訴訟」
e-Gov法令検索. 「個人情報の保護に関する法律・同施行令・同施行規則」
国土交通省神戸運輸監理部. 「レンタカー事業における法令遵守と諸手続きについて」
OWASP. "Password Storage Cheat Sheet"

メッセージングアプリの匿名性考察

2026-07-01T10:00:00+09:00

Table of Contents

Threema GmbH（以下、Threema社）の公式ブログに「システムレベルの匿名性についての記事」という記事が投稿されました。

メッセージングアプリの匿名性について論じています。以前、市川の強盗傷害事件をきっかけに暗号化やメタデータで機能比較した記事を書きましたが、匿名性という観点はなかったのでこの記事を参考に解説したいと思います。

メッセージングアプリの匿名性について

Threema社の技術記事では、匿名性を二種類に分けています。

水平的匿名性: 会話の相手に対する匿名性です。ユーザー名だけで連絡先を交換できれば、相手は電話番号や本名を知りません。対等な利用者どうしの間で成り立ちます。
垂直的匿名性: サービス運営者に対する匿名性です。登録時に電話番号やメールアドレスを渡していなければ、運営は身元を特定する手がかりを持ちません。利用者とサービスという上下の関係で成り立ちます。

Threema社は、ユーザー名機能で水平的匿名性は広まったものの、プライバシー保護で本当に重要なのは垂直的匿名性であり、これはセキュリティにおけるエンドツーエンド暗号化に相当する基盤だと主張します。あくまで同社の枠組みですが、この二軸はアプリを見比べる土台として使えます。

垂直的匿名性の重要性について

なぜ運営に対する匿名性がそれほど問題になるのでしょうか。

メッセージングアプリでは、登録時に電話番号やメールアドレスを要求するものがあります。

ユーザー名で連絡先を交換できるサービスでも、相手にこうした個人情報を見せずに済むだけで、登録の段階では運営に渡しています。電話番号やメールアドレスは本人確認や他サービスの登録にも使われる、生活に密着した識別子です。運営がこれを保持していれば、別々の文脈で集めた情報を同一人物に結びつける手がかりとして使えてしまいます。

この紐付けは、広告で収益を上げるサービスでは特に意味を持ちます。利用者の行動を束ねてプロフィールを作るほど広告の精度が上がるので、複数の情報源を統合する動機がもともと働きます。電話番号やメールアドレスのような確実な識別子があれば、その統合は格段にやりやすくなります。メッセージの中身が暗号化されていても、誰がいつ誰と連絡したかというメタデータや、それを個人に結びつける識別子までは覆い隠せません。

メッセージングアプリの匿名性の比較

ここまでの軸で、私が知る範囲の主要なアプリを並べてみます。

暗号化の強さと、運営に対する匿名性は別物だという点に注目してください。暗号化の対応範囲やメタデータ収集、法執行機関への開示といった機能面の詳しい比較は前回の記事にまとめたので、ここでは匿名性の軸に絞ります。

アプリ	登録時に必要な個人情報	運営に対する匿名性
LINE	電話番号	なし
WhatsApp	電話番号	なし
iMessage	電話番号または Apple Account	なし
Signal	電話番号	なし
Element / Matrix	なし（メールは任意）	サーバー次第
Threema	なし	運営は満たすと主張
Session	なし	高い
SimpleX	なし	最も高い部類

国内利用者の多いLINEは、もう少し細かく見ておきます。LINEのメッセージはLetter Sealingと呼ぶ技術で暗号化されていますが、50人を超えるグループトーク、グループ音声・ビデオ通話、LINEミーティング、アルバム、ノートは対象外で、通信路のTLS暗号化にとどまります。この範囲は運営が技術的に中身へアクセスし得ます。そして匿名性の面では、登録に電話番号が必須なので運営に対する匿名性は持ちません。自治体などが市民の申請にLINEを使うケースが増えていますし、たまに企業でも業務で使用しているケースを見かけます。セキュリティ意識の低さには驚きます。

WhatsAppとiMessageも、垂直的匿名性はありません。メッセージの暗号化に対応していますが、登録にはWhatsAppが電話番号、iMessageが電話番号かApple Accountを必要とします。この時点で運営に対する匿名性は持ちません。特にWhatsAppを運営するMeta社は広告を収入源としているので、個人情報に関連したメタデータを収集してグループ内の他社と共有している可能性があります。中身は守られても、誰といつ繋がったかまでは隠せません。

暗号化に強いというイメージのSignalも垂直的匿名性はありません。ユーザー名機能が2024年に加わり、電話番号を教えないまま連絡できるようになりました(水平的匿名性)が、アカウントの作成には今も電話番号が必須です。 Signalを運営するのはSignal Foundationという非営利団体ですが、拠点はカリフォルニア州です。つまり米国の管轄下なので、米国の捜査機関の要求があれば開示義務があります。

ElementはMatrixというオープンなプロトコルの上に作られています。登録に必要なのは、選んだサーバー上のユーザー名とパスワードだけで、電話番号は要りません。メールアドレスはパスワード再設定用に任意で登録でき、サーバーによっては不正利用対策で求められることもあります。利用者はmatrix.orgのような公開サーバーを選んで登録するのが一般的で、自前でサーバーを立てることもできます。運営に対する匿名性は、結局どのサーバーを信頼するかに依存します。

結局、垂直的匿名性を保持しているのは、Threema、Session、SimpleXのみです。

垂直的匿名性の代償

垂直的匿名性の仕組みと、その代わりに払う利便性のコストを見ておきます。

Threemaは電話番号やメールアドレスを必要とせず、アカウントはランダムに割り当てられたThreema IDだけで機能します。ユーザーはThreema IDを交換しメッセージの送受信を行ないます。伝えるのはThreema IDのみなので、運営や相手に身元を明かさずに通信できます。 Threemaを使用していることすら秘匿する為にGoogle Playなどに依存せずThreemaを入手・購入できる手段も提供しています。 Threema IDはThreema社により管理されており、「IDが誰か」はThreema社に把握されませんが「いつ・どのIDと通信したか」は論理的にはThreema社で把握可能です。ただし、Threema社は広告やトラッキングを行なわないというポリシーを持ち、収益源を買い切り課金に置いています。

SimpleXは、利用者を識別する固定IDを一切持たない設計です。電話番号やユーザー名はもちろん、ランダムなIDすら使いません。仕組みは一方向のメッセージキューで、接続ごとに送信用と受信用の別々のキューを持ち、通常はそれぞれ別のサーバーを経由します。サーバーから見えるのは不透明なキューへの孤立した配送だけで、送信者と受信者を結びつけられません。サーバー同士も通信せず、配送が済んだメッセージは保存しません。

SessionはもともとSignalのフォークとして始まりました。電話番号やメールなどの個人データも不要で、ランダムなSession IDという66文字程度の公開鍵をアカウントのIDとして使います。メッセージは多数の有志ノードからなるオニオン型のネットワークを経由し、どのノードも送信者と受信者の両方を知ることはありません。運営は2024年10月に、暗号化技術への規制圧力を背景としてオーストラリアからスイスへ拠点を移し、現在はスイスのSession Technology Foundationが運営しています。コードはQuarkslabによる独立監査を受けています。SimpleXとの違いは、Sessionが永続的なアカウントのIDを持つ点です。

これらの高い匿名性には、現実的な代償が伴います。

いずれも、相手に直接リンクやQRコード、IDを渡さなければ会話を始められない
従って、電話番号やユーザー名で気軽に相手を見つけることはできず、なんらかの方法で相手と直接これらの情報を交換する必要がある

一番問題になるのは、相手も同じアプリを入れている必要があるところでしょう。いずれもマイナーなアプリなので、匿名性のために連絡相手の数と手軽さを大きく差し出すことになります。この利便性の低さは、日常使いを考えるうえで無視できないトレードオフです。

メッセージングアプリについて私の選択

ここまで匿名性の強さで並べてきましたが、強ければ強いほどよい、という話ではありません。匿名性がどれだけ効くかは、相手があなたの身元を知っているかどうかで変わります。

私は以下のように考えています。

関係	説明
家族	当然対面しており、インストールするアプリも管理可能。機微なメッセージ交換もあり
友人	対面しているが、アプリの管理は困難。機微なメッセージ交換は限定的
他人	必ずしも対面していない。アプリの管理は不能。機微なメッセージはなし

このように考えると、家族とは水平的匿名性は不要で垂直的匿名性が必要です。前回の記事でも軽く触れましたが、私自身は家族との連絡用にThreemaを選んでいます。 SimpleXやSessionでもよいのですが、かなり以前からThreemaを使用しており、特に問題もないために使用を続けています。

友人も同様です。知り合いなので水平的匿名性は不要ですが、垂直的匿名性は必要です。しかし、現実的には垂直的匿名性を実現するために、先に記述した「代償」のため友人に対応するアプリを導入してもらうことは困難です。そのため諦めて必要な場合は、友人にはメールかSMSでのコンタクトを依頼しています。暗号化、匿名性は放棄すると言うことです。 LINEなどを使っていると「じゃ、LINEで」と言われるので、私はLINEなどのアプリは使わずインストールさえしていません。

ネットで知り合ったような他人については、どちらの匿名性も重要だと思います。しかし、私は、匿名のままネットで知り合った相手とメッセージングアプリを使って通信するようなニーズはないので無視します。

まとめ

LINE・WhatsApp・iMessage・Signalなど主要なメッセージングアプリは、暗号化や水平的匿名性は実装されていますが、垂直的匿名性は担保されていません。LINEなど「なりすまし防止、復旧、法令遵守」などを理由に電話番号への紐付けを強化しています。自治体などでLINEを使用するケースが多いようですが、あれは個人特定を行政として放棄しているとしか思えません。

私にとって必要なのは垂直的匿名性です。メッセージの中身が暗号化されていても、運営に身元や「誰といつ通信したか」を握られては、プライバシーを守ったことになりません。一方、相手に対しても名乗らない水平的匿名性は、私個人にはほとんど必要ありません。

両方の匿名性を保てるのは、Threema・Session・SimpleXの3つです。

両方の匿名性が必要なのは、相手や運営に身元を伏せたまま連絡したい場面だけです。こうしたニーズは犯罪目的での使用を想起するかもしれませんが、内部告発や情報提供など正当な目的のためにも必要です。米国では報道機関が情報提供の窓口としてメッセージングアプリの宛先などを公開しています。日本ではこうした使い方はほとんど根づいておらず、全く遅れています。

大切なのは、自分がどちらの匿名性を必要とするのかを見極めることです。垂直的匿名性はほとんどの人に効きますが、水平的匿名性まで求めるかは人によって大きく変わります。私自身は、身元を隠す必要のない家族との連絡に、垂直的匿名性を保ちつつ扱いやすいThreemaを使っています。

References

Threema. "Anonymity at the System Level: The Ultimate Privacy Protection"
Threema. "Statement on ETH Findings"
ETH Zurich Applied Cryptography Group. "Three Lessons from Threema"
Signal. "Keep your phone number private with Signal usernames"
Signal Foundation. "Signal Foundation"
SimpleX Chat. "How SimpleX works"
Session. "Introducing the Session Technology Foundation"
Session. "Session code audit by Quarkslab"
WhatsApp Help Center. "About end-to-end encryption"
Apple Support. "iMessage security overview"
Element. "Creating a Matrix Account"
LINE Help Center. "Letter Sealing"
LINEヤフー.「LINE暗号化状況レポート（2025年）」

三菱UFJ銀行のPPAP廃止は、半歩前進で半歩後退

2026-06-08T00:00:00+00:00

三菱UFJ銀行が2026年6月8日付で「当行からの添付ファイル送信方法の変更に関するご案内」を公表しました。日本を代表するメガバンクがまだPPAPやっていたと衝撃を受けました。内容を読んで考えさせられたので記録しておきます。

三菱UFJ銀行のアナウンス

要点はシンプルです。

同行は、お客さま側のセキュリティを確保するため、パスワード付き添付ファイルのメール送信を原則取り止めると発表しました。 2026年7月18日より順次、添付ファイルを送る際は専用のダウンロードサイトを利用する方式へ変更されます。

理由として挙げられているのは次の2点です。これまでの「メールでパスワード付きZIPファイルを送り、パスワードを別送する方法」、いわゆる PPAP は、ファイルが暗号化されているためメール受信時のマルウェアチェックが困難であること。そして近年、パスワード付きZIPファイルを悪用したサイバー攻撃の事例が確認されていることです。

新方式では、同行の役職員が添付ファイルを送る際、メール本文に専用ダウンロードサイトへアクセスするためのURLを記載します。受け手はそのサイトにアクセスし、別送されるダウンロード専用のパスワードを使ってファイルを取得します。

PPAPの何が問題だったのか

PPAPの是非については、昨年「AWSからSMSにメッセージを送る」という記事で一度整理しました。

そのとき、機密文書をメールで送る手段を秘匿性と本人確認性の観点で並べて評価したのですが、結論は変わっていません。

PPAP、つまり暗号化ファイルとパスワードを同じ経路で送る方法は、1通盗まれればすべて漏洩します。パスワードを別メールにしても、同じメールインフラを流れる以上、傍受や誤送信のリスクは本質的には下がりません。加えて、暗号化されたZIPはメールゲートウェイでウイルススキャンできないため、マルウェアの運び屋になりやすい。三菱UFJ銀行が今回理由として挙げているのは、まさにこの最後の点です。

ですから、PPAPをやめるという判断そのものは正しいと思います。日本でも2020年に政府がPPAPの廃止方針を打ち出して以降の流れに沿っていますし、銀行という立場で旗を振る意味も小さくありません。

新方式は本当に安全になったのか

問題は、その置き換え先です。

新方式は「メール本文にダウンロードサイトのURLを記載し、パスワードは別送する」というものでした。マルウェアスキャンの観点では確かに前進しています。ファイルが暗号化ZIPとしてメールに乗らなくなるので、受信側のゲートウェイで中身を検査できるようになるからです。

しかし、フィッシング耐性という観点では、むしろ後退しかねません。

ひとつは、銀行が自ら「メール本文のURLをクリックさせる」習慣を送信先に植え付けてしまう点です。銀行はこれまでフィッシング対策として、「当行からのメールにURLは記載しません」「メール内のリンクは開かないでください」と顧客には教育してきたはずです。メールの送信先は顧客ではないと思いますが、今回はその逆を習慣づけることになります。なりすましメールに偽のダウンロードURLが貼られていても、利用者は見分けがつかなくなります。

もうひとつは、「パスワードを別送する」という発想がPPAPのままという点です。日ごろ支援しているコンサルテーション会社やITベンダーはちゃんと技術的に支援できなかったんでしょうか？

URLとパスワードを両方メールで送るのであれば、構造的にはPPAPの暗号化ZIPをWebサイトに置き換えただけです。同じ経路を流れる以上、傍受や誤送信による漏洩リスクは解決していません。マルウェアの問題は片付いても、秘匿性の問題は手つかずなのです。

整理すると、今回の変更は「マルウェアスキャン」という一点ではマシになる一方で、フィッシング耐性では弱点を抱え込む、惜しい設計だと感じます。

本来あるべき姿

以前の記事でも書きましたが、現実的なのは認証付きのクラウドストレージで共有する方法でした。受け手がログインして初めてファイルにアクセスできる仕組みなら、URLが単体で漏れても無効ですし、誰がいつアクセスしたかのログも残せます。パスワードを別送する必要すらありません。

メールの送付先は取引業者だと思いますから、銀行が共通の認証を払い出すのは困難です。たとえばBoxやDropboxのようなクラウドストレージであれば、受け手は無料のアカウントを気軽に作れます。銀行側が取引先ごとにアカウントを発行・運用しなくても、受け手がログインして初めてファイルにアクセスできる仕組みを成り立たせられるわけです。 URLが単体で漏れても無効ですし、誰がいつアクセスしたかのログも残ります。

さらに言えば、この方式ならメールにリンクを書く必要すらありません。ファイルを共有すれば、受け手にはクラウドストレージ側から「共有されました」という通知が届きます。受け手は自分が信頼しているサービスにログインしてファイルを取りに行くだけです。冒頭で挙げた、メール内URLをクリックさせる習慣づけという問題が、根本から消えてなくなるのです。

より根本的な解はないのか

もっとも、銀行ともあろうものがファイルの受け渡しを外部のクラウドサービスに丸ごと預けるのも、それはそれで引っかかります。委託先管理やデータの所在、サービスへの従属といった問題が新たに生じるからです。だとすれば、現実的な落としどころは、銀行が認証付きの受け渡しポータルを自前で持つことでしょう。インターネットバンキングという認証基盤と運用ノウハウをすでに備え、取引先の本人確認も日常的に行っている組織です。 Boxがやっていることを内製すればよいだけです。技術力と体力の両面で、銀行はそれができる立場にあります。

では、もっと教科書的な根本解はないのか。あります。受け手の証明書でメールそのものを暗号化・署名するS/MIME、いわゆるPKIです。外部サービスやポータル、パスワードの別送といった仕組みが一切要らず、本人性と秘匿性をエンドツーエンドで担保できる、理屈のうえでは最も美しい解です。

ところがPKIは、米国ですら普及しませんでした。証明書の発行や管理が高コストで手作業が多く、ユーザーごと・端末ごとに鍵を入れて回る運用負荷に耐えられなかったためです。そして決定的なのは、送り手と受け手の双方が対応していないと成り立たないという両側依存です。暗号化して送るには、相手があらかじめ証明書を用意していなければなりません。相手が対応していなければ、文字どおり意味がない。この鶏と卵の構造ゆえに、誰も最初の一歩を踏み出せませんでした。受け手に「アカウントを作ってログインする」という自己完結した操作しか求めないポータル方式に世界が流れたのは、そのためです。

それでもリーダーシップを期待したかった

ここで私が惜しいと思うのは、まさにこの一点です。 PKIが普及しなかった最大の理由が「最初の一歩を誰も踏み出せなかった」ことなら、その一歩を踏み出せる体力と影響力を持つ組織こそ、日本を代表するメガバンクのはずです。

率先してS/MIMEを導入し、添付ファイルをやり取りするような主要な取引先には導入を促す。場合によっては証明書発行の基盤を貸し出したり、運用を支援したりする。そうやって両側依存の壁を、影響力のある側から崩していく。そんなリーダーシップを見せてくれたら、日本全体のメール文化が一段前に進んだかもしれません。

現実的な着地は認証付きポータルでよいと思います。ただ、PPAPをやめるという入口が正しかっただけに、出口がもう一歩踏み込めなかったのは惜しい。日本をリードする銀行のやることだからこそ、ここにこそリーダーシップを期待したかった、というのが私の正直な感想です。

References

株式会社三菱UFJ銀行. 「当行からの添付ファイル送信方法の変更に関するご案内」（2026年6月8日）
Coded Chords. 「AWSからSMSにメッセージを送る」（2025年6月9日）

無料で始める Cloudflare セキュリティ対策

2026-03-23T00:00:00+00:00

公開翌日に何が起きたか

先日の記事で紹介した生成AIを使ったAsk ページを公開した翌日、CloudflareのObservabilityを確認したところ、攻撃と思われるリクエストが並んでいました。

GET /.env — 環境変数ファイルの探索
/checkout, /plans, /signup — SaaS系パスの総当たり
/wp-login, /wp-admin, /xmlrpc.php — WordPress管理画面の探索
/api/v1/stripe/config.js, /api/v2/payment/keys.js — 決済APIの設定ファイル探索（Stripeはオンライン決済プラットフォーム）
config.php, /api/system/info — サーバー情報の収集

主にWordPressなどのCMSやStripeなどの決済サービスを狙ったスキャンです。静的サイト＋Workerという構成なのでそんなサービスは乗せていないのですが。公開されているエンドポイントに対してよく狙われる既知のパスを片っ端から叩いているのでしょう。

実害はありませんが、放置するのも気持ちが悪いですし、Workers AIのNeuronsを無駄に消費されるのは避けたいところです。Cloudflareの無料プランのセキュリティ機能で対策しました。

対策1: Bot Fight Mode

最も手軽な対策です。Cloudflareダッシュボードの Security > Bots から、ワンクリックで有効化できます。

Bot Fight ModeはCloudflareが持つボットの行動パターンデータベースを使い、自動化されたアクセスを検出して計算コストの高いチャレンジを返します。検索エンジンのクローラーなど検証済みの正当なボットは通過させる仕組みです。

設定はON/OFFだけで、細かなチューニングは有料プラン（Super Bot Fight Mode）の機能になります。それでも、汎用的なスキャンボットの大半はこれで弾けます。

注意点として、Bot Fight Modeは外部サービスからのWebhookやRSSリーダーのフィード取得など、正当な自動アクセスもブロックする場合があります。無料プランではWAFルールによるバイパス（Skip）ができないため、これらのサービスに影響が出た場合はBot Fight Mode自体を無効にする必要があります。

対策2: WAF カスタムルール

Bot Fight Modeをすり抜けるアクセスに対しては、WAF（Web Application Firewall）のカスタムルールで対処します。無料プランでは5つまでルールを作成できます。

ルール1: 許可パスの制限（ホワイトリスト）

最も効果が高いルールを最優先に配置します。ask.codedchords.devは /（フロントエンド）と /api/（Workers API）しか使わないので、それ以外を全てブロックします。

(http.host eq "ask.codedchords.dev")
and not (http.request.uri.path eq "/" or http.request.uri.path contains "/api/")

Actionは Block、Place atは First に設定します。

「正当なパスだけを許可する」ホワイトリスト方式なので、攻撃者がどんなパスを試してもすり抜けられません。ただし、対象サイトの構成を把握している必要があります。新しいパスを追加した際にルールの更新を忘れると自分自身のコンテンツがブロックされるため、サイト構成を変更したらルールも見直してください。

ルール2: スキャンパスの遮断（ブラックリスト）

ルール1はaskサブドメイン限定なので、ドメイン全体に適用する汎用ルールも設定します。WordPressやphpMyAdminなど、よく狙われるパスへのアクセスを一括でブロックします。

Security > Security rules > Create rule から、以下のExpressionを設定します。

(http.request.uri.path contains ".env")
or (http.request.uri.path contains "wp-login")
or (http.request.uri.path contains "wp-admin")
or (http.request.uri.path contains "xmlrpc.php")
or (http.request.uri.path contains "phpmyadmin")
or (http.request.uri.path contains "wp-content")
or (http.request.uri.path contains "wp-includes")

Actionは Block です。

このルールはサイトの構成に依存しないため、Cloudflareで管理しているドメイン全体に適用できます。WordPressを使っていないサイトであれば、デメリットはありません。

対策3: Rate Limiting

Bot Fight ModeとWAFルールを通過したリクエストに対する最後の砦です。同一IPからの過剰なリクエストを制限します。

Security > Security rules > Rate limiting rules から設定します。

項目	設定値
対象	`http.host eq "ask.codedchords.dev"`
判定基準	IP
レート	10リクエスト / 10秒
Action	Block（10秒間）

無料プランではRate Limitingルールは1つまで、ブロック期間は最大10秒という制約があります。大規模な攻撃には有料プランのRate Limiting（より長いブロック期間、より多くのルール）が必要ですが、スキャンボット対策としては十分です。上記の設定値は一例です。ページ内のリソース数や想定されるアクセスパターンに応じて調整してください。

なお、今回はWorkers側にも /api/ask エンドポイントに対して同一IP 60秒間10リクエストの制限を入れています。CloudflareのRate Limitingはインフラ層での粗いフィルタリング、Workers側はアプリケーション層での細かな制御という役割分担です。

3層防御の全体像

設定した対策を整理します。

レイヤー	対策	役割
第1層	Bot Fight Mode	既知のボットパターンを自動検出
第2層	WAF カスタムルール	不正なパス・不要なパスを遮断
第3層	Rate Limiting	過剰なリクエストを制限

いずれもCloudflareの無料プランで利用でき、設定はダッシュボードからの操作だけで完結します。

まとめ

これらの設定を適用した直後から、Observability上でスキャン系のリクエストがブロックされていることを確認できました。Workers AIのNeuronsが無駄に消費されることもなくなっています。

個人サイトであっても、公開すればスキャンボットは来ます。「小規模だから狙われない」ということはありません。ボットは規模を問わず、見つけたエンドポイントを片っ端から叩きます。

Cloudflareを使っているなら、無料プランの範囲でもBot Fight Mode、WAFカスタムルール、Rate Limitingの3つを設定するだけで、大半の自動化されたスキャンは防げます。設定にかかる時間は10分程度です。特にWorkers AIやAPIエンドポイントを公開している場合は、不要なリクエストによるリソース消費を防ぐためにも早めの対策をおすすめします。

References

Cloudflare. "Bot Fight Mode"
Cloudflare. "Custom rules"
Cloudflare. "Rate limiting rules"

SPFのDNSルックアップ上限10回、あなたの組織は大丈夫？

2026-03-03T00:00:00+00:00

転載元

この記事は Zenn に掲載した記事の転載です。

Table of Contents

はじめに

「ある日突然、自組織からのメールが取引先に届かなくなった」——そんな事態が、メール配信サービスを複数利用している組織で実際に起こり得ます。原因は、SPF（Sender Policy Framework）のDNSルックアップ上限です。

外部のメール配信サービスを導入するたびにSPFレコードへ include を追加していくと、気づかないうちに上限へ近づきます。しかも、上限超過のトリガーは自組織の操作ではなく、外部サービス側の設定変更かもしれません。

本記事では、SPFのDNSルックアップ上限の仕組みを解説し、上限超過のリスクと対策を整理します。

SPFの仕組みとDNSルックアップ上限

SPFは、メールの送信元ドメインが「どのサーバーからの送信を許可しているか」をDNSのTXTレコードで宣言する仕組みです。受信側メールサーバーは、送信元IPアドレスがSPFレコードに含まれているかを検証し、正当な送信元かどうかを判断します。

SPFレコードの例を示します。

v=spf1 ip4:192.0.2.0/24 include:spf.example.com ~all

この例では、192.0.2.0/24 のIPレンジからの送信と、spf.example.com が許可する送信元を正当とみなします。

SPFの検証は受信側メールサーバーで行われます。メールを受け取ったサーバーが送信元ドメインのSPFレコードをDNSに問い合わせ、送信元IPが許可されているかを確認します。この検証過程でDNSルックアップが発生しますが、RFC 7208（Section 4.6.4）により、1回のSPF検証で実行できるDNSルックアップは最大10回と制限されています。この制限は、SPF検証によるDNSサーバーへの負荷を防ぐために設けられたものです。

すべてのメカニズムがDNSルックアップを消費するわけではありません。消費するメカニズムとしないメカニズムを表にまとめます。

メカニズム / 修飾子	DNSルックアップ
`ip4` / `ip6`	0回（IP直接指定のためDNS不要）
`a`	1回
`mx`	1回（＋MXレコードが指すAレコードの解決）
`include`	1回＋参照先のSPFレコード内のルックアップ
`redirect`	1回
`exists`	1回

重要なのは include の挙動です。include は参照先のSPFレコードをさらに評価するため、参照先に include や a が含まれていれば、それらも合算されます。つまり、1つの include が実際には複数回のルックアップを消費する場合があります。

includeの入れ子で上限に近づく実例

架空の組織 example.or.jp を例に考えます。この組織では業務メールに加えて、メールマガジン配信に3つの外部サービスを利用しています。SPFレコードは以下のようになっています。

v=spf1 ip4:192.0.2.0/29 ip4:198.51.100.1 include:spf.mail-a.example include:spf.mail-b.example include:spf.mail-c.example include:spf.bizmail.example ~all

各エントリのDNSルックアップ数を確認します。

エントリ	DNSルックアップ
`ip4:192.0.2.0/29`	0回（IP直接指定）
`ip4:198.51.100.1`	0回（IP直接指定）
`include:spf.mail-a.example`	1回
`include:spf.mail-b.example`	1回＋内部で3回 = 4回
`include:spf.mail-c.example`	1回
`include:spf.bizmail.example`	1回
合計	7回 / 上限10回

一見すると余裕がありそうですが、問題は spf.mail-b.example の内部構造です。このSPFレコードは以下のようになっています。

v=spf1 exists:%{i}.spf.mail-b1.example exists:%{i}.spf.mail-b2.example include:spf.mail-b3.example ~all

include 1つで4回のルックアップを消費しています。そして、この内訳は外部サービス側の設定に依存しています。

ここに大きなリスクがあります。外部サービスがインフラ変更に伴いSPFレコードへ include や a を追加すれば、自組織が何も変更していなくてもルックアップ数が増加します。たとえば spf.mail-b.example が内部で1つ include を追加するだけで、合計は8回になり、上限までわずか2回です。さらに別のサービスも同様の変更をすれば、上限を超えてしまいます。

上限を超えるとどうなるか

SPFのルックアップ数が10回を超えると、SPFの検証結果は permerror（恒久的エラー）になります。これは「SPFレコードが壊れている」とみなされる状態です。

permerror が発生すると、受信側メールサーバーの設定に応じて以下のいずれかが起こります。

メールが拒否される（バウンス）
迷惑メールフォルダに振り分けられる
DMARCのSPF判定がfailとなり、DMARCポリシー次第でメールが拒否される

特に厄介なのは、この問題が自組織側からは気づきにくい点です。送信自体は正常に行われ、送信者にはエラーが返らない場合もあります。受信側で静かにスパム判定されるため、「最近メールの返信が来ない」「メルマガの開封率が急落した」といった間接的な兆候で初めて気づくことになります。

自分のドメインのルックアップ数を確認する方法

dig コマンドでSPFレコードの内容を確認できます。

dig +short TXT example.or.jp | grep spf

表示されたSPFレコードに含まれる include 先も再帰的に確認する必要があります。

dig +short TXT spf.mail-b.example

手動での再帰的な確認は手間がかかるため、オンラインツールの利用も有効です。

MXToolbox SPF Record Lookup — SPFレコードの内容とDNSルックアップ数を自動計算してくれる
dmarcian SPF Surveyor — SPFレコードの構造をツリー表示で可視化できる

これらのツールにドメイン名を入力するだけで、現在のルックアップ数と上限までの余裕を確認できます。定期的にチェックしておくことをお勧めします。

対策

SPFルックアップ上限の問題に対して、短期的な対策と中長期的な対策があります。

まず短期的な対策として、メール送信経路を棚卸しします。SPFレコードに登録されている include やIPアドレスが、現在も使われているかを確認します。利用を終了したサービスの include が残っていると、ルックアップ数を無駄に消費するだけでなく、そのサービスのIPレンジが自ドメインの正当な送信元として許可されたままになります。これはなりすましに悪用されるリスクでもあります。

次に、メール配信サービスの統合を検討します。メルマガ配信に複数のサービスを併用している場合、1つに統合すれば include の数を減らせます。配信実績の分析も一元化でき、コスト管理も簡素化されます。

これらの根本対策とは別に、技術的な回避策も存在します^[1]。ただし運用上の注意点があるため、まずは送信経路の整理を優先すべきです。

最後に、中長期的な対策としてDMARCポリシーの段階的強化があります。DMARCはSPFとDKIMの認証結果に基づいて、認証失敗時のメール処理方針を宣言する仕組みです。ポリシーは以下の順で強化します。

p=none（監視モード）でDMARCレポートを収集し、全送信経路の認証状況を把握する
全経路でSPF・DKIMがpassすることを確認したうえで p=quarantine（隔離）に移行する
一定期間の監視後、問題がなければ p=reject（拒否）に移行する

送信経路が整理されていれば、この移行は技術的には難しくありません。逆に、送信経路が乱立したままでは各経路の認証状況を把握すること自体が困難であり、DMARC強化は事実上不可能です。

まとめ

SPFのDNSルックアップ上限10回は、メール配信サービスを複数利用する組織にとって見落とされがちなリスクです。外部サービスの include は入れ子構造でルックアップ数が膨らみ、しかも外部サービス側の変更で自組織のルックアップ数が増加するという、制御しにくい特性があります。

まずは自分のドメインの現在のルックアップ数を確認してみてください。上限に近づいている場合は、不要な include の削除やサービスの統合を検討し、DMARCポリシーの強化と合わせてメール配信の信頼性を確保していくことが重要です。

技術的な回避策としてSPF MacroとSPF flatteningがあります。SPF Macroは exists メカニズムと変数を組み合わせてルックアップ数を抑える手法です。SPF flatteningは include 先のIPアドレスを直接 ip4 / ip6 で記述してルックアップを削減する手法です。ただしflatteningは参照先のIPが変更されたときに追従が必要なため、自動化ツールなしでの運用は推奨しません。 ↩

Cloudflare無料プランだけで個人サイトのセキュリティが完結した話

2026-02-20T00:00:00+00:00

TL;DR

Cloudflareのアドバンテージは、次の3点です。

無料プランだけでWAF・ボット対策まで揃う、セキュリティの充実度
DNS統合だからこそ、煩雑でリスクの高い設定をワンクリックで実現
AIクローラー対策やページ先読みなど、最新トレンドへの即応

つい3日前にCloudflareへ移転したばかりです。構成はシンプルで、Cloudflareでドメインを取得し、GitHubリポジトリと連携して静的コンテンツをCloudflare Pages^[1]へデプロイしています。この構成だけでも思いの外多くの恩恵が得られたので、まとめておきます。

Cloudflareでの設定

Cloudflareのダッシュボードで有効にした機能を、カテゴリごとに紹介します。いずれも無料プランで利用でき、ほとんどがトグルひとつで有効にできるものです。なお、本記事の機能名やβ表記は2026年2月時点のCloudflare管理画面のUIに基づいています。

Edge Certificates

Cloudflareが発行・管理するSSL/TLS証明書と、HTTPS通信に関する設定です。

項目	説明
Always Use HTTPS	HTTP でアクセスが来た場合に自動的に HTTPS へ301リダイレクトしてくれるので、暗号化されていない通信を防げる。
HSTS	`.dev` ドメイン^[2]を使用しているので私の場合あまり恩恵がないが、ブラウザレベルでHTTPSが強制できる。
Minimum TLS Version	サイトに接続する際に許可するTLSプロトコルの最低バージョンの指定。TLS 1.0 と 1.1 は既知の脆弱性があるので、私はTLS1.2にしている。
Opportunistic Encryption	HTTPでアクセスしてきたブラウザに対して「暗号化接続も利用可能ですよ」と通知する仕組み。`.dev` の場合、HTTPアクセスが発生しないので実質的に意味がない。
TLS 1.3	Minimum TLS Version を 1.2 に設定し、この TLS 1.3 をオンにしておけば、「最低 1.2、対応していれば 1.3 を使う」という構成になる。
Automatic HTTPS Rewrites	`http://` をCloudflare が自動的に `https://` に書き換えて「混在コンテンツ（mixed content）」の問題を防いでくれる。
Certificate Transparency Monitoring	自分が意図していない証明書が第三者によって発行された場合（ドメインの不正利用や乗っ取りの兆候）通知してくれる

Security

ボット対策、DDoS防御、WAFなど、サイトを外部の脅威から守るための設定です。

項目	説明
AI Labyrinth	まだβ機能だが、robots.txt 等のクロールルールを無視して勝手にサイトをスクレイピングするボットに対して偽コンテンツを読ませて学習データを汚染させるという「ハニーポット」的な機能
Block AI bots	AI学習用クローラーをブロックする機能
Bot fight mode	悪意のあるボット（スパム、クレデンシャルスタッフィング、DDoS等）を検知すると、JavaScriptチャレンジを出して人間かどうかを確認する
Browser Integrity Check	訪問者のHTTPヘッダーを検査して、不正なUser-Agentやスパムボットによく見られる異常なヘッダーパターンを検出し、脅威が見つかった場合はブロックページを表示する。
Challenge passage	チャレンジ（CAPTCHA等）をクリアした訪問者が、再度チャレンジを求められるまでの有効時間
HTTP DDoS attack protection	HTTPレイヤーのDDoS攻撃を自動検知・緩和する。無料プランでもCloudflare Free Managed Ruleset（基本的なWAFルール）が付属する
Manage your robots.txt	Cloudflare が robots.txt を自動管理するβ機能。Content Signals Policyを選択すると、コンテンツの利用意図を用途別（検索・AI入力・AI学習）に宣言できる
Network-layer DDoS attack protection	DDoS保護

DNS

DNS応答の改ざん防止やメールのなりすまし対策など、ドメインの信頼性を高める設定です。

項目	説明
DNSSEC	DNSレスポンスに暗号署名を付与して、DNS応答の偽造（DNSキャッシュポイズニング等）を防ぐ
Email Security	有効にしてDMARCの設定。メール送信の予定はないので、SPFは"v=spf1 -all"で設定。DMARCは"v=DMARC1; p=reject"

Speed

通信プロトコルの最適化やページ先読みなど、サイト表示を高速化するための設定です。

項目	説明
Web analytics using real user measurement (RUM)	実際の訪問者のブラウザからパフォーマンスデータ（ページ読み込み時間など）を収集する。Cookieを使わないプライバシー重視の計測方式
Speed Brain	ユーザーがリンクをクリックする前にページを先読みする機能。Speculation Rules API を使い、体感的なページ遷移が高速になる
HTTP/2	HTTP/1.1の後継。1つの接続で複数リクエストを並行処理（多重化）でき、ページ読み込みが高速になる
HTTP/3	HTTP/2の次世代版。TCPの代わりにQUICプロトコルを使い、接続確立が高速でパケットロス時の劣化も少ない
HTTP/2 to Origin	Cloudflareとオリジンサーバー間の通信にもHTTP/2を使う設定
0-RTT Connection Resumption	TLS 1.3で接続済みのクライアントが再訪問時にハンドシェイクの最初の往復を省略でき、再訪問者の初回リクエストが速くなる

以前のプラットフォームとの比較

昨年までAmazon Amplify、先月までGitHub Pagesで運用していました。上記で挙げたCloudflareの機能が、それぞれの環境ではどうだったかを比較してみます。特にセキュリティ列の差に注目してください。

○: 標準/無料で利用可能
△: 別途設定や追加費用で対応可能
×: 非対応
−: 該当なし

機能	Amplify + CloudFront	GitHub Pages	コメント
Always Use HTTPS	○	○
HSTS	△（手動設定）	○	AWSだけ手動設定の手間がかかる
Minimum TLS Version	○	×	GitHub Pagesは古いTLSを拒否できず、セキュリティポリシーを徹底しにくい
Opportunistic Encryption	×	×	HTTP接続の暗号化への誘導は他のサービスでは提供されていない
TLS 1.3	○	○
Automatic HTTPS Rewrites	×	×	他では混在コンテンツを自分で探して直す必要がある
Certificate Transparency Monitoring	△（ACMの一部）	×	不正な証明書発行の早期発見に差が出る
AI Labyrinth	×	×	ワンクリックでAIスクレイピングに対抗できる機能は他にない
Block AI bots	△（WAFルールで対応）	×	AWSは自前でルールを書く手間とWAF費用がかかる
Bot fight mode	△（WAF Bot Control有料）	×	AWSで同等機能を得るにはBot Control（月額$10〜＋リクエスト従量課金）が必要
Browser Integrity Check	△（WAFで部分的）	×	AWSでは同等ルールの自作が必要で、運用負荷が高い
Challenge passage	△（WAF）	×	Cloudflareはチャレンジの有効期間まで細かく制御できる
HTTP DDoS attack protection	△（WAFは有料）	×	無料でWAFまで付くのはCloudflareの大きな強み
Manage your robots.txt	×	×	増え続けるAIクローラーへの対応を自動化できる機能は他にない
Network-layer DDoS attack protection	○（Shield Standard）	○
DNSSEC	○（Route 53）	△（DNS providerに依存）	Cloudflareはワンクリック、DNS一体管理なので設定が圧倒的に楽
Email Security	○（Route 53）	△（DNS providerに依存）	同上。DNS管理とセットなのでSPF/DMARCの設定も迷わない
Web analytics (RUM)	△（CloudWatch RUM有料）	×	Cloudflareは追加費用なしでCookie不要の計測が使える
Speed Brain	×	×	ページ先読みによる体感速度向上は他のサービスでは提供されていない
HTTP/2	○	○
HTTP/3	○	×	GitHub Pagesは2026年2月時点でHTTP/3未サポート
HTTP/2 to Origin	○	−	オリジンサーバーがある構成でのみ意味がある
0-RTT	×	×	再訪問時の体感速度に差が出る。他のサービスでは無料で提供されていない

AI時代のコンテンツ保護

Cloudflareの無料プランには、AIクローラーに対応する機能が複数用意されています。これらは独立した機能ですが、組み合わせると多層的な防御になります。

機能	レイヤー	役割
Content Signals Policy	意思表示	robots.txt内でコンテンツの用途別に許可/拒否を宣言する。強制力はなく、善意あるクローラーへの「お願い」
Block AI bots	技術的ブロック	Cloudflareが「AI学習用」と分類するクローラーをWAFレベルでブロックする。検索エンジンやAIアシスタントは対象外
AI Labyrinth	欺瞞防御	ブロックを無視するクローラーに偽コンテンツを読ませ、学習データを汚染させるハニーポット

ポイントは、Content Signals PolicyとBlock AI botsの役割分担です。Content Signals Policyでは search=yes, ai-input=yes, ai-train=no のように宣言し、「検索やAI回答での引用はOKだが、モデルの学習には使うな」という意思を伝えます。しかし宣言はあくまで「お願い」なので、AI学習用クローラーに対してはBlock AI botsがWAFレベルで実際にアクセスを遮断します。それでもすり抜けてくるクローラーにはAI Labyrinthが偽データを食わせます。

さらに、AI Crawl ControlのCrawlersタブではクローラーごとに個別のAllow/Blockを設定できます。たとえば「ChatGPT-Userは許可するがBytespiderはブロックする」といった細かい制御も可能です。

この多層構成により、AI検索からの流入を確保しつつ学習目的のスクレイピングは拒否するという運用が、無料プランだけで実現できます。

Cloudflareの評価

比較表を振り返ると、Cloudflareの強みは大きく3つあります。

1つ目は、無料プランでのセキュリティの充実度です。AWSで同等のボット対策やWAFを実現しようとすると、AWS WAFやBot Controlの追加費用と自前でのルール作成が必要でした。GitHub Pagesではユーザーが設定できるセキュリティ機能はほとんどありません。Cloudflareでは、AIボットのブロック、Bot fight mode、WAFまで無料プランに含まれており、しかもダッシュボードのトグルひとつで有効にできます。

2つ目は、DNS・証明書・セキュリティ・CDNがひとつのダッシュボードに統合されている点です。AWSではRoute 53、CloudFront、ACM、WAFと複数サービスをまたいで設定する必要がありました。GitHub PagesではDNSが外部依存のため、DNSSECやSPF/DMARCの設定は利用するDNSプロバイダ次第でした。Cloudflareではドメイン取得からDNSSEC、メールセキュリティ、デプロイまで一箇所で完結するため、設定の見通しがよく管理も楽です。

3つ目は、他のサービスでは提供されていない独自機能です。前述のとおり、Content Signals PolicyからBlock AI bots、AI Labyrinthまで、AIクローラーへの多層的な対応が無料プランだけで揃います。加えて、Speculation Rules APIを活用したSpeed BrainやTLS 1.3の0-RTT再接続など、パフォーマンス面でも独自の機能が提供されています。特にAIクローラー対策は今後ますます重要になる領域であり、「意思表示」と「技術的ブロック」と「欺瞞防御」を組み合わせた構成がワンクリックで手に入るのは大きな安心感があります。

個人の静的サイトという用途では、Cloudflareの無料プランだけで「やりたいことが全部できる」状態になりました。以前はAWSの複数サービスを組み合わせて実現していたことが、Cloudflareではひとつのダッシュボードで、しかも無料で手に入ります。移行してよかったと素直に思います。

Cloudflare Pagesは現在、Cloudflare Workersとの統合が進んでいる。将来的にはWorkersの静的アセット機能に一本化される見込みだが、Pages自体も引き続き利用可能。 ↩
.dev ドメインはGoogleが管理しているTLDで、HSTS Preload ListにTLD単位で登録済みなので最初からHTTPSが強制される。 ↩

GitHub Pagesのセキュリティヘッダー警告、無視していいの？

2026-02-06T00:00:00+00:00

NOTE

この記事は Zenn.dev に掲載した記事の転載です。

TL;DR

GitHub Pagesではセキュリティヘッダーを設定する機能がなく、スキャナーの警告がでる
セキュリティスキャナーの警告は「ベストプラクティス未達」であり「脆弱性」ではない
GitHub Pagesでは大抵静的サイトのため、放置しても実質的なリスクは低い
自前でホスティングしたWordPressなどの動的サイトは必ず対応すべき

セキュリティヘッダーとは何か

セキュリティスキャナーでよく指摘される6つのHTTPレスポンスヘッダーがあります。

ヘッダー	目的	設定しないリスク
Strict-Transport-Security (HSTS)	HTTPS接続を強制	HTTPへのダウングレード攻撃
Content-Security-Policy (CSP)	XSS攻撃を防止	悪意あるスクリプト実行
X-Frame-Options	クリックジャッキング防止	偽サイトへの埋め込み
X-Content-Type-Options	MIMEスニッフィング防止	ファイル種別の誤認識
Referrer-Policy	リファラー情報の制御	URLパラメータの漏洩
Permissions-Policy	ブラウザ機能の制御	カメラ等の不正利用

これらのヘッダーは、Webサーバーがレスポンスに含めることで、ブラウザにセキュリティ関連の指示を与えます。

GitHub Pagesの制限

GitHub Pagesは静的サイトホスティングサービスですが、 HTTPレスポンスヘッダーをカスタマイズする機能がありません。

.htaccess は使えない（Apache設定ファイル）
nginx.conf も使えない（Nginx設定ファイル）
GitHub側で固定されたヘッダーが返される

どうしてもセキュリティヘッダーを設定したい場合は、Cloudflare CDNを前段に置けばTransform Rulesでヘッダーを追加できます。ただし、Cloudflareの無料プランはネームサーバー移管が必須です。

既存のDNSサービスを使い続けたい場合、この方法は採用しづらいです。

静的サイトと動的サイトでリスクが違う

セキュリティヘッダーの重要度は、サイトの種類によって大きく異なります。 GitHub Pagesでも動的なSPAをホストできますが、ここではZolaやHugoなどのSSGで生成した純粋な静的サイトを想定しています。

観点	静的サイト（SSG生成）	動的サイト（WordPress等）
ユーザー入力	受け付けない	フォーム等で受け付ける
サーバーサイド処理	なし	PHP + DB
管理画面	なし	`/wp-admin` 等が存在
XSSリスク	ほぼなし	高い
クリックジャッキング	影響軽微	管理画面が標的になる

WordPressでセキュリティヘッダーが未設定の場合、管理者がログイン中にクリックジャッキング攻撃を受けたり、 XSS経由でマルウェアを注入されたりするリスクがあります。

判断基準：いつ対応すべきか

以下のフローチャートで判断できます。

flowchart LR
A[フォームがある？] -->|Yes| B[対応すべき]
A -->|No| C[サイトの性質は？]
C -->|個人ブログ| D[放置OK]
C -->|企業サイト| E[できれば対応]
C -->|公的機関| F[対応すべき]

フォームがあるサイトは対応が必要です。問い合わせフォーム、会員登録、ログイン機能、寄付やEC機能があれば、ユーザー入力を受け付けるためXSSのリスクがあります。

フォームがない場合はサイトの性質で判断します。個人の技術ブログやポートフォリオなら放置で問題ありません。公的機関などのサイトは、信頼性の観点から対応が望ましいです。

まとめ

セキュリティスキャナーの警告を見ると焦りますが、すべての警告に対応する必要はありません。

重要なのはリスク評価です。

何を守る必要があるか（資産）
どんな攻撃が想定されるか（脅威）
攻撃が成功する可能性はあるか（脆弱性）

GitHub Pagesで静的ブログを公開している場合、セキュリティヘッダーがなくても攻撃面がほとんどありません。「設定できないから放置」は、この場合は合理的な判断です。

一方、WordPressや動的サイトでは事情が異なります。 .htaccess やプラグインで設定できるので、対応しておくべきです。

スキャナーの警告は「ベストプラクティスに従っていない」という指摘であり、「今すぐ危険」という意味ではありません。コンテキストに応じた判断をしましょう。

参考文献

免責事項

本記事は情報提供を目的としており、個別の状況に応じた判断は読者ご自身の責任でお願いします。セキュリティ要件は組織やサービスによって異なるため、必要に応じて専門家にご相談ください。

React Server Components RCE脆弱性（CVE-2025-55182）への対応記録

2025-12-06T00:00:00+00:00

脆弱性の概要

CVE-2025-55182とは

CVE-2025-55182は、React 19のServer Components（RSC）における「Flight」プロトコルの安全でないデシリアライゼーション（deserialize）に起因する脆弱性です。主な特徴は次の通りです。

CVSSスコア: 10.0（最大値）
影響範囲: React 19.0.0、19.1.0、19.1.1、19.2.0
攻撃条件: 認証不要、細工されたHTTPリクエストのみで実行可能
デフォルト設定で脆弱: create-next-appにより作成した標準的なNext.jsアプリケーションが影響を受ける

技術的な仕組み

この脆弱性は、RSCの内部通信プロトコルである「Flight」の処理において、攻撃者の制御可能なデータを適切な検証なしにデシリアライズしてしまうことに起因します。攻撃者からペイロードを含むHTTPリクエストが送信されると、サーバー側ではこれをFlightプロトコルのデータとして処理し、検証なしにデシリアライズします。この結果、任意のコードを実行される可能性があります。

重要なのは、この処理がアプリケーションの認証ロジックより前、つまりMiddlewareでの保護より深い層で行われるため、通常の認証機構では防げないという点です。

CVE番号の統合経緯

2025年12月3日時点では、以下の2つのCVE番号で追跡されていました。

CVE-2025-55182: React Server Componentsの脆弱性
CVE-2025-66478: Next.jsの脆弱性

調査の結果、Next.jsの脆弱性は実質的にReactの脆弱性に起因することが判明し、CVE-2025-66478は重複として却下されました。現在はCVE-2025-55182に統合されています。

この経緯は、脆弱性の根本原因がReactのRSC実装そのものにあり、Next.jsはその影響を受けていたに過ぎないことを示しています。

影響を受けるバージョンと修正版

React / React-dom

影響を受けるバージョン	修正済みバージョン
19.0.0	19.0.1
19.1.0, 19.1.1	19.1.2
19.2.0	19.2.1

Next.js

影響を受けるバージョン	修正済みバージョン
15.x（全般）	15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7
16.x（全般）	16.0.7
14.3.0-canary.77以降	（14.x Stable版は影響なし）

注: Next.js 13.x、14.x stable版、Pages Router、Edge Runtimeは影響を受けません。

実際の攻撃状況

この脆弱性は公表直後から実際に悪用されています。

2025年12月3日: 脆弱性が公表される
同日中: 中国関連の脅威グループによる大規模な攻撃活動が観測される
2025年12月5日午前6時（UTC）以降: Wizのセンサーが複数の被害者を検知

この脆弱性は「React2Shell」または「React4Shell」という名称でも呼ばれ、既に実証コード（PoC）が公開されています。

当ブログでの対応状況

対応タイムライン

2025年12月3日: CVE-2025-55182が公表される
2025年12月5日: 当ブログで修正版へのアップデート実施（v1.7.1）

実施した対応

以下のパッケージを修正版にアップデートしました。

# 実施したアップデート
React: 19.0.0 → 19.2.1
React-dom: 19.0.0 → 19.2.1
Next.js: 15.2.3 → 15.5.7
@next/mdx: 15.2.3 → 15.5.7
eslint-config-next: 15.2.3 → 15.5.7

当ブログはCVE-2025-55182に完全対応済みであり、この脆弱性の影響を受けない安全な状態です。

推奨される対応

Next.jsやReactを使用しているプロジェクトをお持ちの方は、以下の対応を推奨します。

1. バージョンの確認

まず現在のバージョンを確認します。

npm list next react react-dom

2. 修正版へのアップデート

該当する場合は、直ちに修正版へアップデートしてください。

# npm の場合
npm install next@latest react@latest react-dom@latest

# yarn の場合
yarn add next@latest react@latest react-dom@latest

# pnpm の場合
pnpm add next@latest react@latest react-dom@latest

3. 内部依存関係の確認

package.jsonだけでなく、ロックファイル（package-lock.json、yarn.lockなど）も確認し、内部依存関係として古いバージョンが残っていないか確認することを強く推奨します。

# ロックファイル内のReactバージョンを確認
grep -A5 '"react":' package-lock.json
grep -A5 '"next":' package-lock.json

4. デプロイ

アップデート後は速やかにビルドとデプロイを実施してください。

npm run build
# デプロイコマンドを実行

まとめ

CVE-2025-55182は、React Server Componentsの根本的な脆弱性であり、 CVSS 10.0という最大の深刻度を持つ重大な問題です。デフォルト設定で脆弱であり、認証を回避して攻撃可能という特性から、速やかな対応が必要です。

当ブログでは公表から2日以内に対応を完了しましたが、既に実際の攻撃が観測されているため、まだ対応されていない方は最優先で対応することを強く推奨します。

参考リンク

OpenAIではパスワード変更機能が提供されていない？

2025-07-18T00:00:00+00:00

最近はずっとClaudeを利用していてChatGPT/OpenAIはご無沙汰しています。しかし、なぜかパスワードマネージャーからOpenAIのパスワードが使い回しという警告が出てしまったので、パスワードを変更することにしました。

しかし、ここで気付いたのです。パスワード変更機能が提供されていないということに。

以下は、OpenAIアカウントのセキュリティ設定画面です。

多要素認証の設定しかありません。

Anthropic MCP Inspectorに重大な脆弱性

2025-07-02T00:00:00+00:00

Table of Contents

開発者向けツールとはいえ、CVSSスコア9.4という深刻度の高さに、セキュリティ対策の重要性を改めて認識させられました。

はじめに

jrnlのジャーナルにClaude Desktopなどからアクセスを可能とするMCPサーバーを開発中で、統合テスト時にドライバーを探していてMCP Inspectorを検討していたところ、脆弱性の報告があり驚きました。開発者向けツールとはいえ、CVSSスコア9.4という深刻度の高さに、セキュリティ対策の重要性を改めて認識しました。

MCP Inspector とは何？

MCP Inspectorは、Anthropicが提供するModel Context Protocol (MCP) サーバーのテスト・デバッグツールです。MCPは2024年11月に発表された、LLMアプリケーションと外部データソースやツールとの連携を標準化するオープンプロトコルです。

MCP Inspectorは主に以下のような場面で使用されます。

MCPサーバー開発者が実装の動作確認を行う際
API統合のデバッグやトラブルシューティング時
本番環境へのデプロイ前の検証作業

ツールはWeb UIを提供するクライアントと、各種MCPサーバーへの接続を仲介するプロキシサーバーで構成されています。

MCP Inspector の脆弱性とは

2025年7月に報告された脆弱性CVE-2025-49596は、悪意のあるWebサイトにアクセスするだけでリモートコード実行を可能にする重大な問題です。

元記事：Critical Vulnerability in Anthropic's MCP Exposes Developer Machines to Remote Exploits

攻撃手法は以下の要素を組み合わせたものです。

19年前から存在するブラウザの脆弱性「0.0.0.0 Day」を利用
MCP InspectorのCSRF脆弱性と連鎖させる
localhostで動作するサービスへ不正なリクエストを送信

根本原因はデフォルト設定における認証と暗号化の欠如でした。プロキシサーバーが0.0.0.0でリッスンし、クライアントとの間に認証機構がなかったため、任意のコマンド実行が可能となっていました。

影響範囲はMCP Inspectorを使用している開発者に限定されます。一般のMCPユーザーや本番環境のMCPサーバーには直接影響しません。ただし、攻撃を受けた開発者のマシンから機密情報が漏洩したり、ネットワーク内への侵入経路として悪用される可能性があります。

まとめ

この脆弱性は2025年6月13日にリリースされたバージョン0.14.1で修正されています。MCP Inspectorを使用している開発者は直ちにアップデートすることを推奨します。

開発ツールであっても適切なセキュリティ対策が必要であることを示す事例となりました。特にlocalhostで動作するサービスも攻撃対象となりうることを認識し、開発環境のセキュリティにも十分な注意を払う必要があると肝に銘じました。

Webサイト脆弱性スキャン入門：NucleiとKatanaで始めるセキュリティチェック

2025-06-04T00:00:00+00:00

Table of Contents

ebサイトのセキュリティが気になるけど、専門的な知識がなくて何から始めればいいか分からない...そんなIT技術者の方に向けて、オープンソースのツールを使った脆弱性スキャンの方法をご紹介します。今回は「Nuclei」と「Katana」という2つのツールを組み合わせて、効率的にWebサイトの脆弱性をチェックする方法を解説していきます。

1. NucleiとKatanaとは？

NucleiはProjectDiscoveryが開発したオープンソースの脆弱性スキャナーです。最大の特徴は以下の通りです。

テンプレートベース：YAML形式のテンプレートで脆弱性パターンを定義
コミュニティ駆動：世界中のセキュリティ研究者が3000以上のテンプレートを提供
高速処理：並列処理による効率的なスキャン
低い誤検出率：実際の脆弱性を模擬したテストで精度が高い
多様な対応：CVE、設定ミス、情報漏洩など幅広い脆弱性に対応

KatanaもProjectDiscoveryが開発したWebクローラーです。

高速クロール：Go言語で開発された軽量高速なクローラー
JavaScript対応：SPA（Single Page Application）も適切にクロール
設定柔軟：クロール深度や対象範囲を細かく制御可能
Nuclei連携：同じ開発元のため、Nucleiとの相性が抜群

両者ともProjectDiscoveryが開発したツールですが、この組み合わせが良い理由は次の通りです。

Katanaでサイト全体のURLを収集
NucleiでそれらのURLに対して脆弱性をチェック
両ツールとも同じ開発元なので連携がスムーズ
オープンソースなので無料で利用可能

2. インストール方法

前提条件は次の通りです。

macOS
Homebrew（未インストールの場合は公式サイトからインストール）
Go言語環境（brew install goでインストール可能）

インストール手順は以下の通りです。初回実行時にNucleiが自動的にテンプレートをダウンロードします。

# Homebrewを使用（推奨）
brew install nuclei

# インストール確認
nuclei -version

# Go言語でインストール
go install github.com/projectdiscovery/katana/cmd/katana@latest

# インストール確認
katana -version

# テンプレートの手動更新（定期的に実行推奨）
nuclei -update-templates

3. 実行方法と結果の確認

最もシンプルな使い方から始めましょう。単一のURLを検査する方法です。

# 基本的なスキャン
nuclei -u https://example.com -o results.txt

# 重要度の高い脆弱性のみチェック
nuclei -u https://example.com -s critical,high,medium -o important_vulns.txt

サイト全体をチェックしたい場合は、次のような手順となります。

# 1. Katanaでサイト全体をクロール
katana -u https://example.com -d 2 -o urls.txt

# 2. 不要なファイルを除外
grep -v -E '\.(jpg|jpeg|png|gif|css|js|ico)$' urls.txt > filtered_urls.txt

# 3. Nucleiで脆弱性スキャン
nuclei -l filtered_urls.txt -s critical,high,medium -o vulnerability_report.txt

脆弱性が発見されなければ何も出力されません。脆弱性が発見された場合は発見された内容が出力されていますので、以下のように確認できます。

# 発見された脆弱性の数
wc -l vulnerability_report.txt

# 脆弱性の内容確認
cat vulnerability_report.txt

# 重要度別の集計
cat vulnerability_report.txt | grep -oE '\[(critical|high|medium|low)\]' | sort | uniq -c

4. どのような検証がなされているか確認する方法

仕事などで脆弱性検証する場合、「で、一体何が検証されたん？」と聞かれることもあると思います。3,000以上のテンプレートを使用しているので、簡単にどんなテンプレートが使用されているか把握する方法です。

# 全テンプレート数
nuclei -tl | wc -l

# カテゴリ別のテンプレート数
echo "CVE脆弱性: $(nuclei -tl -tags cve | wc -l)"
echo "情報漏洩: $(nuclei -tl -tags exposure | wc -l)"
echo "設定ミス: $(nuclei -tl -tags misconfig | wc -l)"
echo "XSS: $(nuclei -tl -tags xss | wc -l)"
echo "LFI: $(nuclei -tl -tags lfi | wc -l)"
echo "管理画面: $(nuclei -tl -tags panel | wc -l)"
echo "技術スタック: $(nuclei -tl -tags tech | wc -l)"
echo "情報収集: $(nuclei -tl -tags osint | wc -l)"

# 重要度で判別
nuclei -tl -s critical | wc -l     # 1321件
nuclei -tl -s high | wc -l         # 2377件
nuclei -tl -s medium | wc -l       # 2322件
nuclei -tl -s low | wc -l          # 316件
nuclei -tl -s info | wc -l         # 4086件

脆弱性が発見された場合は、以下のように詳細ログを確認しましょう。

# 詳細ログ付きで実行
nuclei -u https://example.com -v -o results.txt

# 特定カテゴリのテンプレート一覧
nuclei -tl -tags cve | head -10

CVE（Common Vulnerabilities and Exposures）について

CVEは世界共通のセキュリティ脆弱性カタログです。

命名規則：CVE-YYYY-NNNNN（年-通し番号）
例：CVE-2021-44228（Log4jの重大な脆弱性）
Nucleiは3000以上のCVEに対応したテンプレートを保有

5. 実践的な使い分け

実践的な使い方をまとめてみしょう。

# クイックチェック（30秒以内）
nuclei -u https://example.com -t exposures/ -s critical,high

# バランス型チェック（1-2分）
nuclei -u https://example.com -t cves/,exposures/ -s medium,high,critical

# 徹底スキャン（5-10分） - 新サイトの評価など
katana -u https://example.com -d 2 | nuclei -s critical,high,medium

テンプレート選択は以下のような指針で運用するとよいと思います。

初回チェック：cves/,exposures/（CVEと情報漏洩）
定期チェック：-s critical,high（重要度の高いもののみ）
詳細調査：全テンプレート使用

6. パフォーマンス最適化

脆弱性の検証自体は結構重たい処理なってしまうので、パフォーマンスが問題となる場合は、以下のような並行度やレート制限を調整しましょう。

# 並列度とレート制限の調整
nuclei -u https://example.com -c 50 -rl 100 -timeout 5

# バッチ処理での最適化
nuclei -l urls.txt -c 25 -rl 50 -bulk-size 25

-c 50：同時実行テンプレート数を50に設定
-rl 100：1秒間に100リクエストまで
-timeout 5：タイムアウトを5秒に短縮

7. セキュリティ向上のための継続的運用

継続的に運用するために、次のようなスクリプトを組んでcronなどで自動運用する方法もよいと思います。

#!/bin/bash
# daily_security_check.sh

TARGET="https://your-website.com"
DATE=$(date +%Y%m%d)
OUTPUT_DIR="security_scans/$DATE"

# 金曜日（5）かチェック
if [ $(date +%u) -eq 5 ]; then
    echo "金曜日なので、テンプレートを更新します..."
    nuclei -update-templates
fi

mkdir -p "$OUTPUT_DIR"

# 高優先度の脆弱性をチェック
nuclei -u "$TARGET" -s critical,high -o "$OUTPUT_DIR/critical_scan.txt"

# 結果をメール送信（お好みで）
if [ -s "$OUTPUT_DIR/critical_scan.txt" ]; then
    mail -s "セキュリティアラート: $TARGET" admin@company.com < "$OUTPUT_DIR/critical_scan.txt"
fi

8. 他ツールとの連携例

Webサイトが静的サイトジェネレーターなどで組まれている場合は、サイト生成のCI/CDパイプラインに脆弱性検証を組み込むという手もあります。

以下は、GitHub Actionsの例です。

# GitHub Actions例
name: Security Scan
on:
  schedule:
    - cron: "0 9 * * 1" # 毎週月曜日9時

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Install Nuclei
        run: |
          go install github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

      - name: Run Security Scan
        run: |
          nuclei -u ${{ secrets.TARGET_URL }} -s critical,high -o scan_results.txt

      - name: Upload Results
        uses: actions/upload-artifact@v2
        with:
          name: security-scan-results
          path: scan_results.txt

また、レポート生成の自動化、定期的な処理などの最後にレポート出力を組み込んでも良いと思います。

# 簡単なサマリーレポート生成
generate_security_report() {
    TARGET=$1
    OUTPUT="security_report_$(date +%Y%m%d).txt"

    echo "=== セキュリティスキャンレポート ===" > "$OUTPUT"
    echo "対象サイト: $TARGET" >> "$OUTPUT"
    echo "スキャン日時: $(date)" >> "$OUTPUT"
    echo "" >> "$OUTPUT"

    # スキャン実行
    nuclei -u "$TARGET" -s critical,high,medium -o temp_results.txt

    echo "発見された脆弱性数: $(wc -l < temp_results.txt)" >> "$OUTPUT"
    echo "" >> "$OUTPUT"
    echo "詳細結果:" >> "$OUTPUT"
    cat temp_results.txt >> "$OUTPUT"

    rm temp_results.txt
    echo "レポートを生成しました: $OUTPUT"
}

# 使用例
generate_security_report "https://example.com"

⚠️ 重要：責任ある使用のための注意事項

脆弱性の検証はサーバーに非常に負荷をかけるため、不正アクセス禁止法、電子計算機損壊等業務妨害罪、偽計業務妨害罪などに抵触し違法行為になる可能性があります。

必ず以下を遵守しましょう。

所有権の確認
- 自分が所有するサイトのみスキャンしてください
- 他者のサイトには必ず事前許可を取得してください
適切な負荷制御
- 本番サイトへの負荷を考慮してレート制限を設定
- 業務時間外でのスキャン実施を推奨
結果の適切な管理
- スキャン結果に機密情報が含まれる可能性あり
- 結果ファイルの保存場所とアクセス権限に注意

なぜ偽計業務妨害罪となる可能性があるか

偽計業務妨害罪（刑法233条）の要件は、以下の3つです。

偽計：虚偽の情報や人を欺く行為
業務妨害：他人の業務を妨害すること
故意：妨害する意図があること

脆弱性検査はサーバーに非常に負荷を掛ける処理であることは知られているので、業務妨害と故意であることは分かりやすいと思います。

「偽計」については、脆弱性スキャンはブラウザの正常なアクセスを装ってリクエストヘッダを偽装しつつ「負荷」という観点では攻撃的とも言えるペイロードを送信するため「偽計」と見なされる可能性があります。

まとめ

NucleiとKatanaを使った脆弱性スキャンは、以下のような方に特におすすめです。

自社サイトのセキュリティ状況を定期的にチェックしたい
オープンソースツールでコストを抑えたい
コマンドラインツールに慣れている
セキュリティの基本的な知識を実践で学びたい

最初は単一URLの簡単なチェックから始めて、慣れてきたらサイト全体のスキャンや自動化に挑戦してみてください。重要なのは継続的にセキュリティをチェックする習慣を作ることです。

脆弱性が見つからない結果も良い結果です。むしろサイトが適切にメンテナンスされている証拠として安心できる材料になります。

セキュリティは一度設定すれば終わりではなく、継続的な取り組みが重要です。このツールを活用して、より安全なWebサイト運営を目指しましょう。

参考リンク

注意：この記事の内容は啓蒙目的であり、適切な許可なく他者のシステムをスキャンすることは違法行為となる可能性があります。必ず責任を持って使用してください。

Authorization Bypass in Next.js Middleware

2025-03-22T00:00:00+00:00

CVE情報

CVE番号: CVE-2025-29927
GHSAコード: GHSA-f82v-jwr5-mffw

攻撃者が特定のHTTPヘッダーを操作することで、ミドルウェアの認証チェックを迂回し、保護されたリソースにアクセスできてしまう問題のようです。

アップデート手順

アップデートの手順は次の通りです。

# Next.jsのアップデート
npm install next@15.2.3 @next/mdx@15.2.3 eslint-config-next@15.2.3
# npx next updateでもいいか。

# アップデート後問題ないか、一応Lintをかけておく
npm run lint

The Ultimate Showdown: A Deep Dive into Modern Messaging Apps

2024-10-23T00:00:00+00:00

市川強盗傷害事件で犯人たちが「秘匿性が高い通信アプリを使用」とアプリ名を伏せて報道されています。どうやらSignalを使っていたようです。こうなるとバカなメディアや視聴者が「邪悪なアプリ」と騒ぎ出しそうですね。

プライバシー^[1] を考慮すると当然の選択ですね。公安や自衛隊でもSignalを奨励しているようです。不完全な暗号化やメタデータ収集するLINEとかいうアプリを使っている能天気なメディアや視聴者より、犯人たちのほうがよほど高いリテラシーを持っていたということでしょう。

気になったので、主要なメッセージングアプリについての比較表を作ってみました。

メッセージングアプリの総合比較表

以下は主なメッセージングアプリのついての比較をまとめた表です。

犯人たちがSignalを使ったのも納得です。日本ではユーザーが少ないので利用シーンは限られますが。次点で Threema ですね。私は家族で使用しています。

iPhoneユーザーであれば iMessage は無難でしょう。完全にE2Eで暗号化されており、メタ情報の収集はされているようですが、Appleなので多少はマシだと思います。

Telegram はテロリストが使用しているイメージはありますが、意外に脆弱です。

LINEについては、日本でもユーザーが多いので補足を入れています。やはりLINEは暗号化も不完全でデフォルトの状態ですし、メタ情報^[1]をかなり収集しており、おまけに透明性の観点でもいろいろと問題^[2]がありました。

こう並べてみると、LINE を選択する意味が私にはわかりません。

機能/特徴	LINE	Signal	Threema	WhatsApp	iMessage	Telegram
E2E暗号化	部分対応[暗号化WP] ※1	完全対応	完全対応	完全対応	完全対応	Secret Chatのみ
グループチャット暗号化	50人以下のみ[暗号化WP]	完全対応	完全対応	完全対応	完全対応	Secret Chatのみ
メタデータ収集	多い[PP] ※2	最小限	最小限	多い	中程度	中程度
データストレージ	サーバー保存[暗号化WP,PP] ※3	端末のみ	端末のみ	クラウド可能	iCloud連携時保存	サーバー保存
電話番号必須	はい[PP]	はい	いいえ	はい	いいえ	はい
自動消去機能	24時間のみ[PP]	1秒～4週間	カスタム設定可	24時間～90日	2分～4週間	1秒～1週間
法執行機関への情報開示	多い[TR] ※4	最小限	最小限	多い	一部可能	最小限
追加機能	スタンプ/ゲーム/決済/音声・ビデオ通話[PP]	スタンプ/音声・ビデオ通話	投票/音声・ビデオ通話	ステータス/音声・ビデオ通話/決済	Apple統合/音声・ビデオ通話	Bot/チャンネル/音声・ビデオ通話
オープンソース	一部のみ[暗号化WP]	完全対応	一部のみ	なし	なし	クライアントのみ

※1: LINEのE2E暗号化（Letter Sealing）対応範囲(doc.1) （2026年7月追記: 2024年後半にLetter Sealingの保護対象が拡大されました。出典: LINE暗号化状況レポート（2025年））
- 対応: テキスト・位置情報（1対1と50人以下グループ）、1対1音声・ビデオ通話、画像・動画・音声メッセージ・ファイル添付（2024年後半に対応。1対1と50人以下グループ）
- 非対応: ~~画像、動画、ファイル添付、~~50人以上グループ、グループ通話、LINEミーティング、アルバム、ノート
※2: LINEのメタデータ収集内容(doc.2)
- アカウント情報（電話番号、メールアドレス）
- デバイス情報（使用OS、言語設定）
- アプリの使用頻度情報
- 位置情報（設定による）
- 友達関係の情報
※3: LINEのデータストレージ(doc.1,doc.2)
- メッセージはサーバーに保存
- クラウドバックアップ時は暗号化解除
- URL preview等の機能利用時はサーバーに内容送信
※4: 法執行機関への開示可能情報(doc.3)
- 7日分のテキストチャット履歴
- アカウント情報
- 通信ログ

判断は以下の[LINEの公式ドキュメント]より確認しています。

暗号化ホワイトペーパー(doc.1)^[3]
プライバシーポリシー(doc.2)
透明性レポート(doc.3)^[4]

私自身はThreemaを使用しています。

この場合「プライバシー」と呼ぶのが適当かわかりませんが。 ↩ ↩2
2021年のZホールディングとの経営統合で、トークの画像などの情報が韓国のサーバーでホスティングされていたり、通報確認などが中国企業に委託されていたり、このようなことが「第三国」としかレポートされていなかったりと透明性の観点で問題がありました。現在は解消されたと報告されていますが。 ↩
元のホワイトペーパー: https://scdn.line-apps.com/stf/linecorp/en/csr/line-encryption-whitepaper-ver2.1.pdf は現在アクセスできません ↩
元のレポートページは削除されました ↩

AWS ALBの脆弱性？

2024-08-28T00:00:00+00:00

First, the attacker creates their own ALB instance with authentication configured in their account. The attacker then uses this ALB to sign a token they fully control. Next, the attacker alters the ALB configuration and sets the issuer field to the victim's expected issuer. AWS subsequently signs the attacker's forged token with the victim's issuer. Finally, the attacker uses this minted token against the victim's application, bypassing both authentication and authorization.

まず、攻撃者は自身のアカウント内に認証を設定した独自の ALB インスタンスを作成します。次に、この ALB を使用して、攻撃者が完全に制御できるトークンに署名します。その後、攻撃者は ALB の設定を変更し、発行者フィールドを被害者が期待する発行者に設定します。 AWS はその結果、攻撃者が偽造したトークンに対して、被害者の発行者として署名を行います。最後に、攻撃者はこの生成されたトークンを使用して被害者のアプリケーションに対して攻撃を仕掛け、認証と認可の両方を回避します。
[ALBeast Security Advisory by Miggo Research | Miggo](https://www.miggo.io/resources/albeast-security-advisory-alb-vulnerability)

「AWS ALBの脆弱性」と騒がれているけれど、普通にIssuerの検証、JWTトークンの検証、ALBのトラフィックの制限、セキュリティグループの設定をやっていれば関係なくない？「AWS ALBのベストプラクティスを無視した間抜けが作ったアプリの脆弱性」では？

こだわりのNostr Pubkeyを手に入れる

2024-08-25T00:00:00+00:00

NostrでVanity pubkeyのMiningをやってみました。プリフィックスにyostosと近いy0st0sを得るため、ranaを使って数時間Miningしました。

得られた、Pubkeyがnpub1y0st0svvu5xg6dvswx7dz5m2p7004kmvsx6n22w4yjp3l6fa3mvsef2zz7で、npub1に続く部分がy0st0sとなっています。自己満足ですが。

ranaのインストールと使い方は次の通りです。Rustの実行環境が事前に必要です。

cargo install rana
rana --vanity-n-prefix y0st0s
Started mining process for vanity bech32 prefix[es]: 'npub1["y0st0s"]' (estimated pow: 24)
Benchmarking of cores disabled for vanity npub key upon proper calculation.
Mining using 14 cores...
<<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>>
Vanity npub found: y0st0s
Found matching Nostr public key:
Hex public key: 23e0b7c18ce50c8d359071bcd1536a0f9efadb6c81b53529d524831fe93d8ed9
Hex private key: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Npub public key: npub1y0st0svvu5xg6dvswx7dz5m2p7004kmvsx6n22w4yjp3l6fa3mvsef2zz7
Nsec private key: nsec1@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2597711770 iterations (about 2x10^9 hashes) in 3433 seconds. Avg rate 756688 hashes/second

プリフィックスに指定する桁数が増えるほどマイニングに時間がかかるので注意しましょう。上記の例ではM3 MAXのMacbook Proで1時間ほどかかりました。

また、PubkeyはNative SegWit(Bech32)でエンコードされており、小文字でl,b,i,oを除いた32文字しか使えません。これらの文字については数字などに置き換えて指定する必要があります（yostos->y0st0sなど）