On 3/1/2012 12:15 PM, RS Tech wrote: > A client just sent me a web security report for a Mason-based site I > built for him a while ago (Mason 1.38). The report, which was generated > by HP WebInspect, complains that form scripts on the site are not > distinguishing between POST and GET parameters. A summary of the problem > is provided, explaining that 'collapsing' POST and GET params into a > single collection exposes the site to XSS and other attacks. > > I'd like to get list users' thoughts on the degree of vulnerability > represented. Is there a best practice way of dealing with this issue? > > Thanks, > MM
Hello, I did some research into this. It is a bit obscure and information is not easy to find. I believe the scan is referencing HTTP Parameter Pollution (HPP). See: http://www.iseclab.org/people/embyte/slides/BHEU2011/hpp-bhEU2011.pdf Essentially, it comes down to how the application or framework handles multiple sources of the same parameter. There are several ways an attacker can pollute the parameters. Example 1: original: http://domain.com/page.html?parameter=a attacker: http://domain.com/page.html?parameter=a¶meter=b - How is this handled? - Do you keep "a", "b", somehow combine them both, or can the one that gets kept be somehow pseudorandom? (Pseudorandom behavior can result if a hash is used during processing since the order of keys is based on a complex hashing algorithm which is specifically designed to scramble key order, in order to facilitate even distribution). - Do you even have control over this, or are you "handed" a value by your framework so you are oblivious that an attempted attack even occurred? - How are your parameters parsed? - Are you looking specifically for "?" and "&" since these can be obscured? - Will you miss the above attack if the URL looks like: http://domain.com/page.html?parameter=a%26parameter%3Db You might be handed, and take action based on, the value "b" which could be anything the attacker chooses, when your app was expecting "a". Example 2: The same is true if your normally expect to get parameters from a POST, but your framework combines GET and POST parameters before handing them to your app. A misconception among many developers is that POST requests are more secure and thus more trusted. This is because POST parameters do not go into the server logs and do not show up in the URL line. However, in many circumstances, it is just as easy for an attacker to generate a POST as to add parameters to a GET. So many of the same questions apply: - If a POST has parameter=a (the real one) and the GET has ...?parameter=b (from the attacker), how does your app or framework handle it? - Does the GET take precedence, or the POST, are they somehow combined, or is the one that is kept, pseudorandom? The reverse is true. If you normally have parameters on the command line (GET), the attacker can use Javascript and optionally one of the frameworks like jQuery if it is running on the page, to generate AJAX requests. From a browser standpoint, AJAX is partial page updates, but from the server standpoint, an AJAX call is nothing more than a GET or POST. Basically, it is possible to inject POST parameters, when you were expecting only GET parameters. Example 3: Another vector of this attack is if you store parameters in a cookie. I do not believe this is the default behavior of Mason and is generally a bad idea. However, if you store a session key in a cookie such as sess=12345678 and in your app add that to the same hash that stores your GET and POST parameters you will be vulnerable. The attacker can add sess=ABCDEFGH to the GET request and hijack another session. It has always bothered me that Mason and many other systems combine GET and POST parameters, but I was able to ignore that since it did not adversely affect my apps. However, based on these newly discovered vulnerabilities, the defense is the following: 1) Always know where your parameters come from and make sure they come from an expected source. 2) Do not blindly discard data. If three copies of "parameter" come from a GET, keep all three and decide how to handle it. If you only expect one copy, it is probably best to reject the entire query as a possible hacking attempt. If you get one from GET and one from POST, same logic: keep both tagged where they came from, then in your form analysis logic, reject the entire query as a possible hack attempt. As Dave Rolsky said, a lot of frameworks treat parameters rather sloppily. However, until fairly recently, doing so was not known to be a security problem and it made things simpler for the web developer. These frameworks will need to be changed to accommodate these new defenses and the changes cannot be backward compatible with the old behavior, since the old behavior is vulnerable to attack. In the meantime, a quick patch, if your app only expects to get parameters via POST, is to disallow GET parameters altogether. If you have the option of specifying this in your framework, then use it. If you are using CGI to initiate Mason, then you can delete the QUERY_STRING environment variable in your Mason handler, so CGI.pm and Mason never see it. Or, if you need GET parameters for certain operations, then within the mason handler, read QUERY_STRING and make sure it only contains parameters that you are expecting, erasing the rest, then store the sanitized results back in QUERY_STRING (although this is not as good as disallowing it altogether). If you use mod_perl, then you will need to do handle more of this in your app. HOWEVER, in all the above cases of disallowing GET parameters, you will still need to test if multiple copies of a parameter came in via the POST mechanism. All parameters that you expect only one copy, you should specify as scalars. Then check if they are a reference to an array, since Mason 1 does this for you when it sees multiple copies of a parameter that is specified as a scalar (see Mason book page 35). Dave Rolsky's suggestion is a good start, but it is still vulnerable to the following (action was modified by the attacker to add x=evil_value): <form method="post" action="/formhandler.mhtml?x=evil_value"> <input type="hidden" name="x" value="real_value"> <input type="submit" value="Submit"> </form> $r->method reports this as POST, but it is still vulnerable and you may not know that you received two versions of the same parameter and which one you were handed by the framework. A lot of the vulnerability comes down to your app's handling of the situation, but the framework can make it easier or more difficult. I recommend you get the specifics from the scan, try to duplicate it yourself and plan how to fix it, if it indeed is a vulnerability. Cheers. Paul Wallingford ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
