.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
### HPPパラメーター汚染の定義
httpparameterpollutionは略してHPPと呼ばれるため、一部の人々はそれを「HPPパラメーター公害」と呼んでいます。 HPPは注入型の脆弱性です。攻撃者は、特定のパラメーターをHTTP要求に挿入することにより攻撃を開始します。このような脆弱性がWebアプリケーションに存在する場合、攻撃者はクライアントまたはサーバー攻撃を行うために使用できます。
### HPPパラメーター汚染の原理
最初に、HTTPパラメーター処理について説明しましょう。サーバーとの対話中、クライアントはしばしばGET/POSTリクエストにパラメーターをもたらします。
post /foo http /1.1
user-agent: mozilla/5.0
host:ホスト
Accept: */*
Content-Length: 19
post /foo http /1.1
user-agent: mozilla/5.0
host:ホスト
Accept: */*
Content-Length: 19
上記の例に示すように、これらのパラメーターは名前と値のペアの場合に表示され、通常はリクエストにおいて、同じ名前のパラメーターは一度だけ表示されます。ただし、HTTPプロトコルでは、同じ名前のパラメーターが複数回表示されます。以下のW3Schoolリンクで試すことができます。
http://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_checkbox
ただし、同じ名前のパラメーターが何度も発生した場合、異なるサーバーが異なる方法で処理されます。たとえば、次の3つの例を参照してください。
http://www.google.com/search?q=italyq=china(googleプロセス2同時に同時に同じパラメーター）
http://search.yahoo.com/search?p=italyp=china（yahooはその後パラメーターを処理します）
https://www.baidu.com /search？p=yateyp=china（baiduは最初のパラメーターを処理します）
Googleに2つの検索キーワードパラメーターを同時に提供すると、Googleは両方のパラメーターを照会します。 Baiduは最初のパラメーターの値を処理しますが、Yahooは異なり、次のパラメーターのみを処理します。次の表には、複数回表示される同じ名前のパラメーターを処理する一般的な方法を簡単に示します。
Webサーバー
関数を取得するパラメーター
取得したパラメーター
PHP/Apache
$ _get（ "par"）
最後
JSP/Tomcat
request.getParameter（ "par"）
初め
Perl（CGI）/Apache
param（ "par"）
初め
Python/Apache
getValue（ "par"）
すべて（リスト）
ASP/IIS
request.querystring（ "par"）
all（Comma Delimited文字列）
このURL：http://www.xxxx.com/search.php?id=110id=911を想定してください
Baiduは、Baidu検索を許可することとしてそれを理解します：110＃最初のパラメーターを選択し、2番目のパラメーターを放棄します。
Yahooは、Yahoo Search：911＃を尋ねることを理解し、2番目のパラメーターを選択し、最初のパラメーターをあきらめました。
Googleは、Googleの検索を許可することとして理解します：110 911＃同時に2つのパラメーターを選択します。
主なことは、これらの3つの状況です。これは主に、さまざまなWebサイトによる処理パラメーターを処理するさまざまな方法が原因です。
### HPPパラメーター汚染攻撃方法
HTTPパラメーター公害、またはHPPは、Webサイトがユーザー入力を受け入れ、それを使用して他のシステムに送信されたHTTP要求を生成し、ユーザー出力を確認しないときに発生します。サーバー（バックエンド）またはクライアントを介して、2つの方法で生成されます
1。クライアントへの攻撃
たとえば、2人の候補者の間で他の人の間で投票するために使用されるウェブサイトがあります。このWebサイトのURLとコードは次のとおりです。
URL : http://host/letheme.jsp？poll_id=4568
link1: a href='lote.jsp？poll_id=4568candidate=zhang' zhang san/aの投票
link2: a href='bote.jsp？poll_id=4568candidate=li' li si/aの投票
さまざまな理由で、このページで投票に使用されるリンクの実装は次のとおりです。悪意のある攻撃者が次のURLを生成し、有権者に送信する場合：
http_: //host/letheme.jsp？poll_id=4568candidate=zhang
その後、ページの最終コンテンツは次のとおりです。
URL : http://HOST/chollect.jsp？poll_id=4568candidate=zhang
link1: a href='lote.jsp？poll_id=4568candidate=zhangcandidate=zhang' zhang san/aの投票
link2: a href='yot.jsp？poll_id=4568candidate=zhangcandidate=li' li si/aの投票
JSPについては、同じ名前の2つのパラメーターがある場合に最初の値が取られるため、投票者が誰を選択しても、Zhang Sanは常に票に勝ちます。
一般的に言えば、クライアントへの攻撃は一般に次のプロセスであり、ユーザーは望ましくないオプションを選択します。
2。サーバー側への攻撃
たとえば、特定のWebサイトの実装は次のとおりです。
void private executebackendRequest（httprequest request）{
文字列Action=request.getParameter（ 'Action'）;
string user=request.getParameter（ 'userid'）;
文字列ターゲット=request.getParameter（ 'ターゲット'）;
httpRequest（ 'http://CentralAuthencationServer/checkprivileded.jsp'、 'post'、 'action='+action+'user='+'user+'ターゲット='+ターゲット）;}
/*このユーザーが指定されたアクションを実行する特権があるかどうかのフィードバックを取得します。そのような特権がない場合は、エラーを返し、それ以外の場合はアクションを実行し続けます*/
httpRequest（ 'http://BusinessServer/performance.php'、 'post'、 'action='+action+'user='+user+'ターゲット='+ターゲット）;}
ユーザー許可を認証するための独立した集中認証サーバーを備えており、別のサービスサーバーがビジネスの処理に特別に使用されています。外部ポータルは、実際にはリクエストを転送するためにのみ使用されます。次に、以下のリクエストをサーバーに送信する場合は、元々読み取り専用権限を持っていたユーザーを見てください。
http://www.backlion.org/page?action=viewuserid=zhangsantarget=bizreportaction=edit
したがって、Web Serverパラメーターの処理を知っている方法に応じて、このユーザーは認証を通じて行う許可を持たないことを行うことができます。
Webサーバー
関数を取得するパラメーター
取得したパラメーター
PHP/Apache
$ _get（ "par"）
最後
JSP/Tomcat
request.getParameter（ "par"）
初め
### HPPパラメーター汚染のヒント
HPPは、攻撃者がいくつかのWebアプリケーションファイアウォール（WAF、WebAppファイアウォール）をバイパスするために使用することもできます。 HTTPパラメーター汚染注入は、Webサイトで提出された同じパラメーターを処理するさまざまな方法によって引き起こされます。
例えば：
www.backlion.org/a?key=abkey=3
サーバーが入力キーの値を返す場合、
1：AB
2：3
3：AB3
これらの3つの異なる方法。
特定のサーバー処理方法は次のとおりです。
Webサーバー
関数を取得するパラメーター
取得したパラメーター
PHP/Apache
$ _get（ "par"）
最後
JSP/Tomcat
request.getParameter（ "par"）
初め
Perl（CGI）/Apache
param（ "par"）
初め
Python/Apache
getValue（ "par"）
すべて（リスト）
ASP/IIS
request.querystring（ "par"）
all（Comma Delimited文字列）
入力www.backlion.org/a?key=selectkey=1,2,3,4をテーブルから仮定します
サーバーは、テーブルから1,2,3,4を選択してキーを処理し、SQL注入をもたらします
たとえば、特定のページのSQLインジェクション攻撃は次のとおりです。
show_user.aspx？id=5; select+1,2,3+from+users+where+id=1---
この攻撃は、パラメーターID：select . from .しかし、hppに変更されている場合、Select .から明らかなSQLインジェクションテンプレートがあるため、WAFによって正常に傍受されます。
show_user.aspx？id=5; select+1id=2Id=3+from+users+where+id=1--
現時点では、selectの特性を持つパラメーターはありません。
PHPは、以下のWAF:をバイパスするために使用できます
http://www.xishaonian.com/hello.php?id=select 1ID=2,3,4から管理者
この状況は、WAFをバイパスするためにも使用し、もちろんXSSと組み合わせることもできます。
### HPPパラメーター汚染ケース
ケース1：2009年、ModSecurityフィルターは、ブラックリストに登録されたテーブルからSelect1,2,3などのステートメントを分類します。 Webサーバーが /index.aspx?page=select 1,2,3のようなステートメントに遭遇すると、リクエストがブロックされます。ただし、このWebサーバーが同じパラメーターに割り当てられた異なる値に遭遇すると、それらを接続します。攻撃者は、この方法を介してブラックリストをバイパスできます。たとえば、次のURLを送信します。
/index.aspx?page=select 1Page=2,3mからテーブルから
まず第一に、これはブラックリストのパターンではなく、ブラックリストインターセプト関数をトリガーしません。第二に、Webプログラムは接続操作、つまりシンボルの前後にコンテンツを接続するため、SQLインジェクションの動作を実行できます。
ケース2：このケースは、多くのUNIXシステムで使用されている印刷システムであるApple Cupsに関するものです。次の方法を使用してXSS攻撃を試してください。
http://127.0.0.1:631/admin/？kerberos=onmouseover=alert（1）kerberos
この検証システムは、空の2番目のKerberosの値のみを採用しているため、トリガーされないため、この方法はシステムの検証メカニズムをバイパスするために使用できます。最初のKerberosは、動的なHTMLコンテンツの構築に使用されるまで確認されませんでした。最後に、JavaScriptステートメントはWebサイトのコンテキストで実行されます
ケース3：多くの支払いリンクには抜け穴がある場合があります。一方で、支払いリンクには一般に、重要なパラメーターで構築された署名があります。これらの署名は、特定の重要なフィールドで構成され、同じ名前のフィールドを追加した後。署名時に最初の支払い金額パラメーターが検証される可能性があります。ただし、実際の支払いが使用されると、後続の支払い額パラメーターが使用され、署名が囲まれます。
次のサイトがあるとします。3https://www.example.com/transfermoney.php。これは、次のパラメーターを使用して、POSTメソッドからアクセスできます。
金額=1000 FromAccount=12345
申請がリクエストを処理すると、他のバックエンドシステムへの独自のPOSTリクエストを生成します。これは、実際に固定されたToAcCcccccccarterパラメーターを使用してトランザクションを処理します。
個別のバックエンドURL：https://BackEnd.example/dotransfer.php
個別のバックエンドパラメーター：toaccount=9876amount=1000 FromAccount=12345
ここで、バックエンドが重複パラメーターが提供されたときに最後のパラメーターのみを受け入れ、攻撃者がWebサイトに送信されたPOSTリクエストを変更してToAcCountパラメーターを送信すると仮定します。
金額=1000 FromAccount=12345ToAccount=99999
HPPの脆弱性を備えたサイトは、このような別のバックエンドシステムにリクエストを転送します。
toaccount=9876amount=1000 -FromAccount=12345ToAccount=99999（PHPプロセスの最後のパラメーター値、つまり99999）
ここでは、悪意のあるユーザーが提出した2番目のToaccountパラメーターは、バックエンドリクエストを上書きし、システムによって設定された予想アカウントの代わりに、悪意のあるユーザーのトレーニングアカウント（99999）にお金を転送します（9876）。
これは、攻撃者が自分の要求を変更し、脆弱なシステムで処理するつもりである場合に非常に便利です。しかし、攻撃者が別のポイントからリンクを作成し、ユーザーに攻撃者が添付した追加のパラメーターを使用して悪意のあるリクエストを誤って送信するように誘導できる場合、攻撃者にとってより実用的になる可能性があります。
ケース4：一方、HPPクライアントは、追加のパラメーターをリンクやその他のSRC属性に注入することを伴います。 OWASPの一例では、次のコードがあるとします。
？ $ val=htmlspecialchars（$ _ get ['par']、ent_quotes）; a href='/page.php？action=viewpar='。=$ val？ ''私を見る！/a
URLからのPARの値を受け入れ、安全であることを保証し、そこからリンクを作成します。さて、攻撃者が提出した場合：
http://host/page.php？par=123action=edit
結果のリンクは次のとおりです。
a href='/page.php？action=viewpar=123action=edit'View me！/a
これにより、アプリケーションは操作を表示する代わりに編集操作を受け入れます
### HPPパラメーター公害リスト
1。ハッケロンソーシャル共有ボタン
レポート接続：https://hackerone.com/blog/introducing-signal-and-Impact
脆弱性の説明：Hackeroneには、Twitter、Facebookなどの有名なソーシャルメディアサイトでコンテンツを共有するためのリンクが含まれています。これらのソーシャルメディアリンクには、ソーシャルメディアリンクに使用される特定のパラメーターが含まれています。
攻撃者は、別のURLパラメーターをリンクに追加して、被害者をクリックして誘い込むことができます。 Hackeroneには、ソーシャルメディアサイトに送信されたPOSTリクエストのパラメーターの変更が含まれているため、脆弱性が生じます。脆弱性レポートで使用される例は、URLを配置することです。
https://hackerone.com/blog/introducing-signal
修正：
https://hackerone.com/blog/introducing-signal?u=3https://vk.com/durov
追加のパラメーターuに注意してください。後続のUパラメーターの値を変更して、被害者を誘い出してソーシャルメディアリンクを介してコンテンツを共有しようとすると、悪意のあるリンクが次のようになります。
https://www.facebook.com/sharer.php?u=https://hackerone.com/blog/introducing-signal?u=https://vk.com/durov
ここでの最後のパラメーターuは、最初のパラメーターよりも優先度が高く、Facebookの公開には後で使用されます。 Twitterに投稿すると、推奨されるデフォルトのテキストも変更されます。
https://hackerone.com/blog/introducing-signal?u=33https://vk.com/durovtext=another_site:3359vk.com/durov
2。 Twitterが登録解除
レポート接続：https://blog.mert.ninja/twitter-hpp-vulnerability/
脆弱性の説明：2015年8月、ハッカーのMert Tasciは、Twitterの受信のケアをキャンセルしたときに興味深いURLに気付きました。
https://twitter.com/i/u?t=1cn=bwvsig=657iid=f6542uid=1134885524nid=22+26
パラメーターUIDはTwitterアカウントUIDである可能性があることに注意してください。これで、彼がほとんどのハッカーがすると思うことに注意を払い、UIDを他のユーザーに変更してみてください。Twitterはエラーを返しました。他の方法が放棄された可能性があることを考慮して、Mertは2番目のUIDパラメーターを追加したため、URLは次のようになります。
https://twitter.com/i/u?iid=f6542UID=2321301342UID=1134885524NID=22+26それから成功しました。彼は他のユーザーのメールリマインダーからの登録を解除することができました。これは、TwitterからのHPP解除の脆弱性があることを示しています。
3。 Twitter Webインテント
レポートリンク：https://ericrafaloff.com/parameter-tampering-attack-on-twitter-web-intents
脆弱性の説明：Archive Twitter Web Intentsによると、Twitterユーザー：Tweet、返信、リツイートなどを処理するためのポップアップ最適化されたデータストリームを提供します。これにより、ユーザーはページを離れたり、新しいアプリの対話を許可することなく、サイトコンテキストでTwitterコンテンツと対話できます。これがその例です：
完全なテストの後、ハッカーのエリック・ラファロフは、4つの意図タイプすべてが、ツイート、転送、ツイートなどのユーザーがすべてHPPの脆弱性を持っていることを発見しました。
2つのscreen_nameパラメーターを持つURLを作成する場合：
https://twitter.com/intent/follow?screen_name=twitterscnreen_name=erictest3
Twitterは2番目のscreen_nameを処理します。これは、最初のscreen_nameよりも優先されます。 Webフォームによると、このようなもの：
form class='follow' id='follow_btn_form'action='/intent/follow？screen_name=er \ icrtest3'method='post'input type=' hidden'name='真正性_token'value=' . '
入力型='hidden'name=' screen_name'value='twitter'
入力型='hidden'name=' profile_id'value='783214'
ボタンclass='button'type='送信'
b/bstrongfollow/strong
/ボタン
/形状
被害者は、screen_name twitterでユーザープロファイルが定義されているのを見ますが、ボタンをクリックすると、erictest3に従います。
同様に、likeの意図を提示する場合、エリックはscreen_nameパラメーターを含めることができることを発見しましたが、このツイートのようには何の関係もありません。
https://twitter.com/intent/like?tweet_id=6616252302978211845screen_name=erictest3
このツイートのように、犠牲者に正しいユーザープロファイルが表示されますが、「フォロー」をクリックした後、erictest3に続きます。
###脆弱性防御
1.HPPは、新しい注入の脆弱性です。この脆弱性を防ぐために、入力パラメーターの形式を確認することに加えて、HTTPプロトコルが同じ名前のパラメーターを許可することを認識する必要もあります。申請プロセス全体で、これを認識し、サービスの特性に従ってそのような状況を正しく処理する必要があります。
2.WAFまたは他のゲートウェイデバイス（IPSなど）に、URLをチェックするときに特別な処理を行わせます。 HTTPプロトコルはURLに同じパラメーターを複数回表示できるようにするため、この特別な治療には過失致死の状況を回避するために注意が必要です。
3.コードレベルでは、Webプログラムを作成するときは、合理的な$ _GETメソッドを介してURLのパラメーター値を取得し、Webサーバーによって返された他の値をプログラムに取得しようとする場合は注意してください。