HPP: HTML Parameter Pollution paper

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!

本文转hackfreer51CTO博客，原文链接：http://blog.51cto.com/pnig0s1992/502451，如需转载请自行联系原作者