HTTP Parameter Pollution
Past, Present, Future
SEaCURE.it ‐ 23 October 2009 – Milan
Luca Carettoni
Independent Researcher
luca.carettoni@ikkisoft.com
Stefano di Paola
CTO @ Minded Security
stefano.dipaola@mindedsecurity.com

About us
Luca “ikki” Carettoni
Penetration Testing Specialist in a worldwide financial institution
Security researcher for fun (and profit)
OWASP Italy contributor
I blog @ http://blog.nibblesec.org
Keywords: web application security, ethical hacking, Java security
Stefano “wisec” Di Paola
CTO @ Minded Security Application Security Consulting
Director of Research @ Minded Security Labs
Lead of WAPT & Code Review Activities
OWASP Italy R&D Director
Sec Research (Flash Security, SWFIntruder...)
2
WebLogs http://www.wisec.it, http://blog.mindedsecurity.com

Agenda
Introduction
Server enumeration
Bizarre behaviors
HPP in a nutshell
HPP Categories
Server side attacks
Concept and Real world examples
Client side attacks
Concept and Real world examples
How to detect HPP issues?
FAQs
Conclusions
DISCLAIMER: This is an updated version of our previous OWASP AppSec
2009 presentation. New tricks and hacks are included!

Fact
In modern web apps, several application layers are
involved

Consequence
Different input validation vulnerabilities exist
SQL Injection
LDAP Injection
XML Injection
XPath Injection
Command Injection
All input validation flaws are caused by unsanitized data
flows between the front‐end and the several back‐ends
of a web application
Anyway, we still miss something here !?!
_ _ _ Injection

An unbelievable story…
Before our first presentation @OWASP AppSec Poland
2009, there was no formal definition of an injection
triggered by query string delimiters
HPP is surely around since many years, however it is
definitely underestimated
As a result, several vulnerabilities have been discovered in
real‐world applications
Further researches have to investigate business logic
flaws triggered by HPP. As we know, it is tricky and time
consuming since manual testing is required

Introduction 1/2
The term Query String is commonly used to
refer to the part between the “?” and the end
of the URI
As defined in the RFC 3986, it is a series of
field‐value pairs
Pairs are separated by “&” or “;”
The usage of semicolon is a W3C
recommendation in order to avoid escaping
RFC 2396 defines two classes of characters:
Unreserved: a‐z, A‐Z, 0‐9 and _ . ! ~ * ' ( )
Reserved: ; / ? : @ & = + $ ,

Introduction 2/2
GET and POST HTTP request
GET /foo?par1=val1&par2=val2 HTTP/1.1 POST /foo HTTP/1.1
User-Agent: Mozilla/5.0 User-Agent: Mozilla/5.0
Host: Host Host: Host
Accept: */* Accept: */*
Content-Length: 19
par1=val1&par2=val2
Query String meta characters are &, ?, #, ; , = and
equivalent (e.g. using encoding)
In case of multiple parameters with the same
name, HTTP back‐ends behave in several ways

Server enumeration ‐ List

Server enumeration ‐ Summing up
Different web servers manage multiple
occurrences in several ways
Some behaviors are quite bizarre
Whenever protocol details are not strongly
defined, implementations may strongly differ
Unusual behaviors are a usual source of
security weaknesses (MANTRA!)

A bizarre behavior 1/4

A bizarre behavior 2/4

A bizarre behavior 3/4

A bizarre behavior 4/4
Since this error generates
~100 lines in the log file, it
may be used to obfuscate
other attacks

HPP in a nutshell
HTTP Parameter Pollution (HPP) is a quite simple but
effective hacking technique
HPP attacks can be defined as the feasibility to override or
add HTTP GET/POST parameters by injecting query string
delimiters
It affects a building block of all web technologies thus server‐
side and client‐side attacks exist
Exploiting HPP vulnerabilities, it may be possible to:
Override existing hardcoded HTTP parameters
Modify the application behaviors
Access and, potentially exploit, uncontrollable variables
Bypass input validation checkpoints and WAFs rules

HPP Categories
Classification:
Client‐side
First order HPP or Reflected HPP
Second order HPP or Stored HPP
Third order HPP or DOM Based HPP
Server‐side
Standard HPP
Second order HPP
According to our classification, Flash Parameter
Injection* may be considered as a particular
subcategory of the HPP client‐side attack
* http://blog.watchfire.com/FPI.ppt

Encoding & Parameters precedence
Several well‐known
encoding techniques
may be used to inject
malicious payloads
The precedence of
GET/POST/Cookie may Apache Tomcat/6.0.18
POST /foo?par1=val1&par2=val2 HTTP/1.1
influence the Host: 127.0.0.1
application behaviors
par3=val3&par4=val4
and it can also be used FIRST occurrence, GET parameter first
to override parameters

HPP Server Side Attacks 1/2
Suppose some code as the following:
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="+amount+"&recipient="+beneficiary
);
}
Which is the attack surface?

HPP Server Side Attacks 2/2
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);
action=transfer&amount=1000&recipient=Mat&action=withdraw
Obviously depends on how the application will manage
the occurrence

HPP Server Side Attacks ‐ Flow

HPP Server Side ‐ WAFs evasion
What would happen with WAFs that do Query String parsing
before applying filters?
Some loose WAFs may analyze and validate a single parameter
occurrence only (first or last one)
Whenever the devel environment concatenates multiple
occurrences (e.g. ASP, ASP.NET, AXIS IP Cameras, DBMan, …),
an aggressor can split the malicious payload
http://mySecureApp/db.cgi?par=<Payload_1>&par=<Payload_2>
par=<Payload_1>~~<Payload_2>
E.g. ModSecurity default core rules bypass
“Split and Join” by Lavakumar Kuppan
http://packetstormsecurity.nl/papers/attack/parameter‐pollution.pdf

HPP Server Side – URL Rewriting
URL Rewriting could be affected as well if
regexp are too permissive:
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]
http://host/abc
becomes:
http://host/page.php?action=view&page=abc&id=0

HPP Server Side – URL Rewriting
An attacker may try to inject:
http://host/abc%26action%3dedit
and the url will be rewritten as:
http://host/page.php?action=view&page=abc&action=edit&id=0
Once again, the impact depends on the
functionality exposed
23

Real World
Examples
Server Side Attacks

Google Search Appliance
Once upon a time, during an assessment for XXX…
GSA was the LAN search engine exposed for public search as well, with
only three controllable values
The parameter named “afilter” is used unencoded
By polluting GSA parameters, appending %23 (“#”), we got full access to
internal results. Pls note, this is not a GSA vulnerability!

Information leakage in Python 1/3
In Python, multiple occurrences of the same parameter generate a list
type object
In case of hardcoded functions that are not applicable to such object type,
the application may generate an exception and, consequently,
information disclosure
This is not an issue within the Python framework. Developers have to
properly handle unexpected errors as well as to avoid information leakage
In these real‐world examples, an aggressor can easily retrieve file system
paths, application source code, SQL queries, …

Information leakage in Python 2/3

Information leakage in Python 3/3

PayPal NVP API 1/4
PayPal NVP API is a programmatic interface that allows interaction with PayPal’s
business functionalities
PayPal NVP API is available for several programming languages such as ASP,
ASP.NET, PHP, Java, etc.
PayPal API requires a registered username/password and, either a signature or a
certificate, in order to identify the requestor
Example of a “GetBalance” operation:
METHOD=GetBalance&VERSION=51.0&PWD=<OMITTED>&USER=<OMITTED> &SIGNATURE=<OMITTED>
GetBalance Completed Successfully: Array
(
[L_AMT0] => 35770864%2e46
[L_CURRENCYCODE0] => USD
[TIMESTAMP] => 2009%2d10%2d19T10%3a04%3a42Z
[CORRELATIONID] => eab6e62b5727b
[ACK] => Success
[VERSION] => 51%2e0
[BUILD] => 1073465
)

PayPal NVP API 2/4
PayPal warns developers about potential problems.
“The request and response are URL‐encoded. URL‐encoding ensures that you can
transmit special characters, characters that are not allowed in a URL, and
characters that have special meaning in a URL, such as the equal sign and
ampersand.”
Source: https://cms.paypal.com/uk/cgi‐bin/?cmd=_render‐content&content_ID=developer/e_howto_api_soap_NVPAPIOverview
However, developers are fully responsible here. A simple mistake may cause a
critical security issue, as we are going to demonstrate
PhpNVPCodeGenerate/RefundTransaction.php is a sample script provided by
PayPal in order to speed up the API integration
In this code, $memo is declared but not included within an “urlencode()” function
(it is not used in such specific script).
What about an innocent cut&paste within your own application?

PayPal NVP API 3/4
Original “RefundTransaction” (using an invalid transaction id)

PayPal NVP API 3/4
Tampered “RefundTransaction”
&METHOD=MassPay&EMAILSUBJECT=example_email_subject&RE
CEIVERTYPE=EmailAddress&CURRENCYCODE=USD&L_EMAIL0=u
ser0%4a0paypal.com&L_Amt0=1&L_UNIQUEID0=example_unique_id
&L_NOTE0=example_noteo&L_EMAIL1=user1%40paypal.com&L_Am
t1=1&L_UNIQUEID1=example_unique_id&L_NOTE1=example_noteo
&L_EMAIL2=user2%40paypal.com&L_Amt2=10000&L_UNIQUEID2=e
xample_unique_id&L_NOTE2=example_noteo

HPP Client Side attacks 1/2
HPP Client Side is about injecting additional
parameters to links and other src attributes
Suppose the following code:
<? $val=htmlspecialchars($_GET['par'],ENT_QUOTES); ?>
<a href="/page.php?action=view&par='.<?=$val?>.'">View Me!</a>
There's no XSS, but what about HPP?
It’s just necessary to send a request like
http:/host/page.php?par=123%26action=edit
To obtain
<a href="/page.php?action=view&par=123&amp;action=edit">View Me!</a>

HPP Client Side attacks 2/2
Once again, it strongly depends on the
functionalities of a link or form
It's more about
Anti‐CSRF
Functional UI Redressing
It could be applied on every tag with
Data, SRC, HREF attributes
Action forms with POST method

HPP Client Side attacks – Example
with Anti CSRF tokens 1/2
Suppose a Web GUI using Anti CSRF Tokens
// Jsp Example http://host/page.jsp?folder=inbox
<form action=“/servlets/addUser.do?folder=<%=HtmlEntities(request.getParameter(‘folder’))%>”>
<input type=“hidden” name=“tok” value=‘<%=getCSRFToken()%>’>
<input type=“hidden” name=“cmd” value=“add”>
<input type=text name=“user” value=“”>
<input type=“submit” value=“add User”>
</form>
If an attacker sends the link to the victim:
http://host/page.jsp?folder=inbox%26action%3duser=EvilUser

HPP Client Side attacks ‐ Example
with Anti CSRF tokens 2/2
Whatever user the victim add the value is overriden (In
case of J2ee), since the action is going to be:
// Jsp Example http://host/page.jsp?folder=inbox
<form action=“/servlets/addUser.do?folder=inbox&amp;user=EvilUser”>
Since the Anti CSRF token is still there the action will be
executed.
Yes, depending on what cmd parameter allows to do, the
attacker could also modify/override the cmd parameter.

HPP Client Side attacks ‐ Example
with Anti Tampering HMAC
Suppose there’s an antitampering solution which
appends a HMAC based signature:
// http://host/shownews.php?showall=yes
<a href=“<?=Hmac(“/printnews.php?id=2&showall=”+$_GET [“showall” ] +””)?>” >print</a>
// http://host/shownews.php?showall=yes
<a href=“/printnews.php?id=2&showall=yes&hmac=89042ab23e65f4543e93” >print</a>
Yes, we can still try with HPP to tamper ‘id’ par by sending
http://host/shownews.php?showall=yes%26id=2+or+3=3
If the server takes the second occurrence then is still possible
to tamper the id parameter

HPP Client Side ‐ DOM based
It's about parsing unexpected parameters
It's about the generation of client side HPP via JavaScript
It's about the use of (XMLHttp)Requests on polluted pars
// It considers the first occurrence // It considers the last occurrence
function gup( name ) function argToObject () {
{ var sArgs = location.search.slice(1).split('&');
name = name.replace(/[[]/,"[").replace(/[]]/,"]"); var argObj={};
var regexS = "[?&]"+name+"=([^&#]*)"; for (var i = 0; i < sArgs.length; i++) {
var regex = new RegExp( regexS ); var r=sArgs[i].split('=')
var results = regex.exec( window.location.href ); argObj[r[0]]=r[1]
if( results == null ) }
return ""; return argObj
else }
return results[1];
}

Real World
Examples
Client Side Attacks

Excite.it 1/2
Features:
Several parameters could be HPPed
Anti XSS using htmlEntities countermeasures
DOM HPP + Client Side HPP friendly!
http://search.excite.it/image/
?q=dog&page=1%26%71%
3d%66%75%63%6b%6f%
66%66%20%66%69%6e%
67%65%72%26%69%74%
65%6d%3d%30

Excite.it 2/2
Sweet dogs? Clicking on an image...
This is a kind of “content pollution”
Even if the example seems harmless, it may help to
41
successfully conduct social engineering attacks

Yahoo! Mail Classic
Features
Check antiCSRF
Dispatcher View
Html Entities filtering, antiXSS
HPP compliant! /* now fixed */
The dispatcher pattern helps the attacker
%26DEL=1%26DelFID=Inbox%26cmd=fmgt.delete
%2526cmd=fmgt.emptytrash
Attack payload:
http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=d
own&tt=245&pSize=25&startMid=0%2526cmd=fmgt.emptytrash%
26DEL=1%26DelFID=Inbox%26cmd=fmgt.delete

How to detect server‐side HPP? 1/2
Detect HPP issues is tricky and prone to false positive
Most of the time, an in‐depth business logic knowledge
is required. Automatic tools can only assist auditors
A simple detector can act as a proxy for web clients,
issuing arbitrary HTTP requests and analyzing server
responses
(1) file?par1=val1
(2) file?par1=HPP
(3) file?par1=val1&par1=HPP
If (3) != (1) and (3) != (2) possible HPP
Several other heuristics can be used. Encoding, double
encoding, etc. should be considered too

How to detect server‐side HPP? 2/2
Enhanced web application flaws detectors (with
HPP capability) added to the latest Nessus
This is used to detect client‐side weakness too
A few other commercial and open source tools
have included this check (e.g. Cenzic)
ModSecurity added the following rule to the CRS
v.2.0.0:
SecRule ARGS_NAMES ".*" "chain,phase:2,t:none,nolog,pass,capture,setvar:'tx.arg_name_%{tx.0}=+1',msg:‘
Multiple Parameters with the same Name.'"
SecRule TX:/ARG_NAME_*/ "@gt 1"

How to detect client‐side HPP? 1/2
For each parameter value add %26PATTERN
Search in Html response if attributes like:
Data, SRC, HREF attributes
Action in forms
Have %26PATTERN in their value displaying some
way like:
&PATTERN
&amp;PATTERN
If it is so, then begin to think what can be done :)

How to detect client‐side HPP? 2/2
Also, DOM based applications could be prone to
parameter injection
Check for Query String parameter later used in
XHR
Runtime attribute creation
Client side HPP could be also affect Flash
Parameters , applets and other client side plugins
So pay attention also to FlashVars and similar
proprietary attributes.

Countermeasures
Speaking about HPP, several elements should be
considered:
Application business logic
Technology used
Context
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!

URL encoding reference
ASP
Server.URLEncode
ASP.NET
System.Web.HttpUtility.UrlEncode
System.Web.HttpUtility.UrlDecode
Java
java.net.URLEncoder.encode
java.net.URLDecoder.decode
PHP
urlencode()
urldecode()

Three FAQs
Q: Most of your examples and findings use GET. What about POST ?
A: POST and COOKIE parameters may be affected as well. It is a
very interesting aspect since it gives additional flexibility for all
attacks
Q: HPP is only about WAFs bypasses?
A: Absolutely not! HPP is also about applications flow
manipulation, anti‐CSRF, content pollution
Q: Is this a new class of exploits or just another case of applications
lacking input validation?
A: Actually, HPP is an input validation flaw. As SQL Injection and
XSS, we may consider it as an injection weakness. In this specific
case, query string delimiters are the "dangerous" characters

Conclusion
HPP affects server side as well client side components
The impact could vary depending on the affected
functionalities
HPP requires further researches in order to deeply
understand threats and risks
Several applications are likely vulnerable to HPP
Standard and guidelines on multiple occurrences of a
parameter in the QueryString should be defined
Awareness for application developers is crucial

Go and exploit HPP flaws !
/* ethically */