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:
Found this link on web app sec newsgroup. Great point. We are evaluating application scanners this month and this adds a feature to help the evaluation!
ReplyDeleteThis is a good point. We recognized this few years ago. Dynamic creation of URL's is often needlessly messy even if there are no security issues.
ReplyDeleteIt is usually quite easy to abstract and isolate the URL creation. This makes the code cleaner and facilitates reviewing the code for possible security problems simultaneously. Win-win, no downside.