HPP can be used to create unusual behaviour in applications
Which can typically end up giving weaknesses or possible attack vectors in the application

ASP.NET/IIS:
What it parses: All occurences of a given parameter
Example: parameter1=value1,value2

ASP/IIS
What it parses: All occurences of a given parameter
Example: par1

PHP/Apache
What it parses: Last occurrence of a given parameter
Example: parameter1=value2

PHP/Zeus
What it parses: Last occurence of a given parameter
Example: parameter1=value2

JSP/Tomcat
What it parses: First Occurence of given variable
Example: parameter1=value1

JSP/Oracle server
What it parses: First occurence of a given variable
Example: parameter1=value1

JSP/Jetty
What it parses: First occurence of a given variable
Example: parameter1=value1

IBM Lotus Domino
What it parses: Last occurence of a given variable
Example: parameter1=value2

IBM HTTP
What it parses: First occurence of given variable
Example: parameter1=value1

Perl(module),libapreq2/Apache
What it parses: First occurence of given variable
Example: parameter1=value1

Perl CGI/Apache
What it parses: First occurence of given variable
Example: parameter1=value1

Perl(module),lib?/Apache
What it parses: Becomes an array
Example: ARRAY(0x8b9059c)

python(module)/Apache
What it parses: First occurence of given variable
Example: parameter1=value1

Python/Zope
What it parses: Becomes an array
Example: ['value1','value2']

IceWarp
What it parses: Last occurence of given variable
Example: parameter1=value2

DBMan
What it parses: All occurences of given variable
Example: parameter1=value1~~value2

Some things HPP can help achieve:

* Gaining knowledge about the webserver and technologies used
* Gaining directory information
* Obfuscating logs with false entries
* Dumping cgi information

And many more things...

The attacks are structed by manipulating how the server processes parameters in the URL
Such as for DBMan:
Entering the url: http://address/cgi-b...
Would dump an error message quoting:


  CGI ERROR
 
----------------------------------------------------------
 
Error Message : Debug Information
 
Script Location       : location of db.cgi
 
Perl Version  : version
 
Setup File    : configuration file
 
Session ID    : aaaa~~bbbb
 
 
Form Variables
 
-----------------------------------------------------------
  db            
: default
  uid          
: aaaa~~bbbb
 
 
Environment Variables
 
-----------------------------------------------------------
  DOCUMENT_ROOT
: document root
  GATEWAY_INTERFACE    
: CGI/1.1
 


The use of GET/POST/Cookie may modify expected application behaviors and it can be used to override parameters



So here's an example situation also from AppsecEU09:


This being the source code of the application:



 
void private executeBackendRequest(HTTPRequest request){
   
String amount=request.getParameter("amount");
   
String beneficiary=request.getParameter("recipient");

   
HttpRequest("http://backendServer.com/servlet/actions","POST","action=transfer&amount="<font color="red">+amount+</font>"&recipient="<font color="red">+beneficiary</font>);

A malicious user may send a request like:



 http
://frontendHost.com/page?amount=1000&recipient=Mat%26action%3dwithdraw


Then, the frontend will build the following back-end request:



 
HttpRequest("http://backendServer.com/servlet/actions","POST","action=transfer&amount="+amount+"&recipient="+beneficiary);

Which translates too:



 action
=transfer&amount=1000&recipient=Mat&action=withdraw


This can even be used to bypass Web application firewalls:


Whenever the environment concatenates multiple occurrences (e.g. ASP, ASP.NET, DBMan), an aggressor can split the payload


The user would send



 http
://mySecureApp/db.cgi?par=<Payload_1>&par=<Payload_2>


This would result in:



 par
=<Payload_1>~~<Payload_2>

Being parsed and result in the server running the mal-payload, resulting in mass pwnage



Not only are web application firewalls not safe, but neither is mod_rewrite if not configured correctly!


Badly configured rules:



 
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\.+page\.php.*\HTTP/
 
RewriteRule ^page\.php.*$ -[F,L]
 
RewriteCond %{REQUEST_FILENAME} !-f
 
RewriteCond %{REQUEST_FILENAME} !-d
 
RewriteRule ^([^/]+)$ page.php?action=view&page=$1&id=0 [L]

Where

http://address/string

becomes:


http://address/page....

So therefore a hacker could exploit this with:



 http
://host/string%26action%3dedit

And the url will be rewritten as:



 http
://host/page.php?action=view&page=abc&action=edit&id=0


This can be used in conjunction to bypass current restrictions and perform attacks such as:


* XSS


* FPI


* SQL Injection


* RFI/LFI



And can be furthered to obfuscate logs



Defense



Take into mind:



* Application business logic


* Technology used(PHP, ASP etc)


* Data validation (as usual!)


* Output encoding


* Filtering is the key to defend our systems!


* Don't use HtmlEntities. They're out of context!Instead, apply URL Encoding


* Use strict regexp in URL Rewriting


* Know your application environment!