おはようございます！ zenncast、MCのマイクです。10月23日、金曜日、朝7時になりました。今日もZennでトレンドになっている記事を、皆さんと一緒にチェックしていきます。
今日は5本の記事をご紹介します。PHPの重大な脆弱性への対応から、脆弱性管理の仕組みづくり、新しいWeb開発フレームワーク、そしてAPIの安全対策まで。開発や運用に関わる方には、ぜひ押さえていただきたい話題がそろっています。
....
まず1本目は、PHPの重大な脆弱性、PHP2Shellへの対応についてです。
PHP2Shellは、認証なしで外部から不正なコードを実行される恐れがある、2件の重大な脆弱性です。最初に押さえたいのは、設定変更だけでは安全にならず、修正版への更新が必要だということです。
PHP公式からは、8.2.35、8.3.36、8.4.27、8.5.12が公開されています。ただし、Linuxの配布元によっては、版番号を変えずに修正を取り込む場合があります。番号だけで判断せず、利用している配布元の告知で、修正が適用されているかを確認してください。
記事では、10月22日午前4時時点で、OSやレンタルサーバーによって対応状況に差があるとしています。「保守作業が完了した」というお知らせだけで対策済みと思わず、実際に使っているPHPが修正対象に含まれているかを確かめることが大切です。
KUSANAGIでは、8.2から8.5までの修正版が公開済みです。ただ、自動更新の対象外になっている場合は、手動での更新が必要です。古いPHPを使っている環境では、サポート中の版への移行も進めましょう。
そして、更新したら終わりではありません。不審なログやPHPファイル、見覚えのない管理者アカウントがないかも調べます。「修正が不完全らしい」という未検証の投稿を理由に、更新を遅らせないこと。あわせて、不要なアップロード進捗機能は無効にします。ただし、これも更新の代わりにはなりません。
まず修正版を適用し、そのうえで環境の確認を進める。この順番を、しっかり意識したいですね。
....
続いて2本目は、脆弱性を「見つける」だけで終わらせない、管理の仕組みづくりです。
スキャンで問題が見つかっても、通知を眺めたままになってしまう。そんな状態を避けるために、この記事では、対応の判断から本番環境での解消確認までを追う仕組みを紹介しています。普段の開発やリリースの流れに組み込み、担当者、期限、そして判断した理由を残していく考え方です。
検知には、AWS上の実行環境でAmazon Inspector、依存ライブラリにはDependabotを使います。コンテナは継続スキャンの対象にして、公開したあとに新しく判明した脆弱性も確認できるようにします。
対応の経緯はGitHubのIssueやPRに記録し、複数のリポジトリにまたがる進捗はNotionに集約します。ここで大事なのが、PRをマージしただけでは完了にしないこと。本番環境への反映後、スキャン結果を確認するところまで追いかけます。
重大な脆弱性については、自社への影響を判断する期限と、実際に修復する期限を分けて設定します。また、修正版がまだ出ていない、といった例外も放置しません。対応できない理由、次に評価し直す日、別の人による承認を記録して、引き続き追跡します。
さらに、Claude CodeのSkillsに、情報収集や記録の更新、調査、修正PRの作成を任せる運用も紹介されています。その一方で、人が集中するのは、自社への影響判断、例外の承認、そして修正内容の確認です。
自動化で作業を進めつつ、重要な判断は人が担う。「見つけました」ではなく、「本番で解消したことを確認しました」までつなげる仕組みですね。
....
3本目は、Webアプリの開発から公開までをまとめて扱えるフレームワーク、Voidの話題です。
Voidは、HonoとViteを土台にして、Cloudflare上でWebアプリを開発し、そのまま公開まで進められるフレームワークです。もともとはVoidZeroの商用サービスとして始まり、Cloudflareによる買収後に、配信基盤も含めてOSSとして公開されました。
大きな特徴は、書いたコードに応じて、必要なクラウド機能を自動で用意できることです。データベースや認証を組み込み、コマンド1つでデータベースの更新やアプリの公開まで進められます。アプリを作る作業と、公開に向けた環境の準備が、まとまっているわけですね。
筆者は、実際にポートフォリオを作り直しています。そこで評価しているのが、設定ファイルを手書きせずに公開できた手軽さです。環境設定に時間をかけるより、まず作って届けたい、という場面では気になるポイントです。
一方で、注意点もあります。データベースなどの機能はCloudflareへの依存が強く、初期段階の不具合にも気をつける必要があるとのことです。
手軽に開発から公開まで進められる魅力と、特定の基盤への依存や成熟度。その両方を見ながら、用途に合うか検討したいフレームワークですね。
....
続いて4本目です。ここでもPHP2Shellを取り上げますが、今度は、実際の環境で何を確認し、どう対処するかに焦点を当てた記事です。
PHP2Shellは、認証なしでサーバー上のコードを実行される恐れがある、PHP本体の脆弱性です。そのため、アプリを更新したり、アプリ側をメンテナンスモードにしたりするだけでは防げません。必要なのは、PHP本体への修正です。
まずは、PHPがどこで使われているかを洗い出します。一般公開しているサイトだけでなく、管理画面や、製品の内部で使われているPHPも対象です。そして確認するのは、コマンドライン版のPHPだけではありません。Webで実際に動いているPHPの版と、その修正状況を確かめます。
修正版を適用したあとは、PHPの処理プロセスをすべて再起動します。Dockerを使っている場合は、修正済みのイメージが公開されていることを確認し、作り直して入れ替える必要があります。
すぐに更新できない場合の対応としては、PHPへの通信を遮断し、Webサーバーから静的なメンテナンス画面を返す方法が挙げられています。PHP自体を動かさずに案内を返す、ということですね。設定変更やWAFは、あくまで一時しのぎで、完全な対策ではないとされています。
調査では、メモリ不足や、500番台のエラーの急増などを確認します。ただし、ログに異常が見つからなくても、安全とは断定できません。また、古いPHPを使っている場合は、サポート中の版への移行を進める必要があります。
実際に動いているPHPを確認し、修正して、プロセスの再起動まで行う。更新作業の抜け漏れを防ぐためにも、確認しておきたい内容です。
....
最後、5本目は、APIの安全対策についてです。
まず基本になるのは、「ログインしている人か」だけでなく、「そのデータを見てよい人か」を毎回確認することです。データを取得する条件には所有者のIDを含め、返す項目も必要最小限に絞ります。ログインできたからといって、ほかの人のデータまで見えてよいわけではない、ということですね。
また、見た目には正常な通信でも、大量のデータを取得される場合があります。ユーザーごとに取得量を制限し、急な増加を検知できるようにします。今使っているAPIだけでなく、古いAPIも含めて、何が公開されているかを確認することが大切です。
ログイン試行の制限は、IPとアカウントの両方で行います。多要素認証も導入し、管理者アカウントや開発用アカウントだからといって例外にはしません。
ライブラリや監視ツールの修正も、速やかに取り込みます。さらに、ストレージの公開設定を点検し、他人のデータを取得できてしまわないか、実際にテストします。
そして、侵入される可能性も考えて備えます。不要な個人情報は削除し、データの取得履歴を記録する。アクセスキーは有効期間を短くし、与える権限も絞ります。万が一のときに、被害を広げないための対策ですね。
AIが書いたコードについても、誰が何を閲覧できるのか、というルールと、取得量の制限を重点的に確認します。動くコードができた、というだけで安心せず、誰にどこまで許可しているのかを見直す。これは、日々のレビューでも意識したいポイントです。
....
さて、今日のzenncastは、5本の記事をご紹介しました。
PHP2Shellへの修正版適用と更新後の確認。脆弱性を検知してから、本番での解消確認まで追う仕組み。開発から公開までをまとめて扱うVoid。そして、PHPの実行環境を漏れなく確認する具体的な対処と、APIの権限管理や大量取得への備えについてお伝えしました。
詳しい内容はショーノートに書いてありますので、気になった記事はぜひチェックしてみてください。
番組の感想もお待ちしています。「この話題が役立った」「こんなテーマも聞いてみたい」など、皆さんの声をぜひお寄せくださいね。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入っていただけたら、登録や高評価をつけてもらえるとうれしいです。
それでは、次回も皆さんにお会いできるのを楽しみにしています。今日も無理なく、いい1日をお過ごしください。お相手はマイクでした！