HTTPパラメータ汚染攻撃とはどんな攻撃？

HTTPパラメータ汚染攻撃とはリクエストに追加のパラメータを挿入して意図しない挙動を引き起こす攻撃です。
以前もプロトタイプ汚染攻撃と名称が似た脆弱性を紹介させて頂きましたが似ているのは名前と知名度の低さぐらいで別物と考えた方が良いです。
Railsやlaravelで有名なMassAssignmentが近そうと思った方は勘が良いです。
MassAssignmentはそのユーザに対して本来許可すべきでないデータ項目を変更できる脆弱性です。
HTTPパラメータ汚染攻撃は攻撃手法で、結果としてMassAssignmentとなる可能性もありますし別の結果となる可能性もあります。
代表的なリスクは以下の通りです。

・他者(他社)のリソースを改ざん、閲覧される
・必要な検証がスキップされ条件を満たさない処理が受け入れられ不正利得される
・その権限では本来実行できない管理機能など高権限の処理を不正に実行できる

どちらもあまり有名ではないようですがHTTPパラメータ汚染攻撃はTwiiterを初め有名なサービスや私が診断したサービスでも何度か報告したことがある脆弱性です。

HTTPパラメータ汚染攻撃とは不正に追加したパラメータで悪事を行う攻撃である

HTTPパラメータ汚攻撃の検証方法

一番簡単なのは同じパラメータの別値のセットをもう一個追加し処理をリクエストすることです。
次にクライアントサイドのバリデーションで弾かれている若しくはグレーアウトして送らないパラメータを付加して，サーバがパラメタが取り込んで処理することを利用して不正利用を行う方法、
そして、%26(URLエンコードした＆)を悪用する方法、&myparameter=deleteのように文字符号などの変換を悪用する方法などです。
こんなので脆弱性あるサービスなんてあるのかと疑問に思われるかもしれませんが、繰り返しますがTwiiterを初め有名なサービスや私が診断したサービスでも何度か報告したことがあり脆弱性です。
脆弱性診断では逆に制御パラメータを値とセットで削ってしまい処理が通るか確認するようにすると効率的に作業ができます。

HTTPパラメータ汚攻撃対策

基本的な対策は以下の通りです。

処理元から受け入れるべきパラメータ以外の値は無視し処理に利用しない
%26が&を特殊な解釈をされないように入力値検証で削除、無効化する

&でスプリットしてパラメータの値として受け入れないこと、そのユーザ（のロール）で許可されるアクションか検証することも前提となります。
上記に加えて機能追加や改修の失敗などで脆弱性が露見する可能性も踏まえ、いつ誰がどんな処理を「どのリソースに対して」行ったかログを取ることが責任追跡性の観点から実施すべきです

原則は必要なパラメータのみか検証して処理する。責任追跡性の観点からログは取る

参考になれば幸いです。