Once identified, the analyst will start injecting malicious data into those fields, something like:
Cookie: --attack string--
name= --attack string--
uri?name= --attack string--
EVERYTHING injected in the parameter's value, what about parameter's name? Does it worth?
Why a Developer would like to validate the input receive in the parameter's name?
As any other vulnerability, there are specific scenarios where this can be exploited, the most common one is when all the parameters received via GET or POST are used to generated a new URL:
java.util.Enumeration e = request.getParameterNames();
if (e.hasMoreElements()) {
String name = (String)e.nextElement();
String value = request.getParameter(name);
qs= name+"="+java.net.URLEncoder. encode(value,"utf-8");
while (e.hasMoreElements()) {
name = (String)e.nextElement();
value = request.getParameter(name);
qs += "&"+name+"="+java.net. URLEncoder.encode(value,"utf- 8");
}
}
**** Notice only the parameter's value is being URLEncoded*************
Then, the Query String is concatenated in the iframe src attribute:
So, let's try to inject XSS into parameter's name, like:
%22%20onmouseover%3d"alert(1111)">%20DANUX</iframe> <iframe a%3D"=
Which will print out in the browser as:
<iframe src="xxxx.com?search.aspx?" onmouseover="alert(1111)">DANUX</iframe> <iframe a=""></iframe>
The text highlighted in RED is the portion completed automatically by the application and you can see the html is properly formatted causing the XSS code being executed successfully, tested on FireFox 12.0.
As mentioned before, parameter's name injection is not widely tested by Security Analyst, not even by some Security Vendors, I tested my vulnerable App with WebInspect version 9.X and realized it does NOT test parameter's name: