https://codedchords.dev • This is a web feed, also known as an Atom feed. Subscribe by copying the URL from the address bar into your newsreader. Visit About Feeds to learn more and get started. It's free. Visit website Recent posts Updated on $DATE date Security A personal blog Zola2026-07-01T10:00:00+09:00https://codedchords.dev/tags/security/atom.xml 2026-07-01T10:00:00+09:00 2026-07-01T10:00:00+09:00 Toshiyuki Yoshida https://codedchords.dev/blog/2026/07/messenger-anonymity/ <!-- textlint-disable --> <img src="https:&#x2F;&#x2F;codedchords.dev&#x2F;blog&#x2F;2026&#x2F;07&#x2F;messenger-anonymity&#x2F;cover.webp?h=c60e5fcb30b3118d869c" alt="Cover" width="1536" height="864" loading="lazy" /><!-- textlint-enable --> <details> <summary>Table of Contents</summary> <!-- toc --> </details> <p>Threema GmbH（以下、Threema社）の公式ブログに「<a rel="external" href="https://threema.com/en/blog/anonymity-at-the-system-level-the-ultimate-privacy-protection">システムレベルの匿名性についての記事</a>」という記事が投稿されました。</p> <p>メッセージングアプリの匿名性について論じています。以前、市川の強盗傷害事件をきっかけに<a href="https://codedchords.dev/blog/2024/10/modern-messaging-apps/">暗号化やメタデータで機能比較した記事</a>を書きましたが、匿名性という観点はなかったのでこの記事を参考に解説したいと思います。</p> <h2 id="メッセージングアプリの匿名性について">メッセージングアプリの匿名性について</h2> <p>Threema社の技術記事では、匿名性を二種類に分けています。</p> <dl> <dt>水平的匿名性</dt> <dd>会話の相手に対する匿名性です。ユーザー名だけで連絡先を交換できれば、相手は電話番号や本名を知りません。対等な利用者どうしの間で成り立ちます。</dd> <dt>垂直的匿名性</dt> <dd>サービス運営者に対する匿名性です。登録時に電話番号やメールアドレスを渡していなければ、運営は身元を特定する手がかりを持ちません。利用者とサービスという上下の関係で成り立ちます。</dd> </dl> <p>Threema社は、ユーザー名機能で水平的匿名性は広まったものの、プライバシー保護で本当に重要なのは垂直的匿名性であり、これはセキュリティにおけるエンドツーエンド暗号化に相当する基盤だと主張します。あくまで同社の枠組みですが、この二軸はアプリを見比べる土台として使えます。</p> <h2 id="垂直的匿名性の重要性について">垂直的匿名性の重要性について</h2> <p>なぜ運営に対する匿名性がそれほど問題になるのでしょうか。</p> <p>メッセージングアプリでは、登録時に電話番号やメールアドレスを要求するものがあります。</p> <p>ユーザー名で連絡先を交換できるサービスでも、相手にこうした個人情報を見せずに済むだけで、登録の段階では運営に渡しています。 電話番号やメールアドレスは本人確認や他サービスの登録にも使われる、生活に密着した識別子です。 運営がこれを保持していれば、別々の文脈で集めた情報を同一人物に結びつける手がかりとして使えてしまいます。</p> <p>この紐付けは、広告で収益を上げるサービスでは特に意味を持ちます。利用者の行動を束ねてプロフィールを作るほど広告の精度が上がるので、複数の情報源を統合する動機がもともと働きます。電話番号やメールアドレスのような確実な識別子があれば、その統合は格段にやりやすくなります。メッセージの中身が暗号化されていても、誰がいつ誰と連絡したかというメタデータや、それを個人に結びつける識別子までは覆い隠せません。</p> <h2 id="メッセージングアプリの匿名性の比較">メッセージングアプリの匿名性の比較</h2> <p>ここまでの軸で、私が知る範囲の主要なアプリを並べてみます。</p> <p>暗号化の強さと、運営に対する匿名性は別物だという点に注目してください。暗号化の対応範囲やメタデータ収集、法執行機関への開示といった機能面の詳しい比較は<a href="https://codedchords.dev/blog/2024/10/modern-messaging-apps/">前回の記事</a>にまとめたので、ここでは匿名性の軸に絞ります。</p> <table><thead><tr><th>アプリ</th><th>登録時に必要な個人情報</th><th>運営に対する匿名性</th></tr></thead><tbody> <tr><td>LINE</td><td>電話番号</td><td>なし</td></tr> <tr><td>WhatsApp</td><td>電話番号</td><td>なし</td></tr> <tr><td>iMessage</td><td>電話番号または Apple Account</td><td>なし</td></tr> <tr><td>Signal</td><td>電話番号</td><td>なし</td></tr> <tr><td>Element / Matrix</td><td>なし（メールは任意）</td><td>サーバー次第</td></tr> <tr><td>Threema</td><td>なし</td><td>運営は満たすと主張</td></tr> <tr><td>Session</td><td>なし</td><td>高い</td></tr> <tr><td>SimpleX</td><td>なし</td><td>最も高い部類</td></tr> </tbody></table> <p>国内利用者の多いLINEは、もう少し細かく見ておきます。LINEのメッセージはLetter Sealingと呼ぶ技術で暗号化されていますが、50人を超えるグループトーク、グループ音声・ビデオ通話、LINEミーティング、アルバム、ノートは対象外で、通信路のTLS暗号化にとどまります。 この範囲は運営が技術的に中身へアクセスし得ます。そして匿名性の面では、登録に電話番号が必須なので運営に対する匿名性は持ちません。自治体などが市民の申請にLINEを使 うケースが増えていますし、たまに企業でも業務で使用しているケースを見かけます。セキュリティ意識の低さには驚きます。</p> <p>WhatsAppとiMessageも、垂直的匿名性はありません。メッセージの暗号化に対応していますが、登録にはWhatsAppが電話番号、iMessageが電話番号かApple Accountを必要とします。この時点で運営に対する匿名性は持ちません。 特にWhatsAppを運営するMeta社は広告を収入源としているので 、個人情報に関連したメタデータを収集してグループ内の他社と共有している可能性があります。 中身は守られても、誰といつ繋がったかまでは隠せません。</p> <!-- textlint-disable --> <aside data-position="right"> <p>ただし、Signalのメタ情報の電話番号、登録日、最終接続日のみ。</p> </aside> <!-- textlint-enable --> <p>暗号化に強いというイメージのSignalも垂直的匿名性はありません。 ユーザー名機能が2024年に加わり、電話番号を教えないまま連絡できるようになりました(水平的匿名性)が、 アカウントの作成には今も電話番号が必須です。 Signalを運営するのはSignal Foundationという非営利団体ですが、拠点はカリフォルニア州です。 つまり米国の管轄下なので、米国の捜査機関の要求があれば開示義務があります。</p> <p>ElementはMatrixというオープンなプロトコルの上に作られています。登録に必要なのは、選んだサーバー上のユーザー名とパスワードだけで、電話番号は要りません。メールアドレスはパスワード再設定用に任意で登録でき、サーバーによっては不正利用対策で求められることもあります。利用者はmatrix.orgのような公開サーバーを選んで登録するのが一般的で、自前でサーバーを立てることもできます。運営に対する匿名性は、結局どのサーバーを信頼するかに依存します。</p> <p>結局、垂直的匿名性を保持しているのは、Threema、Session、SimpleXのみです。</p> <h2 id="垂直的匿名性の代償">垂直的匿名性の代償</h2> <p>垂直的匿名性の仕組みと、その代わりに払う利便性のコストを見ておきます。</p> <p>Threemaは電話番号やメールアドレスを必要とせず、アカウントはランダムに割り当てられたThreema IDだけで機能します。 ユーザーはThreema IDを交換しメッセージの送受信を行ないます。 伝えるのはThreema IDのみなので、運営や相手に身元を明かさずに通信できます。 Threemaを使用していることすら秘匿する為にGoogle Playなどに依存せずThreemaを入手・購入できる手段も提供しています。 Threema IDはThreema社により管理されており、「IDが誰か」はThreema社に把握されませんが「いつ・どのIDと通信したか」は 論理的にはThreema社で把握可能です。ただし、Threema社は広告やトラッキングを行なわないというポリシーを持ち、収益源を買い切り課金に置いています。</p> <p>SimpleXは、利用者を識別する固定IDを一切持たない設計です。電話番号やユーザー名はもちろん、ランダムなIDすら使いません。仕組みは一方向のメッセージキューで、接続ごとに送信用と受信用の別々のキューを持ち、通常はそれぞれ別のサーバーを経由します。 サーバーから見えるのは不透明なキューへの孤立した配送だけで、送信者と受信者を結びつけられません。サーバー同士も通信せず、配送が済んだメッセージは保存しません。</p> <p>SessionはもともとSignalのフォークとして始まりました。電話番号やメールなどの個人データも不要で、ランダムなSession IDという66文字程度の公開鍵をアカウントのIDとして使います。メッセージは多数の有志ノードからなるオニオン型のネットワークを経由し、どのノードも送信者と受信者の両方を知ることはありません。運営は2024年10月に、暗号化技術への規制圧力を背景としてオーストラリアからスイスへ拠点を移し、現在はスイスのSession Technology Foundationが運営しています。コードはQuarkslabによる独立監査を受けています。SimpleXとの違いは、Sessionが永続的なアカウントのIDを持つ点です。</p> <p>これらの高い匿名性には、現実的な代償が伴います。</p> <ul> <li>いずれも、相手に直接リンクやQRコード、IDを渡さなければ会話を始められない</li> <li>従って、電話番号やユーザー名で気軽に相手を見つけることはできず、なんらかの方法で相手と直接これらの情報を交換する必要がある</li> </ul> <p>一番問題になるのは、相手も同じアプリを入れている必要があるところでしょう。 いずれもマイナーなアプリなので、匿名性のために連絡相手の数と手軽さを大きく差し出すことになります。 この利便性の低さは、日常使いを考えるうえで無視できないトレードオフです。</p> <h2 id="メッセージングアプリについて私の選択">メッセージングアプリについて私の選択</h2> <p>ここまで匿名性の強さで並べてきましたが、強ければ強いほどよい、という話ではありません。匿名性がどれだけ効くかは、相手があなたの身元を知っているかどうかで変わります。</p> <p>私は以下のように考えています。</p> <table><thead><tr><th>関係</th><th>説明</th></tr></thead><tbody> <tr><td>家族</td><td>当然対面しており、インストールするアプリも管理可能。機微なメッセージ交換もあり</td></tr> <tr><td>友人</td><td>対面しているが、アプリの管理は困難。機微なメッセージ交換は限定的</td></tr> <tr><td>他人</td><td>必ずしも対面していない。アプリの管理は不能。機微なメッセージはなし</td></tr> </tbody></table> <p>このように考えると、家族とは水平的匿名性は不要で垂直的匿名性が必要です。 前回の記事でも軽く触れましたが、私自身は家族との連絡用にThreemaを選んでいます。 SimpleXやSessionでもよいのですが、かなり以前からThreemaを使用しており、特に問題もないために使用を続けています。</p> <p>友人も同様です。知り合いなので水平的匿名性は不要ですが、垂直的匿名性は必要です。 しかし、現実的には垂直的匿名性を実現するために、先に記述した「代償」のため友人に対応するアプリを導入してもらうことは困難です。 そのため諦めて必要な場合は、友人にはメールかSMSでのコンタクトを依頼しています。暗号化、匿名性は放棄すると言うことです。 LINEなどを使っていると「じゃ、LINEで」と言われるので、私はLINEなどのアプリは使わずインストールさえしていません。</p> <p>ネットで知り合ったような他人については、どちらの匿名性も重要だと思います。 しかし、私は、匿名のままネットで知り合った相手とメッセージングアプリを使って通信するようなニーズはないので無視します。</p> <h2 id="まとめ">まとめ</h2> <p>LINE・WhatsApp・iMessage・Signalなど主要なメッセージングアプリは、暗号化や水平的匿名性は実装されていますが、 垂直的匿名性は担保されていません。LINEなど「なりすまし防止、復旧、法令遵守」などを理由に電話番号への紐付けを強化しています。 自治体などでLINEを使用するケースが多いようですが、あれは個人特定を行政として放棄しているとしか思えません。</p> <p>私にとって必要なのは垂直的匿名性です。メッセージの中身が暗号化されていても、運営に身元や「誰といつ通信したか」を握られては、プライバシーを守ったことになりません。 一方、相手に対しても名乗らない水平的匿名性は、私個人にはほとんど必要ありません。</p> <p>両方の匿名性を保てるのは、Threema・Session・SimpleXの3つです。</p> <!-- textlint-disable --> <aside data-position="right"> <p>米国報道機関ではSignalが使用されているケースが多いようです。</p> </aside> <!-- textlint-enable --> <p>両方の匿名性が必要なのは、相手や運営に身元を伏せたまま連絡したい場面だけです。 こうしたニーズは犯罪目的での使用を想起するかもしれませんが、内部告発や情報提供など正当な目的のためにも必要です。 米国では報道機関が情報提供の窓口としてメッセージングアプリの宛先などを公開しています。 日本ではこうした使い方はほとんど根づいておらず、全く遅れています。</p> <p>大切なのは、自分がどちらの匿名性を必要とするのかを見極めることです。垂直的匿名性はほとんどの人に効きますが、水平的匿名性まで求めるかは人によって大きく変わります。私自身は、身元を隠す必要のない家族との連絡に、垂直的匿名性を保ちつつ扱いやすいThreemaを使っています。</p> <h2 id="References">References</h2> <!-- textlint-disable --> <div class="references"> <ul> <li><a rel="external" href="https://threema.com/en/blog/anonymity-at-the-system-level-the-ultimate-privacy-protection">Threema</a>. "Anonymity at the System Level: The Ultimate Privacy Protection"</li> <li><a rel="external" href="https://threema.ch/en/blog/posts/news-alleged-weaknesses-statement">Threema</a>. "Statement on ETH Findings"</li> <li><a rel="external" href="https://breakingthe3ma.app/">ETH Zurich Applied Cryptography Group</a>. "Three Lessons from Threema"</li> <li><a rel="external" href="https://signal.org/blog/phone-number-privacy-usernames/">Signal</a>. "Keep your phone number private with Signal usernames"</li> <li><a rel="external" href="https://signalfoundation.org/en/">Signal Foundation</a>. "Signal Foundation"</li> <li><a rel="external" href="https://simplex.chat/docs/simplex.html">SimpleX Chat</a>. "How SimpleX works"</li> <li><a rel="external" href="https://getsession.org/blog/introducing-the-session-technology-foundation">Session</a>. "Introducing the Session Technology Foundation"</li> <li><a rel="external" href="https://getsession.org/session-code-audit">Session</a>. "Session code audit by Quarkslab"</li> <li><a rel="external" href="https://faq.whatsapp.com/820124435853543">WhatsApp Help Center</a>. "About end-to-end encryption"</li> <li><a rel="external" href="https://support.apple.com/guide/security/imessage-security-overview-secd9764312f/web">Apple Support</a>. "iMessage security overview"</li> <li><a rel="external" href="https://docs.element.io/latest/element-support/matrix-account-management/creating-a-matrix-account/">Element</a>. "Creating a Matrix Account"</li> <li><a rel="external" href="https://help.line.me/line/smartphone/categoryId/20010067/3/pc">LINE Help Center</a>. "Letter Sealing"</li> <li><a rel="external" href="https://www.lycorp.co.jp/ja/privacy-security/security/transparency/encryption-report/2025/">LINEヤフー</a>.「LINE暗号化状況レポート（2025年）」</li> </ul> </div> <!-- textlint-enable -->

Threema公式ブログに「システムレベルの匿名性」についての記事が公開されました。 日本ではLINEが主流で匿名性についての関心は薄いと思うので、その仕組みと重要性を解説してみました。

2026-06-08T00:00:00+00:00 2026-06-08T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2026/06/mufg-ppap/ <!-- textlint-disable --> <img src="https:&#x2F;&#x2F;codedchords.dev&#x2F;blog&#x2F;2026&#x2F;06&#x2F;mufg-ppap&#x2F;cover.webp?h=027a043bdcc9bd7b745e" alt="Cover" width="1536" height="864" loading="lazy" /><!-- textlint-enable --> <p>三菱UFJ銀行が2026年6月8日付で「<a rel="external" href="https://www.bk.mufg.jp/info/pdf/20260608_send_attachments.pdf">当行からの添付ファイル送信方法の変更に関するご案内</a>」を公表しました。 日本を代表するメガバンクがまだPPAPやっていたと衝撃を受けました。 内容を読んで考えさせられたので記録しておきます。</p> <h2 id="三菱UFJ銀行のアナウンス">三菱UFJ銀行のアナウンス</h2> <p>要点はシンプルです。</p> <p>同行は、お客さま側のセキュリティを確保するため、パスワード付き添付ファイルのメール送信を原則取り止めると発表しました。 2026年7月18日より順次、添付ファイルを送る際は専用のダウンロードサイトを利用する方式へ変更されます。</p> <p>理由として挙げられているのは次の2点です。 これまでの「メールでパスワード付きZIPファイルを送り、パスワードを別送する方法」、いわゆる <strong>PPAP</strong> は、ファイルが暗号化されているためメール受信時のマルウェアチェックが困難であること。 そして近年、パスワード付きZIPファイルを悪用したサイバー攻撃の事例が確認されていることです。</p> <p>新方式では、同行の役職員が添付ファイルを送る際、メール本文に専用ダウンロードサイトへアクセスするためのURLを記載します。 受け手はそのサイトにアクセスし、別送されるダウンロード専用のパスワードを使ってファイルを取得します。</p> <h2 id="PPAPの何が問題だったのか">PPAPの何が問題だったのか</h2> <p>PPAPの是非については、昨年「<a href="/blog/2025/06/aws-sns/">AWSからSMSにメッセージを送る</a>」という記事で一度整理しました。</p> <p>そのとき、機密文書をメールで送る手段を秘匿性と本人確認性の観点で並べて評価したのですが、結論は変わっていません。</p> <p>PPAP、つまり暗号化ファイルとパスワードを同じ経路で送る方法は、1通盗まれればすべて漏洩します。 パスワードを別メールにしても、同じメールインフラを流れる以上、傍受や誤送信のリスクは本質的には下がりません。 加えて、暗号化されたZIPはメールゲートウェイでウイルススキャンできないため、マルウェアの運び屋になりやすい。 三菱UFJ銀行が今回理由として挙げているのは、まさにこの最後の点です。</p> <p>ですから、PPAPをやめるという判断そのものは正しいと思います。 日本でも2020年に政府がPPAPの廃止方針を打ち出して以降の流れに沿っていますし、銀行という立場で旗を振る意味も小さくありません。</p> <h2 id="新方式は本当に安全になったのか">新方式は本当に安全になったのか</h2> <p>問題は、その置き換え先です。</p> <p>新方式は「メール本文にダウンロードサイトのURLを記載し、パスワードは別送する」というものでした。 マルウェアスキャンの観点では確かに前進しています。 ファイルが暗号化ZIPとしてメールに乗らなくなるので、受信側のゲートウェイで中身を検査できるようになるからです。</p> <p>しかし、フィッシング耐性という観点では、むしろ後退しかねません。</p> <p>ひとつは、銀行が自ら「メール本文のURLをクリックさせる」習慣を送信先に植え付けてしまう点です。 銀行はこれまでフィッシング対策として、「当行からのメールにURLは記載しません」「メール内のリンクは開かないでください」と顧客には教育してきたはずです。 メールの送信先は顧客ではないと思いますが、今回はその逆を習慣づけることになります。 なりすましメールに偽のダウンロードURLが貼られていても、利用者は見分けがつかなくなります。</p> <p>もうひとつは、「パスワードを別送する」という発想がPPAPのままという点です。 日ごろ支援しているコンサルテーション会社やITベンダーはちゃんと技術的に支援できなかったんでしょうか？</p> <p>URLとパスワードを両方メールで送るのであれば、構造的にはPPAPの暗号化ZIPをWebサイトに置き換えただけです。 同じ経路を流れる以上、傍受や誤送信による漏洩リスクは解決していません。 マルウェアの問題は片付いても、秘匿性の問題は手つかずなのです。</p> <p>整理すると、今回の変更は「マルウェアスキャン」という一点ではマシになる一方で、フィッシング耐性では弱点を抱え込む、惜しい設計だと感じます。</p> <h2 id="本来あるべき姿">本来あるべき姿</h2> <p><a href="/blog/2025/06/aws-sns">以前の記事</a>でも書きましたが、 現実的なのは認証付きのクラウドストレージで共有する方法でした。 受け手がログインして初めてファイルにアクセスできる仕組みなら、URLが単体で漏れても無効ですし、誰がいつアクセスしたかのログも残せます。 パスワードを別送する必要すらありません。</p> <p>メールの送付先は取引業者だと思いますから、銀行が共通の認証を払い出すのは困難です。 たとえばBoxやDropboxのようなクラウドストレージであれば、受け手は無料のアカウントを気軽に作れます。 銀行側が取引先ごとにアカウントを発行・運用しなくても、受け手がログインして初めてファイルにアクセスできる仕組みを成り立たせられるわけです。 URLが単体で漏れても無効ですし、誰がいつアクセスしたかのログも残ります。</p> <p>さらに言えば、この方式ならメールにリンクを書く必要すらありません。 ファイルを共有すれば、受け手にはクラウドストレージ側から「共有されました」という通知が届きます。 受け手は自分が信頼しているサービスにログインしてファイルを取りに行くだけです。 冒頭で挙げた、メール内URLをクリックさせる習慣づけという問題が、根本から消えてなくなるのです。</p> <h2 id="より根本的な解はないのか">より根本的な解はないのか</h2> <p>もっとも、銀行ともあろうものがファイルの受け渡しを外部のクラウドサービスに丸ごと預けるのも、それはそれで引っかかります。 委託先管理やデータの所在、サービスへの従属といった問題が新たに生じるからです。 だとすれば、現実的な落としどころは、銀行が認証付きの受け渡しポータルを自前で持つことでしょう。 インターネットバンキングという認証基盤と運用ノウハウをすでに備え、取引先の本人確認も日常的に行っている組織です。 Boxがやっていることを内製すればよいだけです。技術力と体力の両面で、銀行はそれができる立場にあります。</p> <p>では、もっと教科書的な根本解はないのか。 あります。受け手の証明書でメールそのものを暗号化・署名するS/MIME、いわゆるPKIです。 外部サービスやポータル、パスワードの別送といった仕組みが一切要らず、本人性と秘匿性をエンドツーエンドで担保できる、理屈のうえでは最も美しい解です。</p> <p>ところがPKIは、米国ですら普及しませんでした。 証明書の発行や管理が高コストで手作業が多く、ユーザーごと・端末ごとに鍵を入れて回る運用負荷に耐えられなかったためです。 そして決定的なのは、<strong>送り手と受け手の双方が対応していないと成り立たない</strong>という両側依存です。 暗号化して送るには、相手があらかじめ証明書を用意していなければなりません。 相手が対応していなければ、文字どおり意味がない。 この鶏と卵の構造ゆえに、誰も最初の一歩を踏み出せませんでした。 受け手に「アカウントを作ってログインする」という自己完結した操作しか求めないポータル方式に世界が流れたのは、そのためです。</p> <h2 id="それでもリーダーシップを期待したかった">それでもリーダーシップを期待したかった</h2> <p>ここで私が惜しいと思うのは、まさにこの一点です。 PKIが普及しなかった最大の理由が「最初の一歩を誰も踏み出せなかった」ことなら、その一歩を踏み出せる体力と影響力を持つ組織こそ、日本を代表するメガバンクのはずです。</p> <p>率先してS/MIMEを導入し、添付ファイルをやり取りするような主要な取引先には導入を促す。 場合によっては証明書発行の基盤を貸し出したり、運用を支援したりする。 そうやって両側依存の壁を、影響力のある側から崩していく。 そんなリーダーシップを見せてくれたら、日本全体のメール文化が一段前に進んだかもしれません。</p> <p>現実的な着地は認証付きポータルでよいと思います。 ただ、PPAPをやめるという入口が正しかっただけに、出口がもう一歩踏み込めなかったのは惜しい。 日本をリードする銀行のやることだからこそ、ここにこそリーダーシップを期待したかった、というのが私の正直な感想です。</p> <h2 id="References">References</h2> <!-- textlint-disable --> <div class="references"> <ul> <li><a rel="external" href="https://www.bk.mufg.jp/info/pdf/20260608_send_attachments.pdf">株式会社三菱UFJ銀行</a>. 「当行からの添付ファイル送信方法の変更に関するご案内」（2026年6月8日）</li> <li><a href="/blog/2025/06/aws-sns/">Coded Chords</a>. 「AWSからSMSにメッセージを送る」（2025年6月9日）</li> </ul> </div> <!-- textlint-enable -->

日本を代表する銀行がPPAPの廃止を発表しました。マルウェア対策としては正しい一歩ですが、新しい受け渡し方法には見過ごせない落とし穴が残っています。

2026-03-23T00:00:00+00:00 2026-03-23T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2026/03/cloudflare-free-security/ <!-- textlint-disable --> <img src="https:&#x2F;&#x2F;codedchords.dev&#x2F;blog&#x2F;2026&#x2F;03&#x2F;cloudflare-free-security&#x2F;cover.webp?h=9bfc915254c8cd5bf47d" alt="Cover" width="1792" height="1024" loading="lazy" /><!-- textlint-enable --> <span id="continue-reading"></span><h2 id="公開翌日に何が起きたか">公開翌日に何が起きたか</h2> <p>先日の記事で紹介した生成AIを使った<a rel="external" href="https://ask.codedchords.dev">Ask</a> ページを公開した翌日、CloudflareのObservabilityを確認したところ、攻撃と思われるリクエストが並んでいました。</p> <ul> <li><code>GET /.env</code> — 環境変数ファイルの探索</li> <li><code>/checkout</code>, <code>/plans</code>, <code>/signup</code> — SaaS系パスの総当たり</li> <li><code>/wp-login</code>, <code>/wp-admin</code>, <code>/xmlrpc.php</code> — WordPress管理画面の探索</li> <li><code>/api/v1/stripe/config.js</code>, <code>/api/v2/payment/keys.js</code> — 決済APIの設定ファイル探索（Stripeはオンライン決済プラットフォーム）</li> <li><code>config.php</code>, <code>/api/system/info</code> — サーバー情報の収集</li> </ul> <p>主にWordPressなどのCMSやStripeなどの決済サービスを狙ったスキャンです。静的サイト＋Workerという構成なのでそんなサービスは乗せていないのですが。公開されているエンドポイントに対してよく狙われる既知のパスを片っ端から叩いているのでしょう。</p> <p>実害はありませんが、放置するのも気持ちが悪いですし、Workers AIのNeuronsを無駄に消費されるのは避けたいところです。Cloudflareの無料プランのセキュリティ機能で対策しました。</p> <h2 id="対策1:_Bot_Fight_Mode">対策1: Bot Fight Mode</h2> <p>最も手軽な対策です。Cloudflareダッシュボードの <strong>Security &gt; Bots</strong> から、ワンクリックで有効化できます。</p> <p>Bot Fight ModeはCloudflareが持つボットの行動パターンデータベースを使い、自動化されたアクセスを検出して計算コストの高いチャレンジを返します。検索エンジンのクローラーなど検証済みの正当なボットは通過させる仕組みです。</p> <p>設定はON/OFFだけで、細かなチューニングは有料プラン（Super Bot Fight Mode）の機能になります。それでも、汎用的なスキャンボットの大半はこれで弾けます。</p> <p>注意点として、Bot Fight Modeは外部サービスからのWebhookやRSSリーダーのフィード取得など、正当な自動アクセスもブロックする場合があります。無料プランではWAFルールによるバイパス（Skip）ができないため、これらのサービスに影響が出た場合はBot Fight Mode自体を無効にする必要があります。</p> <h2 id="対策2:_WAF_カスタムルール">対策2: WAF カスタムルール</h2> <p>Bot Fight Modeをすり抜けるアクセスに対しては、WAF（Web Application Firewall）のカスタムルールで対処します。無料プランでは5つまでルールを作成できます。</p> <h3 id="ルール1:_許可パスの制限（ホワイトリスト）">ルール1: 許可パスの制限（ホワイトリスト）</h3> <p>最も効果が高いルールを最優先に配置します。ask.codedchords.devは <code>/</code>（フロントエンド）と <code>/api/</code>（Workers API）しか使わないので、それ以外を全てブロックします。</p> <pre class="giallo z-code"><code data-lang="plain" data-name="Expression"><span class="giallo-l"><span>(http.host eq &quot;ask.codedchords.dev&quot;)</span></span> <span class="giallo-l"><span>and not (http.request.uri.path eq &quot;/&quot; or http.request.uri.path contains &quot;/api/&quot;)</span></span></code></pre> <p>Actionは <strong>Block</strong>、Place atは <strong>First</strong> に設定します。</p> <p>「正当なパスだけを許可する」ホワイトリスト方式なので、攻撃者がどんなパスを試してもすり抜けられません。ただし、対象サイトの構成を把握している必要があります。新しいパスを追加した際にルールの更新を忘れると自分自身のコンテンツがブロックされるため、サイト構成を変更したらルールも見直してください。</p> <h3 id="ルール2:_スキャンパスの遮断（ブラックリスト）">ルール2: スキャンパスの遮断（ブラックリスト）</h3> <p>ルール1はaskサブドメイン限定なので、ドメイン全体に適用する汎用ルールも設定します。WordPressやphpMyAdminなど、よく狙われるパスへのアクセスを一括でブロックします。</p> <p><strong>Security &gt; Security rules &gt; Create rule</strong> から、以下のExpressionを設定します。</p> <pre class="giallo z-code"><code data-lang="plain" data-name="Expression"><span class="giallo-l"><span>(http.request.uri.path contains &quot;.env&quot;)</span></span> <span class="giallo-l"><span>or (http.request.uri.path contains &quot;wp-login&quot;)</span></span> <span class="giallo-l"><span>or (http.request.uri.path contains &quot;wp-admin&quot;)</span></span> <span class="giallo-l"><span>or (http.request.uri.path contains &quot;xmlrpc.php&quot;)</span></span> <span class="giallo-l"><span>or (http.request.uri.path contains &quot;phpmyadmin&quot;)</span></span> <span class="giallo-l"><span>or (http.request.uri.path contains &quot;wp-content&quot;)</span></span> <span class="giallo-l"><span>or (http.request.uri.path contains &quot;wp-includes&quot;)</span></span></code></pre> <p>Actionは <strong>Block</strong> です。</p> <p>このルールはサイトの構成に依存しないため、Cloudflareで管理しているドメイン全体に適用できます。WordPressを使っていないサイトであれば、デメリットはありません。</p> <h2 id="対策3:_Rate_Limiting">対策3: Rate Limiting</h2> <p>Bot Fight ModeとWAFルールを通過したリクエストに対する最後の砦です。同一IPからの過剰なリクエストを制限します。</p> <p><strong>Security &gt; Security rules &gt; Rate limiting rules</strong> から設定します。</p> <table><thead><tr><th>項目</th><th>設定値</th></tr></thead><tbody> <tr><td>対象</td><td><code>http.host eq "ask.codedchords.dev"</code></td></tr> <tr><td>判定基準</td><td>IP</td></tr> <tr><td>レート</td><td>10リクエスト / 10秒</td></tr> <tr><td>Action</td><td>Block（10秒間）</td></tr> </tbody></table> <p>無料プランではRate Limitingルールは1つまで、ブロック期間は最大10秒という制約があります。大規模な攻撃には有料プランのRate Limiting（より長いブロック期間、より多くのルール）が必要ですが、スキャンボット対策としては十分です。上記の設定値は一例です。ページ内のリソース数や想定されるアクセスパターンに応じて調整してください。</p> <p>なお、今回はWorkers側にも <code>/api/ask</code> エンドポイントに対して同一IP 60秒間10リクエストの制限を入れています。CloudflareのRate Limitingはインフラ層での粗いフィルタリング、Workers側はアプリケーション層での細かな制御という役割分担です。</p> <h2 id="3層防御の全体像">3層防御の全体像</h2> <p>設定した対策を整理します。</p> <table><thead><tr><th>レイヤー</th><th>対策</th><th>役割</th></tr></thead><tbody> <tr><td>第1層</td><td>Bot Fight Mode</td><td>既知のボットパターンを自動検出</td></tr> <tr><td>第2層</td><td>WAF カスタムルール</td><td>不正なパス・不要なパスを遮断</td></tr> <tr><td>第3層</td><td>Rate Limiting</td><td>過剰なリクエストを制限</td></tr> </tbody></table> <p>いずれもCloudflareの無料プランで利用でき、設定はダッシュボードからの操作だけで完結します。</p> <h2 id="まとめ">まとめ</h2> <p>これらの設定を適用した直後から、Observability上でスキャン系のリクエストがブロックされていることを確認できました。Workers AIのNeuronsが無駄に消費されることもなくなっています。</p> <p>個人サイトであっても、公開すればスキャンボットは来ます。「小規模だから狙われない」ということはありません。ボットは規模を問わず、見つけたエンドポイントを片っ端から叩きます。</p> <p>Cloudflareを使っているなら、無料プランの範囲でもBot Fight Mode、WAFカスタムルール、Rate Limitingの3つを設定するだけで、大半の自動化されたスキャンは防げます。設定にかかる時間は10分程度です。特にWorkers AIやAPIエンドポイントを公開している場合は、不要なリクエストによるリソース消費を防ぐためにも早めの対策をおすすめします。</p> <h2 id="References">References</h2> <!-- textlint-disable --> <div class="references"> <ul> <li><a rel="external" href="https://developers.cloudflare.com/bots/get-started/free/">Cloudflare</a>. "Bot Fight Mode"</li> <li><a rel="external" href="https://developers.cloudflare.com/waf/custom-rules/">Cloudflare</a>. "Custom rules"</li> <li><a rel="external" href="https://developers.cloudflare.com/waf/rate-limiting-rules/">Cloudflare</a>. "Rate limiting rules"</li> </ul> </div> <!-- textlint-enable -->

個人ブログにAI Chat機能を追加した翌日、スキャンボットの集中アクセスを確認しました。Cloudflareの無料プランだけで実施できるBot Fight Mode、WAFカスタムルール、Rate Limitingの3つの対策を紹介します。

2026-03-03T00:00:00+00:00 2026-03-03T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2026/03/spf-lookup-limit-risk/ <!-- textlint-disable --> <p><img src="https:&#x2F;&#x2F;codedchords.dev&#x2F;blog&#x2F;2026&#x2F;03&#x2F;spf-lookup-limit-risk&#x2F;cover.webp?h=bc1f2cf07dfaabe490a7" alt="Cover" width="1792" height="1024" loading="lazy" /> <div class="admonition info"> <div class="admonition-icon admonition-icon-info"></div> <div class="admonition-content"> <strong class="admonition-title">転載元</strong> <p>この記事は <a rel="external" href="https://zenn.dev/yostos/articles/spf-lookup-limit-risk">Zenn</a> に掲載した記事の転載です。</p> </div> </div> </p> <!-- textlint-enable --> <details> <summary>Table of Contents</summary> <!-- toc --> </details> <h2 id="はじめに">はじめに</h2> <p>「ある日突然、自組織からのメールが取引先に届かなくなった」——そんな事態が、メール配信サービスを複数利用している組織で実際に起こり得ます。原因は、SPF（Sender Policy Framework）のDNSルックアップ上限です。</p> <p>外部のメール配信サービスを導入するたびにSPFレコードへ <code>include</code> を追加していくと、気づかないうちに上限へ近づきます。しかも、上限超過のトリガーは自組織の操作ではなく、外部サービス側の設定変更かもしれません。</p> <p>本記事では、SPFのDNSルックアップ上限の仕組みを解説し、上限超過のリスクと対策を整理します。</p> <h2 id="SPFの仕組みとDNSルックアップ上限">SPFの仕組みとDNSルックアップ上限</h2> <p>SPFは、メールの送信元ドメインが「どのサーバーからの送信を許可しているか」をDNSのTXTレコードで宣言する仕組みです。受信側メールサーバーは、送信元IPアドレスがSPFレコードに含まれているかを検証し、正当な送信元かどうかを判断します。</p> <p>SPFレコードの例を示します。</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>v=spf1 ip4:192.0.2.0/24 include:spf.example.com ~all</span></span></code></pre> <p>この例では、<code>192.0.2.0/24</code> のIPレンジからの送信と、<code>spf.example.com</code> が許可する送信元を正当とみなします。</p> <p>SPFの検証は受信側メールサーバーで行われます。メールを受け取ったサーバーが送信元ドメインのSPFレコードをDNSに問い合わせ、送信元IPが許可されているかを確認します。この検証過程でDNSルックアップが発生しますが、RFC 7208（Section 4.6.4）により、1回のSPF検証で実行できるDNSルックアップは最大10回と制限されています。この制限は、SPF検証によるDNSサーバーへの負荷を防ぐために設けられたものです。</p> <p>すべてのメカニズムがDNSルックアップを消費するわけではありません。消費するメカニズムとしないメカニズムを表にまとめます。</p> <table><thead><tr><th>メカニズム / 修飾子</th><th>DNSルックアップ</th></tr></thead><tbody> <tr><td><code>ip4</code> / <code>ip6</code></td><td>0回（IP直接指定のためDNS不要）</td></tr> <tr><td><code>a</code></td><td>1回</td></tr> <tr><td><code>mx</code></td><td>1回（＋MXレコードが指すAレコードの解決）</td></tr> <tr><td><code>include</code></td><td>1回 ＋ 参照先のSPFレコード内のルックアップ</td></tr> <tr><td><code>redirect</code></td><td>1回</td></tr> <tr><td><code>exists</code></td><td>1回</td></tr> </tbody></table> <p>重要なのは <code>include</code> の挙動です。<code>include</code> は参照先のSPFレコードをさらに評価するため、参照先に <code>include</code> や <code>a</code> が含まれていれば、それらも合算されます。つまり、1つの <code>include</code> が実際には複数回のルックアップを消費する場合があります。</p> <h2 id="includeの入れ子で上限に近づく実例">includeの入れ子で上限に近づく実例</h2> <p>架空の組織 <code>example.or.jp</code> を例に考えます。この組織では業務メールに加えて、メールマガジン配信に3つの外部サービスを利用しています。SPFレコードは以下のようになっています。</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>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</span></span></code></pre> <p>各エントリのDNSルックアップ数を確認します。</p> <table><thead><tr><th>エントリ</th><th>DNSルックアップ</th></tr></thead><tbody> <tr><td><code>ip4:192.0.2.0/29</code></td><td>0回（IP直接指定）</td></tr> <tr><td><code>ip4:198.51.100.1</code></td><td>0回（IP直接指定）</td></tr> <tr><td><code>include:spf.mail-a.example</code></td><td>1回</td></tr> <tr><td><code>include:spf.mail-b.example</code></td><td>1回 ＋ 内部で3回 = 4回</td></tr> <tr><td><code>include:spf.mail-c.example</code></td><td>1回</td></tr> <tr><td><code>include:spf.bizmail.example</code></td><td>1回</td></tr> <tr><td><strong>合計</strong></td><td><strong>7回 / 上限10回</strong></td></tr> </tbody></table> <p>一見すると余裕がありそうですが、問題は <code>spf.mail-b.example</code> の内部構造です。このSPFレコードは以下のようになっています。</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>v=spf1 exists:%{i}.spf.mail-b1.example exists:%{i}.spf.mail-b2.example include:spf.mail-b3.example ~all</span></span></code></pre> <p><code>include</code> 1つで4回のルックアップを消費しています。そして、この内訳は外部サービス側の設定に依存しています。</p> <p>ここに大きなリスクがあります。外部サービスがインフラ変更に伴いSPFレコードへ <code>include</code> や <code>a</code> を追加すれば、自組織が何も変更していなくてもルックアップ数が増加します。たとえば <code>spf.mail-b.example</code> が内部で1つ <code>include</code> を追加するだけで、合計は8回になり、上限までわずか2回です。さらに別のサービスも同様の変更をすれば、上限を超えてしまいます。</p> <h2 id="上限を超えるとどうなるか">上限を超えるとどうなるか</h2> <p>SPFのルックアップ数が10回を超えると、SPFの検証結果は <code>permerror</code>（恒久的エラー）になります。これは「SPFレコードが壊れている」とみなされる状態です。</p> <p><code>permerror</code> が発生すると、受信側メールサーバーの設定に応じて以下のいずれかが起こります。</p> <ul> <li>メールが拒否される（バウンス）</li> <li>迷惑メールフォルダに振り分けられる</li> <li>DMARCのSPF判定がfailとなり、DMARCポリシー次第でメールが拒否される</li> </ul> <p>特に厄介なのは、この問題が自組織側からは気づきにくい点です。送信自体は正常に行われ、送信者にはエラーが返らない場合もあります。受信側で静かにスパム判定されるため、「最近メールの返信が来ない」「メルマガの開封率が急落した」といった間接的な兆候で初めて気づくことになります。</p> <h2 id="自分のドメインのルックアップ数を確認する方法">自分のドメインのルックアップ数を確認する方法</h2> <p><code>dig</code> コマンドでSPFレコードの内容を確認できます。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">dig</span><span class="z-string"> +short TXT example.or.jp</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> grep</span><span class="z-string"> spf</span></span></code></pre> <p>表示されたSPFレコードに含まれる <code>include</code> 先も再帰的に確認する必要があります。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">dig</span><span class="z-string"> +short TXT spf.mail-b.example</span></span></code></pre> <p>手動での再帰的な確認は手間がかかるため、オンラインツールの利用も有効です。</p> <ul> <li><strong>MXToolbox SPF Record Lookup</strong> — SPFレコードの内容とDNSルックアップ数を自動計算してくれる</li> <li><strong>dmarcian SPF Surveyor</strong> — SPFレコードの構造をツリー表示で可視化できる</li> </ul> <p>これらのツールにドメイン名を入力するだけで、現在のルックアップ数と上限までの余裕を確認できます。定期的にチェックしておくことをお勧めします。</p> <h2 id="対策">対策</h2> <p>SPFルックアップ上限の問題に対して、短期的な対策と中長期的な対策があります。</p> <p>まず短期的な対策として、メール送信経路を棚卸しします。SPFレコードに登録されている <code>include</code> やIPアドレスが、現在も使われているかを確認します。利用を終了したサービスの <code>include</code> が残っていると、ルックアップ数を無駄に消費するだけでなく、そのサービスのIPレンジが自ドメインの正当な送信元として許可されたままになります。これはなりすましに悪用されるリスクでもあります。</p> <p>次に、メール配信サービスの統合を検討します。メルマガ配信に複数のサービスを併用している場合、1つに統合すれば <code>include</code> の数を減らせます。配信実績の分析も一元化でき、コスト管理も簡素化されます。</p> <p>これらの根本対策とは別に、技術的な回避策も存在します<sup class="footnote-reference" id="fr-spf-workaround-1"><a href="#fn-spf-workaround">1</a></sup>。ただし運用上の注意点があるため、まずは送信経路の整理を優先すべきです。</p> <p>最後に、中長期的な対策としてDMARCポリシーの段階的強化があります。DMARCはSPFとDKIMの認証結果に基づいて、認証失敗時のメール処理方針を宣言する仕組みです。ポリシーは以下の順で強化します。</p> <ol> <li><code>p=none</code>（監視モード）でDMARCレポートを収集し、全送信経路の認証状況を把握する</li> <li>全経路でSPF・DKIMがpassすることを確認したうえで <code>p=quarantine</code>（隔離）に移行する</li> <li>一定期間の監視後、問題がなければ <code>p=reject</code>（拒否）に移行する</li> </ol> <p>送信経路が整理されていれば、この移行は技術的には難しくありません。逆に、送信経路が乱立したままでは各経路の認証状況を把握すること自体が困難であり、DMARC強化は事実上不可能です。</p> <h2 id="まとめ">まとめ</h2> <p>SPFのDNSルックアップ上限10回は、メール配信サービスを複数利用する組織にとって見落とされがちなリスクです。外部サービスの <code>include</code> は入れ子構造でルックアップ数が膨らみ、しかも外部サービス側の変更で自組織のルックアップ数が増加するという、制御しにくい特性があります。</p> <p>まずは自分のドメインの現在のルックアップ数を確認してみてください。上限に近づいている場合は、不要な <code>include</code> の削除やサービスの統合を検討し、DMARCポリシーの強化と合わせてメール配信の信頼性を確保していくことが重要です。</p> <section class="footnotes"> <ol class="footnotes-list"> <li id="fn-spf-workaround"> <p>技術的な回避策としてSPF MacroとSPF flatteningがあります。SPF Macroは <code>exists</code> メカニズムと変数を組み合わせてルックアップ数を抑える手法です。SPF flatteningは <code>include</code> 先のIPアドレスを直接 <code>ip4</code> / <code>ip6</code> で記述してルックアップを削減する手法です。ただしflatteningは参照先のIPが変更されたときに追従が必要なため、自動化ツールなしでの運用は推奨しません。 <a href="#fr-spf-workaround-1">↩</a></p> </li> </ol> </section>

SPFにはDNSルックアップ上限10回の制約があり、外部メール配信サービスのincludeが入れ子で膨らむと意図せず超過するリスクがあります。上限超過の仕組みと確認方法、対策を解説します。

2026-02-20T00:00:00+00:00 2026-02-20T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2026/02/cloudflare-benefits/ <!-- textlint-disable --> <img src="https:&#x2F;&#x2F;codedchords.dev&#x2F;blog&#x2F;2026&#x2F;02&#x2F;cloudflare-benefits&#x2F;cover.webp?h=a800061cf7b938db4dbe" alt="Cover" width="1792" height="1024" loading="lazy" /><h2 id="TL;DR">TL;DR</h2> <p>Cloudflareのアドバンテージは、次の3点です。</p> <ul> <li>無料プランだけでWAF・ボット対策まで揃う、セキュリティの充実度</li> <li>DNS統合だからこそ、煩雑でリスクの高い設定をワンクリックで実現</li> <li>AIクローラー対策やページ先読みなど、最新トレンドへの即応</li> </ul> <hr /> <p>つい3日前に<a href="https://codedchords.dev/blog/2026/02/migration-to-cloudflare/">Cloudflareへ移転した</a>ばかりです。構成はシンプルで、Cloudflareでドメインを取得し、GitHubリポジトリと連携して静的コンテンツをCloudflare Pages<sup class="footnote-reference" id="fr-2-1"><a href="#fn-2">1</a></sup>へデプロイしています。この構成だけでも思いの外多くの恩恵が得られたので、まとめておきます。</p> <h2 id="Cloudflareでの設定">Cloudflareでの設定</h2> <p>Cloudflareのダッシュボードで有効にした機能を、カテゴリごとに紹介します。いずれも無料プランで利用でき、ほとんどがトグルひとつで有効にできるものです。なお、本記事の機能名やβ表記は2026年2月時点のCloudflare管理画面のUIに基づいています。</p> <h3 id="Edge_Certificates">Edge Certificates</h3> <p>Cloudflareが発行・管理するSSL/TLS証明書と、HTTPS通信に関する設定です。</p> <table><thead><tr><th>項目</th><th>説明</th></tr></thead><tbody> <tr><td>Always Use HTTPS</td><td>HTTP でアクセスが来た場合に自動的に HTTPS へ301リダイレクトしてくれるので、暗号化されていない通信を防げる。</td></tr> <tr><td>HSTS</td><td><code>.dev</code> ドメイン<sup class="footnote-reference" id="fr-1-1"><a href="#fn-1">2</a></sup>を使用しているので私の場合あまり恩恵がないが、ブラウザレベルでHTTPSが強制できる。</td></tr> <tr><td>Minimum TLS Version</td><td>サイトに接続する際に許可するTLSプロトコルの最低バージョンの指定。TLS 1.0 と 1.1 は既知の脆弱性があるので、私はTLS1.2にしている。</td></tr> <tr><td>Opportunistic Encryption</td><td>HTTPでアクセスしてきたブラウザに対して「暗号化接続も利用可能ですよ」と通知する仕組み。<code>.dev</code> の場合、HTTPアクセスが発生しないので実質的に意味がない。</td></tr> <tr><td>TLS 1.3</td><td>Minimum TLS Version を 1.2 に設定し、この TLS 1.3 をオンにしておけば、「最低 1.2、対応していれば 1.3 を使う」という構成になる。</td></tr> <tr><td>Automatic HTTPS Rewrites</td><td><code>http://</code> をCloudflare が自動的に <code>https://</code> に書き換えて「混在コンテンツ（mixed content）」の問題を防いでくれる。</td></tr> <tr><td>Certificate Transparency Monitoring</td><td>自分が意図していない証明書が第三者によって発行された場合（ドメインの不正利用や乗っ取りの兆候）通知してくれる</td></tr> </tbody></table> <h3 id="Security">Security</h3> <p>ボット対策、DDoS防御、WAFなど、サイトを外部の脅威から守るための設定です。</p> <table><thead><tr><th>項目</th><th>説明</th></tr></thead><tbody> <tr><td>AI Labyrinth</td><td>まだβ機能だが、robots.txt 等のクロールルールを無視して勝手にサイトをスクレイピングするボットに対して偽コンテンツを読ませて学習データを汚染させるという「ハニーポット」的な機能</td></tr> <tr><td>Block AI bots</td><td>AI学習用クローラーをブロックする機能</td></tr> <tr><td>Bot fight mode</td><td>悪意のあるボット（スパム、クレデンシャルスタッフィング、DDoS等）を検知すると、JavaScriptチャレンジを出して人間かどうかを確認する</td></tr> <tr><td>Browser Integrity Check</td><td>訪問者のHTTPヘッダーを検査して、不正なUser-Agentやスパムボットによく見られる異常なヘッダーパターンを検出し、脅威が見つかった場合はブロックページを表示する。</td></tr> <tr><td>Challenge passage</td><td>チャレンジ（CAPTCHA等）をクリアした訪問者が、再度チャレンジを求められるまでの有効時間</td></tr> <tr><td>HTTP DDoS attack protection</td><td>HTTPレイヤーのDDoS攻撃を自動検知・緩和する。無料プランでもCloudflare Free Managed Ruleset（基本的なWAFルール）が付属する</td></tr> <tr><td>Manage your robots.txt</td><td>Cloudflare が robots.txt を自動管理するβ機能。Content Signals Policyを選択すると、コンテンツの利用意図を用途別（検索・AI入力・AI学習）に宣言できる</td></tr> <tr><td>Network-layer DDoS attack protection</td><td>DDoS保護</td></tr> </tbody></table> <h3 id="DNS">DNS</h3> <p>DNS応答の改ざん防止やメールのなりすまし対策など、ドメインの信頼性を高める設定です。</p> <table><thead><tr><th>項目</th><th>説明</th></tr></thead><tbody> <tr><td>DNSSEC</td><td>DNSレスポンスに暗号署名を付与して、DNS応答の偽造（DNSキャッシュポイズニング等）を防ぐ</td></tr> <tr><td>Email Security</td><td>有効にしてDMARCの設定。メール送信の予定はないので、SPFは"v=spf1 -all"で設定。DMARCは"v=DMARC1; p=reject"</td></tr> </tbody></table> <h3 id="Speed">Speed</h3> <p>通信プロトコルの最適化やページ先読みなど、サイト表示を高速化するための設定です。</p> <table><thead><tr><th>項目</th><th>説明</th></tr></thead><tbody> <tr><td>Web analytics using real user measurement (RUM)</td><td>実際の訪問者のブラウザからパフォーマンスデータ（ページ読み込み時間など）を収集する。Cookieを使わないプライバシー重視の計測方式</td></tr> <tr><td>Speed Brain</td><td>ユーザーがリンクをクリックする前にページを先読みする機能。Speculation Rules API を使い、体感的なページ遷移が高速になる</td></tr> <tr><td>HTTP/2</td><td>HTTP/1.1の後継。1つの接続で複数リクエストを並行処理（多重化）でき、ページ読み込みが高速になる</td></tr> <tr><td>HTTP/3</td><td>HTTP/2の次世代版。TCPの代わりにQUICプロトコルを使い、接続確立が高速でパケットロス時の劣化も少ない</td></tr> <tr><td>HTTP/2 to Origin</td><td>Cloudflareとオリジンサーバー間の通信にもHTTP/2を使う設定</td></tr> <tr><td>0-RTT Connection Resumption</td><td>TLS 1.3で接続済みのクライアントが再訪問時にハンドシェイクの最初の往復を省略でき、再訪問者の初回リクエストが速くなる</td></tr> </tbody></table> <h2 id="以前のプラットフォームとの比較">以前のプラットフォームとの比較</h2> <p>昨年までAmazon Amplify、先月までGitHub Pagesで運用していました。 上記で挙げたCloudflareの機能が、それぞれの環境ではどうだったかを比較してみます。特にセキュリティ列の差に注目してください。</p> <ul> <li>○: 標準/無料で利用可能</li> <li>△: 別途設定や追加費用で対応可能</li> <li>×: 非対応</li> <li>−: 該当なし</li> </ul> <table><thead><tr><th>機能</th><th style="text-align: center">Amplify + CloudFront</th><th style="text-align: center">GitHub Pages</th><th>コメント</th></tr></thead><tbody> <tr><td>Always Use HTTPS</td><td style="text-align: center">○</td><td style="text-align: center">○</td><td></td></tr> <tr><td>HSTS</td><td style="text-align: center">△（手動設定）</td><td style="text-align: center">○</td><td>AWSだけ手動設定の手間がかかる</td></tr> <tr><td>Minimum TLS Version</td><td style="text-align: center">○</td><td style="text-align: center">×</td><td>GitHub Pagesは古いTLSを拒否できず、セキュリティポリシーを徹底しにくい</td></tr> <tr><td>Opportunistic Encryption</td><td style="text-align: center">×</td><td style="text-align: center">×</td><td>HTTP接続の暗号化への誘導は他のサービスでは提供されていない</td></tr> <tr><td>TLS 1.3</td><td style="text-align: center">○</td><td style="text-align: center">○</td><td></td></tr> <tr><td>Automatic HTTPS Rewrites</td><td style="text-align: center">×</td><td style="text-align: center">×</td><td>他では混在コンテンツを自分で探して直す必要がある</td></tr> <tr><td>Certificate Transparency Monitoring</td><td style="text-align: center">△（ACMの一部）</td><td style="text-align: center">×</td><td>不正な証明書発行の早期発見に差が出る</td></tr> <tr><td>AI Labyrinth</td><td style="text-align: center">×</td><td style="text-align: center">×</td><td>ワンクリックでAIスクレイピングに対抗できる機能は他にない</td></tr> <tr><td>Block AI bots</td><td style="text-align: center">△（WAFルールで対応）</td><td style="text-align: center">×</td><td>AWSは自前でルールを書く手間とWAF費用がかかる</td></tr> <tr><td>Bot fight mode</td><td style="text-align: center">△（WAF Bot Control有料）</td><td style="text-align: center">×</td><td>AWSで同等機能を得るにはBot Control（月額$10〜＋リクエスト従量課金）が必要</td></tr> <tr><td>Browser Integrity Check</td><td style="text-align: center">△（WAFで部分的）</td><td style="text-align: center">×</td><td>AWSでは同等ルールの自作が必要で、運用負荷が高い</td></tr> <tr><td>Challenge passage</td><td style="text-align: center">△（WAF）</td><td style="text-align: center">×</td><td>Cloudflareはチャレンジの有効期間まで細かく制御できる</td></tr> <tr><td>HTTP DDoS attack protection</td><td style="text-align: center">△（WAFは有料）</td><td style="text-align: center">×</td><td>無料でWAFまで付くのはCloudflareの大きな強み</td></tr> <tr><td>Manage your robots.txt</td><td style="text-align: center">×</td><td style="text-align: center">×</td><td>増え続けるAIクローラーへの対応を自動化できる機能は他にない</td></tr> <tr><td>Network-layer DDoS attack protection</td><td style="text-align: center">○（Shield Standard）</td><td style="text-align: center">○</td><td></td></tr> <tr><td>DNSSEC</td><td style="text-align: center">○（Route 53）</td><td style="text-align: center">△（DNS providerに依存）</td><td>Cloudflareはワンクリック、DNS一体管理なので設定が圧倒的に楽</td></tr> <tr><td>Email Security</td><td style="text-align: center">○（Route 53）</td><td style="text-align: center">△（DNS providerに依存）</td><td>同上。DNS管理とセットなのでSPF/DMARCの設定も迷わない</td></tr> <tr><td>Web analytics (RUM)</td><td style="text-align: center">△（CloudWatch RUM有料）</td><td style="text-align: center">×</td><td>Cloudflareは追加費用なしでCookie不要の計測が使える</td></tr> <tr><td>Speed Brain</td><td style="text-align: center">×</td><td style="text-align: center">×</td><td>ページ先読みによる体感速度向上は他のサービスでは提供されていない</td></tr> <tr><td>HTTP/2</td><td style="text-align: center">○</td><td style="text-align: center">○</td><td></td></tr> <tr><td>HTTP/3</td><td style="text-align: center">○</td><td style="text-align: center">×</td><td>GitHub Pagesは2026年2月時点でHTTP/3未サポート</td></tr> <tr><td>HTTP/2 to Origin</td><td style="text-align: center">○</td><td style="text-align: center">−</td><td>オリジンサーバーがある構成でのみ意味がある</td></tr> <tr><td>0-RTT</td><td style="text-align: center">×</td><td style="text-align: center">×</td><td>再訪問時の体感速度に差が出る。他のサービスでは無料で提供されていない</td></tr> </tbody></table> <h2 id="AI時代のコンテンツ保護">AI時代のコンテンツ保護</h2> <p>Cloudflareの無料プランには、AIクローラーに対応する機能が複数用意されています。これらは独立した機能ですが、組み合わせると多層的な防御になります。</p> <table><thead><tr><th>機能</th><th>レイヤー</th><th>役割</th></tr></thead><tbody> <tr><td>Content Signals Policy</td><td>意思表示</td><td>robots.txt内でコンテンツの用途別に許可/拒否を宣言する。強制力はなく、善意あるクローラーへの「お願い」</td></tr> <tr><td>Block AI bots</td><td>技術的ブロック</td><td>Cloudflareが「AI学習用」と分類するクローラーをWAFレベルでブロックする。検索エンジンやAIアシスタントは対象外</td></tr> <tr><td>AI Labyrinth</td><td>欺瞞防御</td><td>ブロックを無視するクローラーに偽コンテンツを読ませ、学習データを汚染させるハニーポット</td></tr> </tbody></table> <p>ポイントは、Content Signals PolicyとBlock AI botsの役割分担です。Content Signals Policyでは <code>search=yes, ai-input=yes, ai-train=no</code> のように宣言し、「検索やAI回答での引用はOKだが、モデルの学習には使うな」という意思を伝えます。しかし宣言はあくまで「お願い」なので、AI学習用クローラーに対してはBlock AI botsがWAFレベルで実際にアクセスを遮断します。それでもすり抜けてくるクローラーにはAI Labyrinthが偽データを食わせます。</p> <p>さらに、AI Crawl ControlのCrawlersタブではクローラーごとに個別のAllow/Blockを設定できます。たとえば「ChatGPT-Userは許可するがBytespiderはブロックする」といった細かい制御も可能です。</p> <p>この多層構成により、AI検索からの流入を確保しつつ学習目的のスクレイピングは拒否するという運用が、無料プランだけで実現できます。</p> <h2 id="Cloudflareの評価">Cloudflareの評価</h2> <p>比較表を振り返ると、Cloudflareの強みは大きく3つあります。</p> <p>1つ目は、無料プランでのセキュリティの充実度です。AWSで同等のボット対策やWAFを実現しようとすると、AWS WAFやBot Controlの追加費用と自前でのルール作成が必要でした。GitHub Pagesではユーザーが設定できるセキュリティ機能はほとんどありません。Cloudflareでは、AIボットのブロック、Bot fight mode、WAFまで無料プランに含まれており、しかもダッシュボードのトグルひとつで有効にできます。</p> <p>2つ目は、DNS・証明書・セキュリティ・CDNがひとつのダッシュボードに統合されている点です。AWSではRoute 53、CloudFront、ACM、WAFと複数サービスをまたいで設定する必要がありました。GitHub PagesではDNSが外部依存のため、DNSSECやSPF/DMARCの設定は利用するDNSプロバイダ次第でした。Cloudflareではドメイン取得からDNSSEC、メールセキュリティ、デプロイまで一箇所で完結するため、設定の見通しがよく管理も楽です。</p> <p>3つ目は、他のサービスでは提供されていない独自機能です。前述のとおり、Content Signals PolicyからBlock AI bots、AI Labyrinthまで、AIクローラーへの多層的な対応が無料プランだけで揃います。加えて、Speculation Rules APIを活用したSpeed BrainやTLS 1.3の0-RTT再接続など、パフォーマンス面でも独自の機能が提供されています。特にAIクローラー対策は今後ますます重要になる領域であり、「意思表示」と「技術的ブロック」と「欺瞞防御」を組み合わせた構成がワンクリックで手に入るのは大きな安心感があります。</p> <p>個人の静的サイトという用途では、Cloudflareの無料プランだけで「やりたいことが全部できる」状態になりました。以前はAWSの複数サービスを組み合わせて実現していたことが、Cloudflareではひとつのダッシュボードで、しかも無料で手に入ります。移行してよかったと素直に思います。</p> <!-- textlint-enable --> <section class="footnotes"> <ol class="footnotes-list"> <li id="fn-2"> <p>Cloudflare Pagesは現在、Cloudflare Workersとの<a rel="external" href="https://blog.cloudflare.com/pages-and-workers-are-converging-into-one-experience/">統合が進んでいる</a>。将来的にはWorkersの静的アセット機能に一本化される見込みだが、Pages自体も引き続き利用可能。 <a href="#fr-2-1">↩</a></p> </li> <li id="fn-1"> <p><code>.dev</code> ドメインはGoogleが管理しているTLDで、HSTS Preload ListにTLD単位で登録済みなので最初からHTTPSが強制される。 <a href="#fr-1-1">↩</a></p> </li> </ol> </section>

Cloudflareの無料プランで利用できるWAF・ボット対策・AIクローラー対策などのセキュリティ機能を、AWS AmplifyやGitHub Pagesと比較しながら紹介します。

2026-02-06T00:00:00+00:00 2026-02-06T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2026/02/github-pages-security-headers/ <!-- textlint-disable --> <div class="admonition note"> <div class="admonition-icon admonition-icon-note"></div> <div class="admonition-content"> <strong class="admonition-title">NOTE</strong> <p>この記事は <a rel="external" href="https://zenn.dev/yostos/articles/github-pages-security-headers">Zenn.dev</a> に掲載した記事の転載です。</p> </div> </div> <!-- textlint-enable --> <h2 id="TL;DR">TL;DR</h2> <ul> <li>GitHub Pagesではセキュリティヘッダーを設定する機能がなく、スキャナーの警告がでる</li> <li>セキュリティスキャナーの警告は「ベストプラクティス未達」であり「脆弱性」ではない</li> <li>GitHub Pagesでは大抵静的サイトのため、放置しても実質的なリスクは低い</li> <li>自前でホスティングしたWordPressなどの動的サイトは必ず対応すべき</li> </ul> <h2 id="セキュリティヘッダーとは何か">セキュリティヘッダーとは何か</h2> <p>セキュリティスキャナーでよく指摘される6つのHTTPレスポンスヘッダーがあります。</p> <table><thead><tr><th>ヘッダー</th><th>目的</th><th>設定しないリスク</th></tr></thead><tbody> <tr><td>Strict-Transport-Security (HSTS)</td><td>HTTPS接続を強制</td><td>HTTPへのダウングレード攻撃</td></tr> <tr><td>Content-Security-Policy (CSP)</td><td>XSS攻撃を防止</td><td>悪意あるスクリプト実行</td></tr> <tr><td>X-Frame-Options</td><td>クリックジャッキング防止</td><td>偽サイトへの埋め込み</td></tr> <tr><td>X-Content-Type-Options</td><td>MIMEスニッフィング防止</td><td>ファイル種別の誤認識</td></tr> <tr><td>Referrer-Policy</td><td>リファラー情報の制御</td><td>URLパラメータの漏洩</td></tr> <tr><td>Permissions-Policy</td><td>ブラウザ機能の制御</td><td>カメラ等の不正利用</td></tr> </tbody></table> <p>これらのヘッダーは、Webサーバーがレスポンスに含めることで、 ブラウザにセキュリティ関連の指示を与えます。</p> <h2 id="GitHub_Pagesの制限">GitHub Pagesの制限</h2> <p>GitHub Pagesは静的サイトホスティングサービスですが、 <strong>HTTPレスポンスヘッダーをカスタマイズする機能がありません</strong>。</p> <ul> <li><code>.htaccess</code> は使えない（Apache設定ファイル）</li> <li><code>nginx.conf</code> も使えない（Nginx設定ファイル）</li> <li>GitHub側で固定されたヘッダーが返される</li> </ul> <p>どうしてもセキュリティヘッダーを設定したい場合は、Cloudflare CDNを前段に置けばTransform Rulesでヘッダーを追加できます。 ただし、Cloudflareの無料プランはネームサーバー移管が必須です。</p> <p>既存のDNSサービスを使い続けたい場合、 この方法は採用しづらいです。</p> <h2 id="静的サイトと動的サイトでリスクが違う">静的サイトと動的サイトでリスクが違う</h2> <p>セキュリティヘッダーの重要度は、サイトの種類によって大きく異なります。 GitHub Pagesでも動的なSPAをホストできますが、 ここではZolaやHugoなどのSSGで生成した純粋な静的サイトを想定しています。</p> <table><thead><tr><th>観点</th><th>静的サイト（SSG生成）</th><th>動的サイト（WordPress等）</th></tr></thead><tbody> <tr><td>ユーザー入力</td><td>受け付けない</td><td>フォーム等で受け付ける</td></tr> <tr><td>サーバーサイド処理</td><td>なし</td><td>PHP + DB</td></tr> <tr><td>管理画面</td><td>なし</td><td><code>/wp-admin</code> 等が存在</td></tr> <tr><td>XSSリスク</td><td>ほぼなし</td><td>高い</td></tr> <tr><td>クリックジャッキング</td><td>影響軽微</td><td>管理画面が標的になる</td></tr> </tbody></table> <p>WordPressでセキュリティヘッダーが未設定の場合、 管理者がログイン中にクリックジャッキング攻撃を受けたり、 XSS経由でマルウェアを注入されたりするリスクがあります。</p> <h2 id="判断基準：いつ対応すべきか">判断基準：いつ対応すべきか</h2> <p>以下のフローチャートで判断できます。</p> <!-- textlint-disable --> <noscript> <strong>⚠️ JavaScript is required to render the diagram.</strong> </noscript> <pre class="mermaid invertible-image"> flowchart LR A[フォームがある？] -->|Yes| B[対応すべき] A -->|No| C[サイトの性質は？] C -->|個人ブログ| D[放置OK] C -->|企業サイト| E[できれば対応] C -->|公的機関| F[対応すべき] </pre> <!-- textlint-enable --> <p>フォームがあるサイトは対応が必要です。 問い合わせフォーム、会員登録、ログイン機能、寄付やEC機能があれば、 ユーザー入力を受け付けるためXSSのリスクがあります。</p> <p>フォームがない場合はサイトの性質で判断します。 個人の技術ブログやポートフォリオなら放置で問題ありません。 公的機関などのサイトは、信頼性の観点から対応が望ましいです。</p> <h2 id="まとめ">まとめ</h2> <p>セキュリティスキャナーの警告を見ると焦りますが、 すべての警告に対応する必要はありません。</p> <p><strong>重要なのはリスク評価です。</strong></p> <ul> <li>何を守る必要があるか（資産）</li> <li>どんな攻撃が想定されるか（脅威）</li> <li>攻撃が成功する可能性はあるか（脆弱性）</li> </ul> <p>GitHub Pagesで静的ブログを公開している場合、 セキュリティヘッダーがなくても攻撃面がほとんどありません。 「設定できないから放置」は、この場合は合理的な判断です。</p> <p>一方、WordPressや動的サイトでは事情が異なります。 <code>.htaccess</code> やプラグインで設定できるので、対応しておくべきです。</p> <p>スキャナーの警告は「ベストプラクティスに従っていない」という指摘であり、 「今すぐ危険」という意味ではありません。 コンテキストに応じた判断をしましょう。</p> <h2 id="参考文献">参考文献</h2> <ul> <li><a rel="external" href="https://owasp.org/www-project-secure-headers/">OWASP Secure Headers Project</a></li> <li><a rel="external" href="https://github.com/orgs/community/discussions/54257">GitHub Community Discussion - HTTP Headers on Pages</a></li> </ul> <!-- textlint-disable --> <div class="admonition note"> <div class="admonition-icon admonition-icon-note"></div> <div class="admonition-content"> <strong class="admonition-title">免責事項</strong> <p>本記事は情報提供を目的としており、 個別の状況に応じた判断は読者ご自身の責任でお願いします。 セキュリティ要件は組織やサービスによって異なるため、 必要に応じて専門家にご相談ください。</p> </div> </div> <!-- textlint-enable -->

このブログはZola+GitHub Pagesで実現していますが、 GitHub Pagesはセキュリティヘッダの設定ができません。 いないとは思いますが、セキュリティスキャナーなどで未設定を見つけて文句をつけてくるセキュリティ厨がいないとも限りません。 対応すべきか放置すべきかの判断基準を解説しておきます。

2025-12-06T00:00:00+00:00 2025-12-06T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2025/12/react-nextjs-cve-2025-55182-response/ <h2 id="脆弱性の概要">脆弱性の概要</h2> <h3 id="CVE-2025-55182とは">CVE-2025-55182とは</h3> <p>CVE-2025-55182は、React 19のServer Components（RSC）における「Flight」プロトコルの安全でないデシリアライゼーション（deserialize）に起因する脆弱性です。 主な特徴は次の通りです。</p> <ul> <li><strong>CVSSスコア: 10.0（最大値）</strong></li> <li>影響範囲: React 19.0.0、19.1.0、19.1.1、19.2.0</li> <li>攻撃条件: 認証不要、細工されたHTTPリクエストのみで実行可能</li> <li>デフォルト設定で脆弱: <code>create-next-app</code>により作成した標準的なNext.jsアプリケーションが影響を受ける</li> </ul> <h3 id="技術的な仕組み">技術的な仕組み</h3> <p>この脆弱性は、RSCの内部通信プロトコルである「Flight」の処理において、攻撃者の制御可能なデータを適切な検証なしにデシリアライズしてしまうことに起因します。攻撃者からペイロードを含むHTTPリクエストが送信されると、サーバー側ではこれをFlightプロトコルのデータとして処理し、検証なしにデシリアライズします。この結果、任意のコードを実行される可能性があります。</p> <p>重要なのは、この処理がアプリケーションの認証ロジックより前、つまりMiddlewareでの保護より深い層で行われるため、通常の認証機構では防げないという点です。</p> <h2 id="CVE番号の統合経緯">CVE番号の統合経緯</h2> <p>2025年12月3日時点では、以下の2つのCVE番号で追跡されていました。</p> <ul> <li><strong>CVE-2025-55182</strong>: React Server Componentsの脆弱性</li> <li><strong>CVE-2025-66478</strong>: Next.jsの脆弱性</li> </ul> <p>調査の結果、Next.jsの脆弱性は実質的にReactの脆弱性に起因することが判明し、<strong>CVE-2025-66478は重複として却下</strong>されました。現在は<strong>CVE-2025-55182</strong>に統合されています。</p> <p>この経緯は、脆弱性の根本原因がReactのRSC実装そのものにあり、Next.jsはその影響を受けていたに過ぎないことを示しています。</p> <h2 id="影響を受けるバージョンと修正版">影響を受けるバージョンと修正版</h2> <h3 id="React_/_React-dom">React / React-dom</h3> <table><thead><tr><th>影響を受けるバージョン</th><th>修正済みバージョン</th></tr></thead><tbody> <tr><td>19.0.0</td><td>19.0.1</td></tr> <tr><td>19.1.0, 19.1.1</td><td>19.1.2</td></tr> <tr><td>19.2.0</td><td>19.2.1</td></tr> </tbody></table> <h3 id="Next.js">Next.js</h3> <table><thead><tr><th>影響を受けるバージョン</th><th>修正済みバージョン</th></tr></thead><tbody> <tr><td>15.x（全般）</td><td>15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7</td></tr> <tr><td>16.x（全般）</td><td>16.0.7</td></tr> <tr><td>14.3.0-canary.77以降</td><td>（14.x Stable版は影響なし）</td></tr> </tbody></table> <p><strong>注</strong>: Next.js 13.x、14.x stable版、Pages Router、Edge Runtimeは影響を受けません。</p> <h2 id="実際の攻撃状況">実際の攻撃状況</h2> <p>この脆弱性は公表直後から実際に悪用されています。</p> <ul> <li>2025年12月3日: 脆弱性が公表される</li> <li>同日中: 中国関連の脅威グループによる大規模な攻撃活動が観測される</li> <li>2025年12月5日午前6時（UTC）以降: Wizのセンサーが複数の被害者を検知</li> </ul> <p>この脆弱性は「React2Shell」または「React4Shell」という名称でも呼ばれ、既に実証コード（PoC）が公開されています。</p> <h2 id="当ブログでの対応状況">当ブログでの対応状況</h2> <h3 id="対応タイムライン">対応タイムライン</h3> <ul> <li><strong>2025年12月3日</strong>: CVE-2025-55182が公表される</li> <li><strong>2025年12月5日</strong>: 当ブログで修正版へのアップデート実施（v1.7.1）</li> </ul> <h3 id="実施した対応">実施した対応</h3> <p>以下のパッケージを修正版にアップデートしました。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 実施したアップデート</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">React:</span><span class="z-constant z-numeric"> 19.0.0</span><span class="z-string"> →</span><span class="z-constant z-numeric"> 19.2.1</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">React-dom:</span><span class="z-constant z-numeric"> 19.0.0</span><span class="z-string"> →</span><span class="z-constant z-numeric"> 19.2.1</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">Next.js:</span><span class="z-constant z-numeric"> 15.2.3</span><span class="z-string"> →</span><span class="z-constant z-numeric"> 15.5.7</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">@next/mdx:</span><span class="z-constant z-numeric"> 15.2.3</span><span class="z-string"> →</span><span class="z-constant z-numeric"> 15.5.7</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">eslint-config-next:</span><span class="z-constant z-numeric"> 15.2.3</span><span class="z-string"> →</span><span class="z-constant z-numeric"> 15.5.7</span></span></code></pre> <p>当ブログは<strong>CVE-2025-55182に完全対応済み</strong>であり、この脆弱性の影響を受けない安全な状態です。</p> <h2 id="推奨される対応">推奨される対応</h2> <p>Next.jsやReactを使用しているプロジェクトをお持ちの方は、以下の対応を推奨します。</p> <h3 id="1._バージョンの確認">1. バージョンの確認</h3> <p>まず現在のバージョンを確認します。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">npm</span><span class="z-string"> list next react react-dom</span></span></code></pre><h3 id="2._修正版へのアップデート">2. 修正版へのアップデート</h3> <p>該当する場合は、直ちに修正版へアップデートしてください。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># npm の場合</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">npm</span><span class="z-string"> install next@latest react@latest react-dom@latest</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># yarn の場合</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">yarn</span><span class="z-string"> add next@latest react@latest react-dom@latest</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># pnpm の場合</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">pnpm</span><span class="z-string"> add next@latest react@latest react-dom@latest</span></span></code></pre><h3 id="3._内部依存関係の確認">3. 内部依存関係の確認</h3> <p><code>package.json</code>だけでなく、ロックファイル（<code>package-lock.json</code>、<code>yarn.lock</code>など）も確認し、内部依存関係として古いバージョンが残っていないか確認することを強く推奨します。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># ロックファイル内のReactバージョンを確認</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">grep</span><span class="z-string z-punctuation z-definition z-string"> -A5 &#39;&quot;react&quot;:&#39; package-lock.json</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">grep</span><span class="z-string z-punctuation z-definition z-string"> -A5 &#39;&quot;next&quot;:&#39; package-lock.json</span></span></code></pre><h3 id="4._デプロイ">4. デプロイ</h3> <p>アップデート後は速やかにビルドとデプロイを実施してください。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">npm</span><span class="z-string"> run build</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># デプロイコマンドを実行</span></span></code></pre><h2 id="まとめ">まとめ</h2> <p>CVE-2025-55182は、React Server Componentsの根本的な脆弱性であり、 <strong>CVSS 10.0</strong>という最大の深刻度を持つ重大な問題です。デフォルト設定で脆弱であり、認証を回避して攻撃可能という特性から、速やかな対応が必要です。</p> <p>当ブログでは公表から2日以内に対応を完了しましたが、既に実際の攻撃が観測されているため、まだ対応されていない方は最優先で対応することを強く推奨します。</p> <h2 id="参考リンク">参考リンク</h2> <ul> <li><a rel="external" href="https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components">Critical Security Vulnerability in React Server Components – React</a></li> <li><a rel="external" href="https://nextjs.org/blog/CVE-2025-66478">Security Advisory: CVE-2025-66478 | Next.js</a></li> <li><a rel="external" href="https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182">Critical RCE Vulnerabilities Discovered in React &amp; Next.js | Wiz Blog</a></li> <li><a rel="external" href="https://unit42.paloaltonetworks.com/cve-2025-55182-react-and-cve-2025-66478-next/">Critical Vulnerabilities in React Server Components and Next.js</a></li> <li><a rel="external" href="https://nvd.nist.gov/vuln/detail/CVE-2025-55182">NVD - CVE-2025-55182</a></li> </ul>

2025年12月3日、React Server Components（RSC）とNext.jsにおいて、認証不要でリモートコード実行（RCE）が可能となる重大な脆弱性が公表されました。この記事では、この脆弱性の深刻度、CVE番号の統合経緯、そして当ブログでの対応状況について記録します。

2025-07-18T00:00:00+00:00 2025-07-18T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2025/07/openai-pwd-change/ <p>最近はずっとClaudeを利用していてChatGPT/OpenAIはご無沙汰しています。 しかし、なぜかパスワードマネージャーからOpenAIのパスワードが使い回しという警告が出てしまったので、パスワードを変更することにしました。</p> <p>しかし、ここで気付いたのです。パスワード変更機能が提供されていないということ に。</p> <p>以下は、OpenAIアカウントのセキュリティ設定画面です。</p> <!-- textlint-disable --> <img src="https:&#x2F;&#x2F;codedchords.dev&#x2F;blog&#x2F;2025&#x2F;07&#x2F;openai-pwd-change&#x2F;openai-security.webp?h=1085a55696bd1ffef545" alt="セキュリティ設定画面" width="680" height="598" loading="lazy" /><!-- textlint-enable --> <p>多要素認証の設定しかありません。</p>

OpenAIでパスワードを変更しようとして、パスワード変更機能が提供されていないことに気付きました。

2025-07-02T00:00:00+00:00 2025-07-02T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2025/07/anthropic-mcp-inspector-vulnerability/ <details> <summary>Table of Contents</summary> <!-- toc --> </details> <p>開発者向けツールとはいえ、CVSSスコア9.4という深刻度の高さに、セキュリティ対策の重要性を改めて認識させられました。</p> <h2 id="はじめに">はじめに</h2> <p>jrnlのジャーナルにClaude Desktopなどからアクセスを可能とするMCPサーバーを開発中で、 統合テスト時にドライバーを探していてMCP Inspectorを検討していたところ、脆弱性の報告があり驚きました。 開発者向けツールとはいえ、CVSSスコア9.4という深刻度の高さに、セキュリティ対策の重要性を改めて認識しました。</p> <h2 id="MCP_Inspector_とは何？">MCP Inspector とは何？</h2> <p>MCP Inspectorは、Anthropicが提供するModel Context Protocol (MCP) サーバーのテスト・デバッグツールです。MCPは2024年11月に発表された、LLMアプリケーションと外部データソースやツールとの連携を標準化するオープンプロトコルです。</p> <p>MCP Inspectorは主に以下のような場面で使用されます。</p> <ul> <li>MCPサーバー開発者が実装の動作確認を行う際</li> <li>API統合のデバッグやトラブルシューティング時</li> <li>本番環境へのデプロイ前の検証作業</li> </ul> <p>ツールはWeb UIを提供するクライアントと、各種MCPサーバーへの接続を仲介するプロキシサーバーで構成されています。</p> <h2 id="MCP_Inspector_の脆弱性とは">MCP Inspector の脆弱性とは</h2> <p>2025年7月に報告された脆弱性CVE-2025-49596は、悪意のあるWebサイトにアクセスするだけでリモートコード実行を可能にする重大な問題です。</p> <p><a rel="external" href="https://thehackernews.com/2025/07/critical-vulnerability-in-anthropics.html">元記事：Critical Vulnerability in Anthropic's MCP Exposes Developer Machines to Remote Exploits</a></p> <p>攻撃手法は以下の要素を組み合わせたものです。</p> <ul> <li>19年前から存在するブラウザの脆弱性「0.0.0.0 Day」を利用</li> <li>MCP InspectorのCSRF脆弱性と連鎖させる</li> <li>localhostで動作するサービスへ不正なリクエストを送信</li> </ul> <p>根本原因はデフォルト設定における認証と暗号化の欠如でした。プロキシサーバーが0.0.0.0でリッスンし、クライアントとの間に認証機構がなかったため、任意のコマンド実行が可能となっていました。</p> <p>影響範囲はMCP Inspectorを使用している開発者に限定されます。一般のMCPユーザーや本番環境のMCPサーバーには直接影響しません。ただし、攻撃を受けた開発者のマシンから機密情報が漏洩したり、ネットワーク内への侵入経路として悪用される可能性があります。</p> <h2 id="まとめ">まとめ</h2> <p>この脆弱性は2025年6月13日にリリースされたバージョン0.14.1で修正されています。MCP Inspectorを使用している開発者は直ちにアップデートすることを推奨します。</p> <p>開発ツールであっても適切なセキュリティ対策が必要であることを示す事例となりました。 特にlocalhostで動作するサービスも攻撃対象となりうることを認識し、 開発環境のセキュリティにも十分な注意を払う必要があると肝に銘じました。</p>

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

2025-06-04T00:00:00+00:00 2025-06-04T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2025/06/vulnerability-check/ <details> <summary>Table of Contents</summary> <!-- toc --> </details> ebサイトのセキュリティが気になるけど、専門的な知識がなくて何から始めればいいか分からない...そんなIT技術者の方に向けて、オープンソースのツールを使った脆弱性スキャンの方法をご紹介します。今回は「Nuclei」と「Katana」という2つのツールを組み合わせて、効率的にWebサイトの脆弱性をチェックする方法を解説していきます。 <h2 id="1._NucleiとKatanaとは？">1. NucleiとKatanaとは？</h2> <p>NucleiはProjectDiscoveryが開発したオープンソースの脆弱性スキャナーです。最大の特徴は以下の通りです。</p> <ul> <li><strong>テンプレートベース</strong>：YAML形式のテンプレートで脆弱性パターンを定義</li> <li><strong>コミュニティ駆動</strong>：世界中のセキュリティ研究者が3000以上のテンプレートを提供</li> <li><strong>高速処理</strong>：並列処理による効率的なスキャン</li> <li><strong>低い誤検出率</strong>：実際の脆弱性を模擬したテストで精度が高い</li> <li><strong>多様な対応</strong>：CVE、設定ミス、情報漏洩など幅広い脆弱性に対応</li> </ul> <p>KatanaもProjectDiscoveryが開発したWebクローラーです。</p> <ul> <li><strong>高速クロール</strong>：Go言語で開発された軽量高速なクローラー</li> <li><strong>JavaScript対応</strong>：SPA（Single Page Application）も適切にクロール</li> <li><strong>設定柔軟</strong>：クロール深度や対象範囲を細かく制御可能</li> <li><strong>Nuclei連携</strong>：同じ開発元のため、Nucleiとの相性が抜群</li> </ul> <p>両者ともProjectDiscoveryが開発したツールですが、この組み合わせが良い理由は次 の通りです。</p> <ul> <li>Katanaでサイト全体のURLを収集</li> <li>NucleiでそれらのURLに対して脆弱性をチェック</li> <li>両ツールとも同じ開発元なので連携がスムーズ</li> <li>オープンソースなので無料で利用可能</li> </ul> <h2 id="2._インストール方法">2. インストール方法</h2> <p>前提条件は次の通りです。</p> <ul> <li>macOS</li> <li>Homebrew（未インストールの場合は<a rel="external" href="https://brew.sh/ja/">公式サイト</a>からインストール）</li> <li>Go言語環境（<code>brew install go</code>でインストール可能）</li> </ul> <p>インストール手順は以下の通りです。 初回実行時にNucleiが自動的にテンプレートをダウンロードします。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># Homebrewを使用（推奨）</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">brew</span><span class="z-string"> install nuclei</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># インストール確認</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -version</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># Go言語でインストール</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">go</span><span class="z-string"> install github.com/projectdiscovery/katana/cmd/katana@latest</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># インストール確認</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">katana</span><span class="z-string"> -version</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># テンプレートの手動更新（定期的に実行推奨）</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -update-templates</span></span></code></pre><h2 id="3._実行方法と結果の確認">3. 実行方法と結果の確認</h2> <p>最もシンプルな使い方から始めましょう。単一のURLを検査する方法です。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 基本的なスキャン</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -u https://example.com -o results.txt</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 重要度の高い脆弱性のみチェック</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -u https://example.com -s critical,high,medium -o important_vulns.txt</span></span></code></pre> <p>サイト全体をチェックしたい場合は、次のような手順となります。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 1. Katanaでサイト全体をクロール</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">katana</span><span class="z-string"> -u https://example.com -d</span><span class="z-constant z-numeric"> 2</span><span class="z-string"> -o urls.txt</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 2. 不要なファイルを除外</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">grep</span><span class="z-string z-punctuation z-definition z-string"> -v -E &#39;\.(jpg|jpeg|png|gif|css|js|ico)$&#39; urls.txt</span><span class="z-keyword z-operator"> &gt;</span><span class="z-string"> filtered_urls.txt</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 3. Nucleiで脆弱性スキャン</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -l filtered_urls.txt -s critical,high,medium -o vulnerability_report.txt</span></span></code></pre> <p>脆弱性が発見されなければ何も出力されません。 脆弱性が発見された場合は発見された内容が出力されていますので、以下のように 確認できます。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 発見された脆弱性の数</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">wc</span><span class="z-string"> -l vulnerability_report.txt</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 脆弱性の内容確認</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">cat</span><span class="z-string"> vulnerability_report.txt</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 重要度別の集計</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">cat</span><span class="z-string"> vulnerability_report.txt</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> grep</span><span class="z-string z-punctuation z-definition z-string"> -oE &#39;\[(critical|high|medium|low)\]&#39;</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> sort</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> uniq</span><span class="z-string"> -c</span></span></code></pre><h2 id="4._どのような検証がなされているか確認する方法">4. どのような検証がなされているか確認する方法</h2> <p>仕事などで脆弱性検証する場合、「で、一体何が検証されたん？」と聞かれること もあると思います。3,000以上のテンプレートを使用しているので、簡単にどんなテ ンプレートが使用されているか把握する方法です。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 全テンプレート数</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># カテゴリ別のテンプレート数</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin">echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;CVE脆弱性: </span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -tags cve</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation">)</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin">echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;情報漏洩: </span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -tags exposure</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation">)</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin">echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;設定ミス: </span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -tags misconfig</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation">)</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin">echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;XSS: </span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -tags xss</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation">)</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin">echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;LFI: </span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -tags lfi</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation">)</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin">echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;管理画面: </span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -tags panel</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation">)</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin">echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;技術スタック: </span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -tags tech</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation">)</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin">echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;情報収集: </span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -tags osint</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation">)</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 重要度で判別</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -s critical</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation z-definition z-comment z-comment"> # 1321件</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -s high</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation z-definition z-comment z-comment"> # 2377件</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -s medium</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation z-definition z-comment z-comment"> # 2322件</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -s low</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation z-definition z-comment z-comment"> # 316件</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -s info</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> wc</span><span class="z-string"> -l</span><span class="z-punctuation z-definition z-comment z-comment"> # 4086件</span></span></code></pre> <p>脆弱性が発見された場合は、以下のように詳細ログを確認しましょう。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 詳細ログ付きで実行</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -u https://example.com -v -o results.txt</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 特定カテゴリのテンプレート一覧</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -tl -tags cve</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> head</span><span class="z-string"> -10</span></span></code></pre><h3 id="CVE（Common_Vulnerabilities_and_Exposures）について">CVE（Common Vulnerabilities and Exposures）について</h3> <p>CVEは世界共通のセキュリティ脆弱性カタログです。</p> <ul> <li><strong>命名規則</strong>：CVE-YYYY-NNNNN（年-通し番号）</li> <li><strong>例</strong>：CVE-2021-44228（Log4jの重大な脆弱性）</li> <li>Nucleiは3000以上のCVEに対応したテンプレートを保有</li> </ul> <h2 id="5._実践的な使い分け">5. 実践的な使い分け</h2> <p>実践的な使い方をまとめてみしょう。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># クイックチェック（30秒以内）</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -u https://example.com -t exposures/ -s critical,high</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># バランス型チェック（1-2分）</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -u https://example.com -t cves/,exposures/ -s medium,high,critical</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 徹底スキャン（5-10分） - 新サイトの評価など</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">katana</span><span class="z-string"> -u https://example.com -d</span><span class="z-constant z-numeric"> 2</span><span class="z-keyword z-operator"> |</span><span class="z-entity z-name z-function"> nuclei</span><span class="z-string"> -s critical,high,medium</span></span></code></pre> <p>テンプレート選択は以下のような指針で運用するとよいと思います。</p> <ul> <li><strong>初回チェック</strong>：<code>cves/,exposures/</code>（CVEと情報漏洩）</li> <li><strong>定期チェック</strong>：<code>-s critical,high</code>（重要度の高いもののみ）</li> <li><strong>詳細調査</strong>：全テンプレート使用</li> </ul> <h2 id="6._パフォーマンス最適化">6. パフォーマンス最適化</h2> <p>脆弱性の検証自体は結構重たい処理なってしまうので、パフォーマンスが問題となる 場合は、以下のような並行度やレート制限を調整しましょう。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 並列度とレート制限の調整</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -u https://example.com -c</span><span class="z-constant z-numeric"> 50</span><span class="z-string"> -rl</span><span class="z-constant z-numeric"> 100</span><span class="z-string"> -timeout</span><span class="z-constant z-numeric"> 5</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># バッチ処理での最適化</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string"> -l urls.txt -c</span><span class="z-constant z-numeric"> 25</span><span class="z-string"> -rl</span><span class="z-constant z-numeric"> 50</span><span class="z-string"> -bulk-size</span><span class="z-constant z-numeric"> 25</span></span></code></pre> <ul> <li><strong>-c 50</strong>：同時実行テンプレート数を50に設定</li> <li><strong>-rl 100</strong>：1秒間に100リクエストまで</li> <li><strong>-timeout 5</strong>：タイムアウトを5秒に短縮</li> </ul> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"></span></code></pre><h2 id="7._セキュリティ向上のための継続的運用">7. セキュリティ向上のための継続的運用</h2> <p>継続的に運用するために、次のようなスクリプトを組んでcronなどで自動運用する 方法もよいと思います。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-shebang z-shell z-meta z-shebang z-shell">#!/bin/bash</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># daily_security_check.sh</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-source">TARGET</span><span class="z-keyword z-operator">=</span><span class="z-punctuation z-definition z-string z-string">&quot;https://your-website.com&quot;</span></span> <span class="giallo-l"><span class="z-source">DATE</span><span class="z-keyword z-operator">=</span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">date</span><span class="z-string"> +%Y%m%d</span><span class="z-punctuation">)</span></span> <span class="giallo-l"><span class="z-source">OUTPUT_DIR</span><span class="z-keyword z-operator">=</span><span class="z-punctuation z-definition z-string z-string">&quot;security_scans/</span><span class="z-variable z-other z-normal z-shell">$DATE</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 金曜日（5）かチェック</span></span> <span class="giallo-l"><span class="z-keyword">if</span><span class="z-punctuation"> [ $(</span><span class="z-entity z-name z-function">date</span><span class="z-string"> +%u</span><span class="z-punctuation">)</span><span class="z-keyword z-operator"> -eq</span><span class="z-constant z-numeric"> 5</span><span class="z-punctuation"> ];</span><span class="z-keyword"> then</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin"> echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;金曜日なので、テンプレートを更新します...&quot;</span></span> <span class="giallo-l"><span class="z-entity z-name z-function"> nuclei</span><span class="z-string"> -update-templates</span></span> <span class="giallo-l"><span class="z-keyword">fi</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name z-function">mkdir</span><span class="z-string z-punctuation z-definition z-string"> -p &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT_DIR</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 高優先度の脆弱性をチェック</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">nuclei</span><span class="z-string z-punctuation z-definition z-string"> -u &quot;</span><span class="z-variable z-other z-normal z-shell">$TARGET</span><span class="z-punctuation z-definition z-string z-string">&quot; -s critical,high -o &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT_DIR</span><span class="z-string z-punctuation z-definition z-string">/critical_scan.txt&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 結果をメール送信（お好みで）</span></span> <span class="giallo-l"><span class="z-keyword">if</span><span class="z-punctuation"> [</span><span class="z-keyword z-operator"> -s</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT_DIR</span><span class="z-string z-punctuation z-definition z-string">/critical_scan.txt&quot;</span><span class="z-punctuation"> ];</span><span class="z-keyword"> then</span></span> <span class="giallo-l"><span class="z-entity z-name z-function"> mail</span><span class="z-string z-punctuation z-definition z-string"> -s &quot;セキュリティアラート: </span><span class="z-variable z-other z-normal z-shell">$TARGET</span><span class="z-punctuation z-definition z-string z-string">&quot; admin@company.com</span><span class="z-keyword z-operator"> &lt;</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT_DIR</span><span class="z-string z-punctuation z-definition z-string">/critical_scan.txt&quot;</span></span> <span class="giallo-l"><span class="z-keyword">fi</span></span></code></pre><h2 id="8._他ツールとの連携例">8. 他ツールとの連携例</h2> <p>Webサイトが静的サイトジェネレーターなどで組まれている場合は、 サイト生成のCI/CDパイプラインに脆弱性検証を組み込むという手もあります。</p> <p>以下は、GitHub Actionsの例です。</p> <pre class="giallo z-code"><code data-lang="yaml"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># GitHub Actions例</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml">name</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-string"> Security Scan</span></span> <span class="giallo-l"><span class="z-constant z-language z-boolean">on</span><span class="z-punctuation z-separator z-key-value">:</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml"> schedule</span><span class="z-punctuation z-separator z-key-value">:</span></span> <span class="giallo-l"><span class="z-punctuation"> -</span><span class="z-entity z-name z-tag z-yaml"> cron</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-punctuation z-definition z-string z-string"> &quot;0 9 * * 1&quot;</span><span class="z-punctuation z-definition z-comment z-comment"> # 毎週月曜日9時</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml">jobs</span><span class="z-punctuation z-separator z-key-value">:</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml"> security-scan</span><span class="z-punctuation z-separator z-key-value">:</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml"> runs-on</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-string"> ubuntu-latest</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml"> steps</span><span class="z-punctuation z-separator z-key-value">:</span></span> <span class="giallo-l"><span class="z-punctuation"> -</span><span class="z-entity z-name z-tag z-yaml"> uses</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-string"> actions/checkout@v2</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation"> -</span><span class="z-entity z-name z-tag z-yaml"> name</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-string"> Install Nuclei</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml"> run</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span class="z-string"> go install github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation"> -</span><span class="z-entity z-name z-tag z-yaml"> name</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-string"> Run Security Scan</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml"> run</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-keyword"> |</span></span> <span class="giallo-l"><span class="z-string"> nuclei -u ${{ secrets.TARGET_URL }} -s critical,high -o scan_results.txt</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation"> -</span><span class="z-entity z-name z-tag z-yaml"> name</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-string"> Upload Results</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml"> uses</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-string"> actions/upload-artifact@v2</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml"> with</span><span class="z-punctuation z-separator z-key-value">:</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml"> name</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-string"> security-scan-results</span></span> <span class="giallo-l"><span class="z-entity z-name z-tag z-yaml"> path</span><span class="z-punctuation z-separator z-key-value">:</span><span class="z-string"> scan_results.txt</span></span></code></pre> <p>また、レポート生成の自動化、定期的な処理などの最後にレポート出力を組み込んで も良いと思います。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 簡単なサマリーレポート生成</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">generate_security_report</span><span class="z-punctuation">() {</span></span> <span class="giallo-l"><span class="z-source"> TARGET</span><span class="z-keyword z-operator">=</span><span class="z-variable z-parameter">$1</span></span> <span class="giallo-l"><span class="z-source"> OUTPUT</span><span class="z-keyword z-operator">=</span><span class="z-punctuation z-definition z-string z-string">&quot;security_report_</span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">date</span><span class="z-string"> +%Y%m%d</span><span class="z-punctuation">)</span><span class="z-string z-punctuation z-definition z-string">.txt&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-support z-function z-builtin"> echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;=== セキュリティスキャンレポート ===&quot;</span><span class="z-keyword z-operator"> &gt;</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin"> echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;対象サイト: </span><span class="z-variable z-other z-normal z-shell">$TARGET</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-keyword z-operator"> &gt;&gt;</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin"> echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;スキャン日時: </span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">date</span><span class="z-punctuation">)</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-keyword z-operator"> &gt;&gt;</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin"> echo</span><span class="z-punctuation z-definition z-string"> &quot;&quot;</span><span class="z-keyword z-operator"> &gt;&gt;</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"> # スキャン実行</span></span> <span class="giallo-l"><span class="z-entity z-name z-function"> nuclei</span><span class="z-string z-punctuation z-definition z-string"> -u &quot;</span><span class="z-variable z-other z-normal z-shell">$TARGET</span><span class="z-punctuation z-definition z-string z-string">&quot; -s critical,high,medium -o temp_results.txt</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-support z-function z-builtin"> echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;発見された脆弱性数: </span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">wc</span><span class="z-string"> -l</span><span class="z-keyword z-operator"> &lt;</span><span class="z-string"> temp_results.txt</span><span class="z-punctuation">)</span><span class="z-punctuation z-definition z-string">&quot;</span><span class="z-keyword z-operator"> &gt;&gt;</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin"> echo</span><span class="z-punctuation z-definition z-string"> &quot;&quot;</span><span class="z-keyword z-operator"> &gt;&gt;</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin"> echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;詳細結果:&quot;</span><span class="z-keyword z-operator"> &gt;&gt;</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-entity z-name z-function"> cat</span><span class="z-string"> temp_results.txt</span><span class="z-keyword z-operator"> &gt;&gt;</span><span class="z-punctuation z-definition z-string"> &quot;</span><span class="z-variable z-other z-normal z-shell">$OUTPUT</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-entity z-name z-function"> rm</span><span class="z-string"> temp_results.txt</span></span> <span class="giallo-l"><span class="z-support z-function z-builtin"> echo</span><span class="z-punctuation z-definition z-string z-string"> &quot;レポートを生成しました: </span><span class="z-variable z-other z-normal z-shell">$OUTPUT</span><span class="z-punctuation z-definition z-string">&quot;</span></span> <span class="giallo-l"><span class="z-punctuation">}</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 使用例</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">generate_security_report</span><span class="z-punctuation z-definition z-string z-string"> &quot;https://example.com&quot;</span></span></code></pre><h2 id="⚠️_重要：責任ある使用のための注意事項">⚠️ 重要：責任ある使用のための注意事項</h2> <p>脆弱性の検証はサーバーに非常に負荷をかけるため、 不正アクセス禁止法、電子計算機損壊等業務妨害罪、偽計業務妨害罪 などに抵触し違法行為になる可能性があります。</p> <p>必ず以下を遵守しましょう。</p> <ol> <li> <p><strong>所有権の確認</strong></p> <ul> <li>自分が所有するサイトのみスキャンしてください</li> <li>他者のサイトには必ず事前許可を取得してください</li> </ul> </li> <li> <p><strong>適切な負荷制御</strong></p> <ul> <li>本番サイトへの負荷を考慮してレート制限を設定</li> <li>業務時間外でのスキャン実施を推奨</li> </ul> </li> <li> <p><strong>結果の適切な管理</strong></p> <ul> <li>スキャン結果に機密情報が含まれる可能性あり</li> <li>結果ファイルの保存場所とアクセス権限に注意</li> </ul> </li> </ol> <h3 id="なぜ偽計業務妨害罪となる可能性があるか">なぜ偽計業務妨害罪となる可能性があるか</h3> <p>偽計業務妨害罪（刑法233条）の要件は、以下の3つです。</p> <ul> <li>偽計：虚偽の情報や人を欺く行為</li> <li>業務妨害：他人の業務を妨害すること</li> <li>故意：妨害する意図があること</li> </ul> <p>脆弱性検査はサーバーに非常に負荷を掛ける処理であることは知られているので、 業務妨害と故意であることは分かりやすいと思います。</p> <p>「偽計」については、脆弱性スキャンはブラウザの正常なアクセスを装って リクエストヘッダを偽装しつつ「負荷」という観点では攻撃的とも言えるペイロード を送信するため「偽計」と見なされる可能性があります。</p> <h2 id="まとめ">まとめ</h2> <p>NucleiとKatanaを使った脆弱性スキャンは、以下のような方に特におすすめです。</p> <ul> <li>自社サイトのセキュリティ状況を定期的にチェックしたい</li> <li>オープンソースツールでコストを抑えたい</li> <li>コマンドラインツールに慣れている</li> <li>セキュリティの基本的な知識を実践で学びたい</li> </ul> <p>最初は単一URLの簡単なチェックから始めて、慣れてきたらサイト全体のスキャンや自動化に挑戦してみてください。重要なのは継続的にセキュリティをチェックする習慣を作ることです。</p> <p><strong>脆弱性が見つからない結果も良い結果</strong>です。むしろサイトが適切にメンテナンスされている証拠として安心できる材料になります。</p> <p>セキュリティは一度設定すれば終わりではなく、継続的な取り組みが重要です。このツールを活用して、より安全なWebサイト運営を目指しましょう。</p> <hr /> <p><strong>参考リンク</strong></p> <ul> <li><a rel="external" href="https://docs.projectdiscovery.io/opensource/nuclei/overview">Nuclei公式ドキュメント</a></li> <li><a rel="external" href="https://github.com/projectdiscovery/katana">Katana公式リポジトリ</a></li> <li><a rel="external" href="https://projectdiscovery.io/">ProjectDiscovery</a></li> </ul> <p><strong>注意</strong>：この記事の内容は啓蒙目的であり、適切な許可なく他者のシステムをスキャンすることは違法行為となる可能性があります。必ず責任を持って使用してください。</p>

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

2025-03-22T00:00:00+00:00 2025-03-22T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2025/03/cve-2025-29927/ <h2 id="CVE情報">CVE情報</h2> <ul> <li>CVE番号: CVE-2025-29927</li> <li>GHSAコード: GHSA-f82v-jwr5-mffw</li> </ul> <p>攻撃者が特定のHTTPヘッダーを操作することで、ミドルウェアの認証チェックを迂回 し、保護されたリソースにアクセスできてしまう問題のようです。</p> <h2 id="アップデート手順">アップデート手順</h2> <p>アップデートの手順は次の通りです。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># Next.jsのアップデート</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">npm</span><span class="z-string"> install next@15.2.3 @next/mdx@15.2.3 eslint-config-next@15.2.3</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># npx next updateでもいいか。</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># アップデート後問題ないか、一応Lintをかけておく</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">npm</span><span class="z-string"> run lint</span></span></code></pre>

Next.js 15.2.3未満で認証をバイパスできる脆弱性の通知がGitHubから飛んできたので、一応このブログもアップデートしました。

2024-10-23T00:00:00+00:00 2026-07-01T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2024/10/modern-messaging-apps/ <p>市川強盗傷害事件で犯人たちが「秘匿性が高い通信アプリを使用」とアプリ名を伏せて報道されています。 どうやら<a rel="external" href="https://signal.org/ja/">Signal</a>を使っていたようです。こうなるとバカなメディアや視聴者が「邪悪なアプリ」と騒ぎ出しそうですね。</p> <p>プライバシー<sup class="footnote-reference" id="fr-1-1"><a href="#fn-1">1</a></sup> を考慮すると当然の選択ですね。公安や自衛隊でもSignalを奨励しているようです。 不完全な暗号化やメタデータ収集するLINEとかいうアプリを使っている能天気なメディアや視聴者より、 犯人たちのほうがよほど高いリテラシーを持っていたということでしょう。</p> <p>気になったので、主要なメッセージングアプリについての比較表を作ってみました。</p> <h2 id="メッセージングアプリの総合比較表">メッセージングアプリの総合比較表</h2> <p>以下は主なメッセージングアプリのついての比較をまとめた表です。</p> <p>犯人たちが<strong>Signal</strong>を使ったのも納得です。日本ではユーザーが少ないので利用シーンは限られますが。 次点で <strong>Threema</strong> ですね。私は家族で使用しています。</p> <p>iPhoneユーザーであれば <strong>iMessage</strong> は無難でしょう。完全にE2Eで暗号化されており、メタ情報の収集はされているようですが、Appleなので多少はマシだと思います。</p> <p><strong>Telegram</strong> はテロリストが使用しているイメージはありますが、意外に脆弱です。</p> <p><strong>LINE</strong>については、日本でもユーザーが多いので補足を入れています。 やはりLINEは暗号化も不完全でデフォルトの状態ですし、メタ情報<sup class="footnote-reference" id="fr-1-2"><a href="#fn-1">1</a></sup>をかなり収集してお り、おまけに透明性の観点でもいろいろと問題<sup class="footnote-reference" id="fr-2-1"><a href="#fn-2">2</a></sup>がありました。</p> <p>こう並べてみると、<strong>LINE</strong> を選択する意味が私にはわかりません。</p> <table><thead><tr><th>機能/特徴</th><th>LINE</th><th>Signal</th><th>Threema</th><th>WhatsApp</th><th>iMessage</th><th>Telegram</th></tr></thead><tbody> <tr><td>E2E暗号化</td><td>部分対応[暗号化WP] ※1</td><td>完全対応</td><td>完全対応</td><td>完全対応</td><td>完全対応</td><td>Secret Chatのみ</td></tr> <tr><td>グループチャット暗号化</td><td>50人以下のみ[暗号化WP]</td><td>完全対応</td><td>完全対応</td><td>完全対応</td><td>完全対応</td><td>Secret Chatのみ</td></tr> <tr><td>メタデータ収集</td><td>多い[PP] ※2</td><td>最小限</td><td>最小限</td><td>多い</td><td>中程度</td><td>中程度</td></tr> <tr><td>データストレージ</td><td>サーバー保存[暗号化WP,PP] ※3</td><td>端末のみ</td><td>端末のみ</td><td>クラウド可能</td><td>iCloud連携時保存</td><td>サーバー保存</td></tr> <tr><td>電話番号必須</td><td>はい[PP]</td><td>はい</td><td>いいえ</td><td>はい</td><td>いいえ</td><td>はい</td></tr> <tr><td>自動消去機能</td><td>24時間のみ[PP]</td><td>1秒～4週間</td><td>カスタム設定可</td><td>24時間～90日</td><td>2分～4週間</td><td>1秒～1週間</td></tr> <tr><td>法執行機関への情報開示</td><td>多い[TR] ※4</td><td>最小限</td><td>最小限</td><td>多い</td><td>一部可能</td><td>最小限</td></tr> <tr><td>追加機能</td><td>スタンプ/ゲーム/決済/音声・ビデオ通話[PP]</td><td>スタンプ/音声・ビデオ通話</td><td>投票/音声・ビデオ通話</td><td>ステータス/音声・ビデオ通話/決済</td><td>Apple統合/音声・ビデオ通話</td><td>Bot/チャンネル/音声・ビデオ通話</td></tr> <tr><td>オープンソース</td><td>一部のみ[暗号化WP]</td><td>完全対応</td><td>一部のみ</td><td>なし</td><td>なし</td><td>クライアントのみ</td></tr> </tbody></table> <ul> <li>※1: LINEのE2E暗号化（Letter Sealing）対応範囲(doc.1) <ins>（2026年7月追記: 2024年後半にLetter Sealingの保護対象が拡大されました。出典: <a rel="external" href="https://www.lycorp.co.jp/ja/privacy-security/security/transparency/encryption-report/2025/">LINE暗号化状況レポート（2025年）</a>）</ins> <ul> <li>対応: テキスト・位置情報（1対1と50人以下グループ）、1対1音声・ビデオ通話<ins>、画像・動画・音声メッセージ・ファイル添付（2024年後半に対応。1対1と50人以下グループ）</ins></li> <li>非対応: <del>画像、動画、ファイル添付、</del>50人以上グループ、グループ通話、LINEミーティング<ins>、アルバム、ノート</ins></li> </ul> </li> <li>※2: LINEのメタデータ収集内容(doc.2) <ul> <li>アカウント情報（電話番号、メールアドレス）</li> <li>デバイス情報（使用OS、言語設定）</li> <li>アプリの使用頻度情報</li> <li>位置情報（設定による）</li> <li>友達関係の情報</li> </ul> </li> <li>※3: LINEのデータストレージ(doc.1,doc.2) <ul> <li>メッセージはサーバーに保存</li> <li>クラウドバックアップ時は暗号化解除</li> <li>URL preview等の機能利用時はサーバーに内容送信</li> </ul> </li> <li>※4: 法執行機関への開示可能情報(doc.3) <ul> <li>7日分のテキストチャット履歴</li> <li>アカウント情報</li> <li>通信ログ</li> </ul> </li> </ul> <p>判断は以下の[LINEの公式ドキュメント]より確認しています。</p> <ul> <li>暗号化ホワイトペーパー(doc.1)<sup class="footnote-reference" id="fr-linewhitepaper-1"><a href="#fn-linewhitepaper">3</a></sup></li> <li><a rel="external" href="https://terms2.line.me/globalnews_PP/sp">プライバシーポリシー</a>(doc.2)</li> <li>透明性レポート(doc.3)<sup class="footnote-reference" id="fr-linecorp-1"><a href="#fn-linecorp">4</a></sup></li> </ul> <p>私自身は<a rel="external" href="https://threema.ch/en">Threema</a>を使用しています。</p> <section class="footnotes"> <ol class="footnotes-list"> <li id="fn-1"> <p>この場合「プライバシー」と呼ぶのが適当かわかりませんが。 <a href="#fr-1-1">↩</a> <a href="#fr-1-2">↩2</a></p> </li> <li id="fn-2"> <p>2021年のZホールディングとの経営統合で、トークの画像などの情報が韓国の サーバーでホスティングされていたり、通報確認などが中国企業に委託されてい たり、このようなことが「第三国」としかレポートされていなかったりと透明性の観 点で問題がありました。現在は解消されたと報告されていますが。 <a href="#fr-2-1">↩</a></p> </li> <li id="fn-linewhitepaper"> <p>元のホワイトペーパー: https://scdn.line-apps.com/stf/linecorp/en/csr/line-encryption-whitepaper-ver2.1.pdf は現在アクセスできません <a href="#fr-linewhitepaper-1">↩</a></p> </li> <li id="fn-linecorp"> <p>元のレポートページは削除されました <a href="#fr-linecorp-1">↩</a></p> </li> </ol> </section>

市川強盗傷害事件で犯人たちがSignalを使っていたということで、「SIgnalは危険アプリ」とか言い出すバカがいそうなのでまとめてみました。

2024-08-28T00:00:00+00:00 2024-08-28T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2024/08/vulnerability-aws-alb/ <blockquote> <p>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.</p> <p>まず、攻撃者は自身のアカウント内に認証を設定した独自の ALB インスタンスを作成します。 次に、この ALB を使用して、攻撃者が完全に制御できるトークンに署名します。 その後、攻撃者は ALB の設定を変更し、発行者フィールドを被害者が期待する発行者に設定します。 AWS はその結果、攻撃者が偽造したトークンに対して、被害者の発行者として署名を行います。 最後に、攻撃者はこの生成されたトークンを使用して被害者のアプリケーションに対して攻撃を仕掛け、認証と認可の両方を回避します。</p> <cite> [ALBeast Security Advisory by Miggo Research | Miggo](https://www.miggo.io/resources/albeast-security-advisory-alb-vulnerability) </cite> </blockquote> <p>「AWS ALBの脆弱性」と騒がれているけれど、普通にIssuerの検証、JWTトークンの検証、ALBのトラフィックの制限、セキュリティグループの設定をやっていれば関係なくない？「AWS ALBの<strong>ベストプラクティスを無視した間抜けが作ったアプリ</strong>の脆弱性」では？</p>

AWS ALBの脆弱性と騒がれているが・・・

2024-08-25T00:00:00+00:00 2024-08-25T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2024/08/pubkey-of-nostr/ <p>NostrでVanity pubkeyのMiningをやってみました。 プリフィックスに<code>yostos</code>と近い<code>y0st0s</code>を得るため、<code>rana</code>を使って数時間Miningしました。</p> <p>得られた、Pubkeyが<code>npub1y0st0svvu5xg6dvswx7dz5m2p7004kmvsx6n22w4yjp3l6fa3mvsef2zz7</code>で、npub1に続く部分が<code>y0st0s</code>となっています。自己満足ですが。</p> <p>ranaのインストールと使い方は次の通りです。Rustの実行環境が事前に必要です。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">cargo</span><span class="z-string"> install rana</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">rana</span><span class="z-string"> --vanity-n-prefix y0st0s</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">Started</span><span class="z-string z-punctuation z-definition z-string"> mining process for vanity bech32 prefix[es]: &#39;npub1[&quot;y0st0s&quot;]&#39;</span><span class="z-source"> (estimated</span><span class="z-string"> pow:</span><span class="z-constant z-numeric"> 24</span><span class="z-source">)</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">Benchmarking</span><span class="z-string"> of cores disabled for vanity npub key upon proper calculation.</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">Mining</span><span class="z-string"> using</span><span class="z-constant z-numeric"> 14</span><span class="z-string"> cores...</span></span> <span class="giallo-l"><span class="z-keyword z-operator">&lt;&lt;</span><span class="z-punctuation z-definition z-string">&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;&lt;&lt;&gt;&gt;</span></span> <span class="giallo-l"><span class="z-string">Vanity npub found: y0st0s</span></span> <span class="giallo-l"><span class="z-string">Found matching Nostr public key:</span></span> <span class="giallo-l"><span class="z-string">Hex public key: 23e0b7c18ce50c8d359071bcd1536a0f9efadb6c81b53529d524831fe93d8ed9</span></span> <span class="giallo-l"><span class="z-string">Hex private key: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@</span></span> <span class="giallo-l"><span class="z-string">Npub public key: npub1y0st0svvu5xg6dvswx7dz5m2p7004kmvsx6n22w4yjp3l6fa3mvsef2zz7</span></span> <span class="giallo-l"><span class="z-string">Nsec private key: nsec1@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@</span></span> <span class="giallo-l"><span class="z-string">2597711770 iterations (about 2x10^9 hashes) in 3433 seconds. Avg rate 756688 hashes/second</span></span> <span class="giallo-l"></span></code></pre> <p>プリフィックスに指定する桁数が増えるほどマイニングに時間がかかるので注意しましょう。上記の例ではM3 MAXのMacbook Proで1時間ほどかかりました。</p> <p>また、PubkeyはNative SegWit(Bech32)でエンコードされており、小文字でl,b,i,oを除いた32文字しか使えません。これらの文字については数字などに置き換えて指定する必要があります（yostos-&gt;y0st0sなど）</p>

Nostrで自分の好きなPubkeyを入手するためにがんばってみました。