HPP方法主要用於服務器兩層架構，其基本結構情況如下圖所示：
服務器端有兩個部分：第一部分爲 tomcat 爲引擎的 jsp 型服務器，第二部分爲 apache爲引擎的 php 服務器，真正提供 web 服務的是 php 服務器。工作流程爲：client 訪問服務器，能直接訪問到 tomcat 服務器，然後 tomcat 服務器再向 apache服務器請求數據。數據返回路徑則相反。
所以重點：index.php?id=1&id=2，到底是顯示 id=1 的數據還是顯示 id=2 的？
Explain：apache（php）解析最後一個參數，即顯示 id=2 的內容。Tomcat（jsp）解析第一個參數，即顯示 id=1 的內容。
對於幾個主要的服務器，其對多個參數的獲取情況歸納如下：
所以對於第一張圖中的服務器配置情況，如果發送index.jsp?id=1&id=2請求，客戶端請求首先過 tomcat，tomcat 解析第一個參數，接下來 tomcat 去請求 apache（php）服務器，apache 解析最後一個參數。那最終返回客戶端的應該是哪個參數？
Answer：此處應該是 id=2 的內容，應爲時間上提供服務的是 apache（php）服務器，返回的數據也應該是 apache 處理的數據。而在我們實際應用中，也是有兩層服務器的情況，那爲什麼要這麼做？是因爲我們往往在 tomcat 服務器處做數據過濾和處理，功能類似爲一個 WAF（Web Application Firewall）。而正因爲解析參數的不同，我們此處可以利用該原理繞過 WAF 的檢測。該用法就是 HPP（HTTP Parameter Pollution），http 參數污染攻擊的一個應用。HPP 可對服務器和客戶端都能夠造成一定的威脅。
下面我們來看下實戰情況,首先我們發送兩個參數，發現其接收的是最後一條信息，如圖：
對於單個jsp/tomcat服務器來說多個參數應該是接收第一個，也就是id=1的，這裏接收了第二個，因此可以得知其服務器架構不單是一個tomcat，通過代碼也可發現其架構是apache+tomcat，所以我們直接以這種架構爲基礎開始注入攻擊。因爲接收的是第二個參數數據，第一個數據被過濾，所以我們可以在第二個參數中注入，如圖：
剩下就可以愉快地自行注入了。