PHPのログイン後を守る。セッション・CSRF・認可を別々に点検する

本人を覚える仕組みだけで、操作は許可できない

PHP公式はセッションの厳格モード、HTTPS時のSecure、HttpOnly、SameSiteなどの設定を説明しています。これらは異なる役割を持ち、一つを有効にしただけでログイン後の問題がすべて解決するものではありません。採用する保存方式と実際のWeb設定を管理担当が確認し、アプリで独自に持つセッションも区別します。

公式情報：PHP公式：セッションの設定（確認 2026-10-26）

意図しない変更を、Cookieの設定だけに任せない

OWASPはCSRF対策でフレームワークの機能やトークン等を扱い、SameSiteだけをすべての状況の対策にしないよう説明しています。SONAEの受入案では、設定変更や削除などの状態を変える操作について、正規の画面からの操作と、確認条件を欠く要求の期待結果を別に決めます。トークンをログやURLへ不用意に残さない管理も合わせます。

公式情報：OWASP：CSRF対策（確認 2026-10-26）

操作の対象を、会社と役割で制限する

OWASPはリクエストごとの認可と、既定での拒否を推奨しています。ログインした人が任意の資料を読めるという意味ではありません。SONAEの架空試験案では、会社、役割、対象レコード、操作の組合せを表にし、一般利用者の削除や別会社の閲覧を拒否する期待結果を置きます。画面からボタンを隠したことだけを認可の証拠にしません。

公式情報：OWASP：リクエストごとの認可（確認 2026-10-26）

退職・役割変更後の扱いを決める

ここからはSONAEの運用提案です。アカウントの停止や権限変更を、既存のセッションへどう反映するかを仕様にします。利用できなくなる時点、例外、再認証、管理者が操作する回復手順を対応させます。パスワードを変えたという作業記録だけで、すべての端末とセッションが終了したとは推測しません。製品や実装の条件を確認します。

SONAEの点検・運用提案。架空例。

回復の入口も、特別扱いで弱くしない

ログイン不能時の回復、MFAの再設定、管理者による招待などは、通常のログインとは別の入口です。誰が承認し、何を記録し、古い手段をいつ無効にするかを決めます。架空利用者で通常の回復と不正な役割の拒否を確認する計画を立て、利用者の秘密や回復コードの値を報告書へ貼らないようにします。

SONAEの点検・運用提案。架空例。

三つの条件を、それぞれ受け入れる

本人のセッション、変更の確認、対象への権限について、対象版、確認方法、期待結果、実測、未確認を別欄にします。三つを同じ「ログインできた」という結果で閉じません。今回の記事作成では実顧客の認証やアカウントに触れていません。AIで実装した機能でも、会社や役割が変わる場面で権限が残らないかを、架空データで検証する設計へつなげましょう。

SONAEの点検・運用提案。架空例。

役割を変えた後まで、認可表を読み合わせる

架空の二社と管理者・一般利用者を使い、一覧、詳細、変更、削除、レポートの期待結果を行ごとに決めます。ログイン直後だけでなく、担当から外れた後、会社が変わった後、アカウントを停止した後を別の状態として置きます。許可の判定をアプリ内で一時保存する実装なら、更新が反映される条件も仕様へ含めます。CSRF条件が欠けた要求は、失敗しても業務データが変わらないことを受入にします。利用者が同じボタンを押せたかではなく、操作前後の状態と見える範囲を照合するのが要点です。この表の許可・拒否は計画であり、顧客環境での実測結果ではありません。

SONAEの点検・運用提案。架空例。

完了前のチェック

• セッション・CSRF・認可を別項目にする
• APIとレコードごとに権限を確認
• 停止後と回復後のセッションを確認
• 秘密を受入記録へ複製しない

一次資料と確認範囲

• PHP公式：セッションの設定
• OWASP：CSRF対策
• OWASP：リクエストごとの認可

資料の対象条件と掲載内容を確認して構成した記事です。顧客への接続や攻撃再現はしていません。資料の改訂を自動追従するものではありません。実施直前に公式資料と配布元の最新案内を再確認してください。