the-web-application-hackers-handbook

394 Chapter 10 n Attacking Back-End Components
When the application server processes this request, it URL-decodes the parameter
values in the normal way. So the value of the ToAccount parameter that the
front-end application receives is as follows:
08447656&clearedfunds=true
If the front-end application does not validate this value and passes it through
unsanitized into the back-end request, the following back-end request is made,
which successfully bypasses the check for cleared funds:
POST /doTransfer.asp HTTP/1.0
Host: mdsec-mgr.int.mdsec.net
Content-Length: 62
fromacc=18281008&amount=1430&toacc=08447656&clearedfunds=true
TRY IT!
http://mdsec.net/bank/48/
NOTE Unlike with SOAP injection, injecting arbitrary unexpected parameters
into a back-end request is unlikely to cause any kind of error. Therefore, a successful
attack normally requires exact knowledge of the back-end parameters
that are being used. Although this may be hard to determine in a blackbox
context, it may be straightforward if the application uses any third-party components
whose code can be obtained and researched.
HTTP Parameter Pollution
HPP is an attack technique that arises in various contexts (see Chapters 12 and
13 for other examples) and that often applies in the context of HPI attacks.
The HTTP specifications provide no guidelines as to how web servers should
behave when a request contains multiple parameters with the same name. In
practice, different web servers behave in different ways. Here are some common
behaviors:
n Use the first instance of the parameter.
n Use the last instance of the parameter.
n Concatenate the parameter values, maybe adding a separator between them.
n Construct an array containing all the supplied values.
In the preceding HPI example, the attacker could add a new parameter to
a back-end request. In fact, it is more likely in practice that the request into
which the attacker can inject already contains a parameter with the name he