Saturday, July 28, 2012

Post/Get Parameter's Name Injection

When testing Web Applications, usually a security analyst will try to identify all the inputs to be injected like Cookies, POST/GET parameters, HTTP Headers, etc.

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+"=","utf-8");
        while (e.hasMoreElements()) {
            name = (String)e.nextElement();
            value = request.getParameter(name);
            qs += "&"+name+"=","utf-8");

**** Notice only the parameter's value is being URLEncoded*************

Then, the Query String is concatenated in the iframe src attribute:

<iframe src="<%=qs%>

 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="" 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:


  1. 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!

  2. This 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.

    It 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.


Note: Only a member of this blog may post a comment.