おはようございます！ zenncast、MCのマイクです。10月24日、土曜日、朝7時になりました。週末の朝、みなさんいかがお過ごしでしょうか。今日もZennでトレンドになっている記事から、気になる話題をお届けします。
今日は5本の記事をご紹介します。証明書の秘密鍵を検証したお話から、Claude Codeの一時ファイル、セキュリティ点検、Flutterの起動処理、そしてDependabotの通知の仕組みまで。開発中に知っておきたい話題がそろっていますよ。
....
まず1本目は、認証局eMudhraの中間CA証明書で、秘密鍵が極端に小さかった問題を、Pythonで検証した記事です。
公開鍵から秘密鍵を求めるのは、通常、現実的な時間ではできないはずですよね。ところが今回の検証では、総当たりで約0.4秒。ほんの一瞬で秘密鍵が判明したそうなんです。
何をしたのか、順番に見ていきましょう。まず、OpenSSLを使って対象の証明書から公開鍵を取り出し、それを楕円曲線上の点として読み込みます。この証明書で使われている曲線は、NIST P-384です。
そして、基準となる点を繰り返し足していき、公開鍵の点と一致するまで、何回足したかを調べます。この回数が秘密鍵に相当するんですね。今回、その値は156でした。
本来は384ビット近い大きな値を使うので、同じように順番に試しても、現実的な時間では見つかりません。ところが156という小さな値だったために、すぐ見つかってしまったわけです。
暗号の方式だけでなく、そこで使う鍵が適切に生成されていることも大切。そのことが、具体的な数字でよくわかる検証ですね。
....
続いて2本目は、Claude Codeで複数の開発を並行していたら、Macの再起動に約20分かかった、というお話です。
筆者が再起動したのは、なんと6週間ぶり。なかなか起動が進まないと、「もしかして故障？」と不安になりますよね。記事では、大量の一時ファイルの削除待ちだった可能性が高いとしています。ただし、原因の検証はまだ済んでいません。ここは、確認できた事実と推測を分けて受け止めたいところです。
筆者の運用では、作業用フォルダにリポジトリを複製し、そこへ依存パッケージを入れていました。再起動後にも、約9時間半で99万ファイルが生成されていたそうです。ファイルの数で聞くと、かなりの規模ですよね。
対策として挙げられているのが、一時フォルダの件数を定期的に確認して、不要な作業用フォルダを片付けることです。ただし、削除の前には作業を保存し、関連するセッションを終了すること。使用中のフォルダや、どの作業で使ったのかわからないフォルダは、消さないようにします。
また、同じような状況で起動の進捗が止まって見えても、すぐに強制終了せず、まずは待つこと。そして、AIに調査を頼んだ場合も、報告にある事実と仮説を切り分けて、原因の推測は自分でも確かめる必要があります。
便利な開発環境だからこそ、その裏で増えていくファイルにも目を向けたいですね。
....
3本目は、Claude Codeなどに渡して使う、セキュリティ点検用の質問集です。
ポイントは、画面の操作だけでなく、APIを直接呼び出した場合も確認すること。そして、「大丈夫です」という回答だけで終わらせず、コード上の根拠も示すよう求めることです。
認証や権限については、メール確認を回避できないか、ログアウトしたあともトークンを使えてしまわないか、さらに、IDを書き換えるだけで他人のデータにアクセスできないかを調べます。画面では操作できなくても、API側で防げていなければ問題になる、という視点ですね。
外部入力についても確認します。入力された内容がSQLやコマンドとして実行されないか。指定したURLやファイルを経由して、内部ネットワークへアクセスできてしまわないか、といった点です。
そのほかにも、メール送信や外部APIの大量利用を防ぐ上限があるか、秘密情報が漏れていないか、意図しないサービスが公開されていないか、依存ソフトに脆弱性がないかを点検します。
結果は、「問題あり」「防御されている」「該当なし」「未確認」の4つに分けます。確認できていないものを、安全と取り違えないためにも、この分類は大事ですね。
さらに、問題を悪用できる条件と、その影響を再検証します。誤検知ではないか、対策を入れた結果、全ユーザーが使えなくなる危険はないか。問題の発見だけでなく、対策が適切かどうかまで確かめる質問集になっています。
....
続いて4本目は、Flutterで見落としがちな、アプリの起動ルートについての記事です。
Flutterでは、Androidの着信やバックグラウンド処理が、main()を通らずに起動する場合があります。しかも、別のisolate、つまりメモリを共有しない実行環境で動くため、main()で取得しておいた値を、そのまま使うことはできません。
記事で紹介されているのは、User-Agentにアプリ情報を追加した際のトラブルです。着信側のProviderに必要な値が渡されておらず、例外が発生して、着信しなくなってしまいました。
共通のAPI処理への小さな変更でも、通常の起動では問題がなく、別の起動ルートだけで不具合が出ることがあるんですね。だからこそ、すべての起動ルートを確認する必要があります。
対策として、Providerに値を渡す設定は共通関数にまとめ、その引数をrequiredにします。こうしておくと、必要な値を追加した際、渡し忘れをコンパイルエラーで検出できます。
一方、値そのものの取得は、それぞれの起動ルートで行います。共通関数には、設定の組み立てだけを担当させるんですね。そうすれば、着信側では不要な初期化まで実行してしまうことも避けられます。
共通化する部分と、起動ルートごとに分ける部分。その境界をきちんと設計することが、トラブルの予防につながるお話でした。
....
最後、5本目は、Next.jsの脆弱性が公表されたのに、Dependabotから通知が来なかった理由についてです。
原因は、GitHubによる確認と、脆弱性データベースへの掲載が済んでいなかったことでした。
Dependabotは、公表されたすべての脆弱性を、そのまま通知するわけではありません。GitHubが確認した脆弱性だけを通知する仕組みなんです。今回取り上げられた3件は、公表から6日後も、掲載されていませんでした。
通知がないと、つい「自分の環境には関係ないのかな」と思ってしまいそうですが、通知がないことと、安全であることは別なんですね。
筆者は、公式ブログなどからも情報を集めることを勧めています。そして、脆弱性情報の識別番号であるGHSA IDを使って掲載状況を調べ、自分たちが使っているバージョンに影響があるかを確認する。必要であれば、通知を待たず、自分で更新することが大切だと述べています。
自動通知は頼もしい味方ですが、それだけですべてを把握できるわけではない。この仕組みを知っておくと、通知との付き合い方も変わりそうですね。
....
さて、今日のzenncast、いかがでしたか？
今日は、約0.4秒で見つかった証明書の秘密鍵、Claude Codeの大量の一時ファイル、APIまで含めたセキュリティ点検、Flutterの複数の起動ルート、そしてDependabotが通知するまでの条件についてご紹介しました。
詳しい内容はショーノートに書いてありますので、気になった記事をぜひチェックしてみてください。番組の感想もお待ちしています。「この話が役に立った」「こんなテーマも聞きたい」など、気軽にお寄せくださいね。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入っていただけたら、登録や高評価をつけてもらえるとうれしいです。
それでは、次回もみなさんにお会いできるのを楽しみにしています。素敵な土曜日をお過ごしください。お相手はマイクでした。またお会いしましょう！