Parameter Pollution | JSON Injection
Last updated
Last updated
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
HTTPパラメータ汚染 (HPP) は、攻撃者がHTTPパラメータを操作して、ウェブアプリケーションの動作を意図しない方法で変更する技術です。この操作は、HTTPパラメータを追加、変更、または複製することによって行われます。これらの操作の影響はユーザーには直接見えませんが、サーバー側でアプリケーションの機能を大きく変更し、クライアント側に観察可能な影響を与えることがあります。
銀行アプリケーションの取引URL:
元のURL: https://www.victim.com/send/?from=accountA&to=accountB&amount=10000
追加のfromパラメータを挿入することによって:
操作されたURL: https://www.victim.com/send/?from=accountA&to=accountB&amount=10000&from=accountC
取引はaccountAではなくaccountCに誤って請求される可能性があり、HPPが取引やパスワードリセット、2FA設定、APIキーリクエストなどの他の機能を操作する可能性を示しています。
パラメータが解析され、優先される方法は、基盤となるウェブ技術によって異なり、HPPがどのように悪用されるかに影響を与えます。
Wappalyzerのようなツールは、これらの技術とその解析動作を特定するのに役立ちます。
OTP操作のケース:
コンテキスト: ワンタイムパスワード (OTP) を必要とするログインメカニズムが悪用されました。
方法: Burp Suiteのようなツールを使用してOTPリクエストを傍受し、攻撃者はHTTPリクエスト内のemailパラメータを複製しました。
結果: 初期のメール用に意図されたOTPが、操作されたリクエストで指定された2番目のメールアドレスに送信されました。この欠陥により、意図されたセキュリティ対策を回避して不正アクセスが可能になりました。
このシナリオは、OTP生成のために最初のemailパラメータを処理したが、配信には最後のものを使用したアプリケーションのバックエンドの重大な見落としを強調しています。
APIキー操作のケース:
シナリオ: アプリケーションは、ユーザーがプロフィール設定ページを通じてAPIキーを更新できるようにしています。
攻撃ベクトル: 攻撃者は、POSTリクエストに追加のapi_keyパラメータを追加することで、APIキー更新機能の結果を操作できることを発見しました。
技術: Burp Suiteのようなツールを利用して、攻撃者は1つの正当なapi_keyパラメータと1つの悪意のあるapi_keyパラメータを含むリクエストを作成します。サーバーは最後の出現のみを処理し、攻撃者が提供した値にAPIキーを更新します。
結果: 攻撃者は被害者のAPI機能を制御し、プライベートデータに不正にアクセスまたは変更する可能性があります。
この例は、特にAPIキー管理のような重要な機能における安全なパラメータ処理の必要性をさらに強調しています。
ウェブ技術が重複したHTTPパラメータを処理する方法は異なり、HPP攻撃に対する脆弱性に影響を与えます:
Flask: クエリ文字列a=1&a=2のように、最初に遭遇したパラメータ値を採用し、最初のインスタンスを優先します。
PHP (Apache HTTPサーバー上): 逆に、最後のパラメータ値を優先し、与えられた例ではa=2を選択します。この動作は、攻撃者が操作したパラメータを元のものよりも優先することによって、HPPの悪用を無意識に助長する可能性があります。
結果はhttps://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89から取得されました。
パラメータ名の後の%00を無視する。
name[]を配列として処理する。
_GETはGETメソッドを意味しない。
最後のパラメータを優先する。
&および;区切り文字を使用してパラメータを分割する。
name[]を認識しない。
最初のパラメータを優先する。
POST RequestMapping == PostMapping & GET RequestMapping == GetMapping。
POST RequestMapping & PostMappingはname[]を認識する。
nameとname[]が存在する場合はnameを優先する。
パラメータを連結する（例: first,last）。
POST RequestMapping & PostMappingはContent-Typeを持つクエリパラメータを認識する。
name[]を認識する。
パラメータを連結する（例: first,last）。
name[]を認識しない。
最初のパラメータを優先する。
name[]を認識しない。
最初のパラメータを優先する。
name[]を認識しない。
最後のパラメータを優先する。
name[]を認識しない。
最後のパラメータを優先する。
フロントエンドは最初の出現を信じるかもしれませんが、バックエンドはキーの2番目の出現を使用します。
特定の文字はフロントエンドによって正しく解釈されないかもしれませんが、バックエンドはそれらを解釈し、これらのキーを使用します。これは特定の制限を回避するのに役立つかもしれません:
注意すべきは、これらのケースではフロントエンドが test == 1 と考え、バックエンドが test == 2 と考える可能性があることです。
これは、次のような値の制限を回避するためにも使用できます:
ここでは、各パーサーのシリアライザーを使用して、それぞれの出力を表示します。
シリアライザー 1 (例: GoLangのGoJayライブラリ) は次のように出力します:
description = "Duplicate with comments"
test = 2
extra = ""
シリアライザー 2 (例: JavaのJSON-iteratorライブラリ) は次のように出力します:
description = "Duplicate with comments"
extra = "/*"
extra2 = "*/"
test = 1
また、コメントの簡単な使用も効果的です:
JavaのGSONライブラリ:
Rubyのsimdjsonライブラリ:
数値
複数の表現にデコードできます。これには次のものが含まれます：
Which might create inconsistences
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
