Hello there, ('ω')ノ
シリアライズとは？
システム内のデータ（例：社員情報、申請データ）を一度「文字列形式」に変換して保存や送信することをシリアライズと呼びます。
逆にその文字列を元の形に戻す操作をデシリアライズと言います。
例：
{"user_id":123,"role":"admin"}
これもシリアライズデータの一種です。
なぜ問題になるのか？
デシリアライズ時にチェックが甘いと：
- 本来ありえないデータがそのまま受け付けられる
- システム内部の処理が乗っ取られる可能性
たとえば：
{"user_id":123,"role":"admin"} ↓ {"user_id":123,"role":"superadmin"}
こういった書き換えがそのまま通ってしまうケースです。
実際のチェック手順① 対象システムを探す
以下のような特徴があるシステムは要チェックです：
- Cookieやパラメーターに長くてランダムっぽい文字列が使われている
- JWTやsessionidとは違う独自フォーマットがある
- ファイルアップロード時にJSONやXMLが使われている
実際のチェック手順② 文字列をデコードしてみる
① Base64形式になっている場合が多いので、まずはオンラインツールでデコード：
https://www.base64decode.org/ など
② 中身が見えるか？構造がわかるか？
もしJSONやPHPオブジェクトっぽいデータが含まれていた場合 → 要注意です。
実際のチェック手順③ 書き換えて再送信
- デコードした文字列内のデータを書き換える
- 再度エンコード
- ブラウザやプロキシツールを使って再送信
✅ 観察ポイント：
- 本来変更できないはずの内容が変わるか？
- ロールや権限、IDなどが変わるか？
社内システムでよくあるチェック対象
- 独自Cookie
- ログイン情報管理用のhiddenパラメーター
- アップロードされたJSON/XMLファイル
チェックリストまとめ
- [ ] Cookieやパラメーター内にBase64や不明な文字列がないか？
- [ ] それをデコードして中身を確認したか？
- [ ] 書き換えて再送信し、挙動を確認したか？
- [ ] ロールや権限変更などが起きないか確認したか？
注意事項
- 本番環境では絶対に事前許可を取ること
- セッションIDや暗号化データまで無理に解析しないこと（逆にリスクあり）
- テスト環境での実施推奨
まとめ
- 不正なシリアライズは「データを書き換えて操作できるか」がポイント
- Cookieやパラメーター内の見慣れない文字列を必ずチェック
- Base64デコード → 書き換え → 再送信が基本流れ
Best regards, (^^ゞ
