開発中の Web サイトで、セキュリティ チェックを行った後、セキュリティの問題を特定しました。このレポートには、HTTP パラメータ汚染の脆弱性も含まれています。Web で、HPP とは何かを見つけることができました。どのように注入できるかなど。しかし、この種の問題を回避する方法を見つけることができませんでした。サーバー言語はphpです。&私は同じパラメータが重複する可能性があることを知っています&同じものがたくさんある場合、phpは最後のパラメータを考慮してください。しかし、このリスクを回避するために何かをしても意味がありません。では、例を使用して HPP の脆弱性を回避する方法を教えてくれる人はいますか?
前もって感謝します
ここでは「サーバー側 HPP」について説明していますが、クライアント側バージョンの脆弱性もあります。サーバー側のバージョンを理解すると、クライアント側のバージョンにも役立ちます。
HPP は、アプリケーションが別のシステムにバックエンド HTTP 要求を行うときです。
たとえば、あなたのウェブサイトが次のフロントエンド URL を使用して送金を行う場合:
https://www.example.com/transferMoney.php
これは POST メソッドを介してのみアクセスでき、次のパラメーターを取ります。
amount=1000&fromAccount=12345
アプリケーションがこのページを処理するとき、バックエンド システムに対して次の POST 要求を行い、固定のトランザクションを実際に処理しますtoAccount。
https://backend.example/doTransfer.php
toAccount=9876&amount=1000&fromAccount=12345
重複の場合、PHP は最後のパラメーターのみを受け取ると言います。
誰かがあなたの Web サイトへの POST を次のように変更したとします。
amount=1000&fromAccount=12345&toAccount=99999
ページが HPP に対して脆弱な場合transferMoney.php、バックエンド システムに対して次のリクエストを行う可能性があります。
https://backend.example/doTransfer.php
toAccount=9876&amount=1000&fromAccount=12345&toAccount=99999
ユーザーが2 番目に注入したものは、このバックエンド リクエストをオーバーライドし、システムによって設定された意図したアカウント ( ) ではなくtoAccount、自分のアカウント ( ) に送金します。これは、攻撃者がシステムへの独自の要求を修正するのに役立ちます。ただし、攻撃者が自分の Web サイトからこのリンクを生成し、追加のパラメーターに気付かずに他のユーザーを無意識のうちにリンクをたどるように仕向けることができれば、攻撃者にとって便利な場合もあります。999999876
これを修正するには、すべてのバックエンド HTTP リクエストに正しいURL エンコーディングが適用されていること、およびすべての入力が検証されていることを確認する必要があります。たとえば、これfromAccountは実際に有効な口座番号です。また、これが検証されなかったとしても、私の例では、バックエンド リクエストはfromAccount=12345%26toAccount%3D99999、2 番目のリクエストがtoAccount別の POST パラメータとして解釈されないようにエンコードされているはずです。
クライアント側の HPP は、攻撃者がページに表示されるリンクを操作できるため、クライアント側でリンクをたどると、アプリケーション開発者が意図したものとは異なることを行う場合です。たとえば、バックエンド サービスではなくアプリから直接実行される「口座への送金」を変更する追加のパラメーターを使用して、送金ボタンを「汚染」します。