Re: [Mason] Post/Get collection 'collapse'
On Fri, 02 Mar 2012 12:25:12 -0800 Paul Wallingford p...@cybergestalt.net wrote: 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. This is an interesting read, and I agree that this may be a problem, but its most potent use seems to be exposing either a forgotten URL-encode, or a validation or logic error of sorts in the author's code. Both must be combined with social engineering to work. HPWI SUMMARY ON POST/GET COLLAPSE: Some web frameworks collapse the POST and GET parameters into a single collection. This is a flawed design pattern from a security standpoint. If a page accepts POST parameters as GET parameters an attacker would be able to effect change on websites through Cross-Site Request Forgery or leverage this design flaw with other vulnerabilities to attack the system hosting the web application. I can understand why they are saying it is flawed, but it has little to do with CSRF (except making it a tad easier) What I think it is saying that, let's say you have a forums software with a POST/GET collapse and you forget to explicitly check for POST in one of the functions. If so, an attacker can compose a post that embeds an image link that (say) deletes the user's account. If a user visits a thread that contains that post, his account will be deleted. (Alternatively, the attacker may have posted a link to the deletion via a URL-shortener and it would have had a similar effect.) What this did was exposed a pre-existing vulnerability (lack of POST checking) to create a worse CSRF situation. If this collapse was not in effect, the attacker would have had to inject javascript (much harder) or get a user to visit an external link to trigger this vulnerability. If there had been CSRF checks in place (e.g. Please enter your password to delete your account), the POST/GET collapse would not have affected a thing. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
Re: [Mason] Post/Get collection 'collapse'
On 03 Mar 2012, at 16:18 , hha...@gmail.com wrote: The GET/POST thing indeed has nothing to do with CSRF: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Prevention_Measures_That_Do_NOT_Work Here's another very nice, easy-reading description of CSRF that people may find useful: http://en.wikipedia.org/wiki/Cross-site_request_forgery Regards Paolo -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
Re: [Mason] Post/Get collection 'collapse'
On 3/5/2012 8:28 AM, hha...@gmail.com wrote: On Thu, 01 Mar 2012 15:15:21 -0500 RS Techt...@rubystudio.com wrote: 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? So, um, what I was trying to get at with the last mail was that, it can aggravate existing vulnerabilities, but it is not in itself a vulnerability. Since most of these attacks happen by someone posting a link that the browser will follow, such as an image, most of the time the request comes from a GET. By keeping all parameters and tagging them with their source, your app can say that this parameter is designed to only come from a POST and can discard the malicious parameters that were sent via a GET (via the image link). This is not the same as only accepting POSTS, as the link states that is a false solution. The reason is that is an attacker can employ javascript, they can construct a link that fires off a javascript AJAX call to the destination site, so the parameters will look like they cam from a POST, which, in fact, they did. The GET/POST problem is that blindly mixing all arguments, you do not know if the GET overwrites the POST or converts it to an array ref, and withing that array ref, you do not know which came from where. Filtering out the GETs and just looking at the POSTs helps a lot with the static CSRF links, but not so much with the dynamic. I agree that this is less of a problem than, say, requiring users have a password no longer than three characters, all of which much be a 3 or a G. However, it should still be defended against. I would modify their suggestion about tokens. Instead of a session token, I would change the token each and every form request and as soon as a form post comes in with that token, it gets invalidated. The reason for this is that, while I do not have an example, if an attacker can get information from the browser history / cache, then they can extract the secret token and dynamically include that in the CSRF link. This may require javascript, or some exploit of the new HTML 5 history / file API. However, exploits that extract browser history information are available without the HTML 5 part. By not reusing tokens from form to form and invalidating tokens as they are used (or whenever a new one is generated), you reduce your vulnerability to just forms that were requested, but the user did not submit. Maybe they closed their browser, thinking they were done with their online work, or maybe their browser crashed. Having a valid token expire after a period of time also helps reduce the window of vulnerability. http://www.w3.org/TR/FileAPI/ Cheers. Paul Wallingford -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
Re: [Mason] Post/Get collection 'collapse'
Hi, On Thu, Mar 1, 2012 at 8:15 PM, RS Tech t...@rubystudio.com 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? Please correct me if I'm wrong but I think the POST/GET parameter mixing is a red herring. CRSF attacks are dangerous but the solution is making sure the attacker lacks a piece of information that the real user has. When generating a form for the real client to submit, add a hidden parameter with a cryptographic secure one-use-only token, and stash the same token in the user session, server-side. All form submissions must include that parameter, and it must match the token in the session. Unless the attacker has access to the original form (and then the attack is not CRSF but Man-In-The-Middle, a whole different problem), any fform submissions by the attackers will lack the token, and therefore will fail the token in session check, and will be denied, no matter where the parameters come from. So XSS, CRSF, cross-site attacks have well studies properties and a solution. Just use it. As for the other nefarious parameter injection from GET into POST'ed data, like including the same parameter on GET and POST, it really is not import problem if you: * validate your parameters properly; * match the HTTP method used with the action requested. So if you expect a single value for parameter X and receive two, send back a 400 Bad Request code to the client. I've been reading about Mason2 (more about that in another post, but so far I'm loving it) and the fact that you define component arguments as Moose attributes, including type (and opening the possibility to use coercion and type validations) might allow Mason2 to generate the proper HTTP response. As for HTTP method checks (not allowing form submissions that change your model over HEAD or GET for example), you can use the if ($http_method eq 'POST') to protect your code. I've used this and a small button_action() helper function to deal with multiple submit buttons in the same form with success. But I do agree with Dave Rolsky that HTTP method differentiation is one place where the Mason dispatcher lacks flexibility. Maybe we could somehow add %http post and %http get blocks, and allow the dispatcher to decline other methods with 405 if no match is found, but right now you have to hand-coded it. But I don't know if this limitation is sufficient for me to use another layer for routing/controller before Mason though. It all depends on what features do you loose from Mason as a view, if you stop using Mason as the dispatcher/controller... Maybe you don't loose much, or maybe what you loose is not important to you. It depends. I still maintain two large Mason1 applications, and one of them is being slowly rebuilt. After using Catalyst, Dancer and Mojo on other projects, I've decided to use Mason2 on the new version at least for the backoffice site. I still on the fence about using Mason2 on the frontend client-facing site, because I also miss a bit of flexibility from the Mason2 dispatcher/controller layer, like the HTTP method stuff. Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ http://about.me/melo xmpp:m...@simplicidade.org mailto:m...@simplicidade.org -- 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
Re: [Mason] Post/Get collection 'collapse'
On Thu, 1 Mar 2012, 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. Basically every web framework in the world does this (at least in the Perl world). You _can_, if you like, distinguish between the two by using the underlying API (CGI.pm, mod_perl's Apache2::Request, Catalyst::Request). I think the issue here is not so much the collapsing the parameters, but whether you can use a get request to submit a form, for example. In other words, does this work ... img src=/bad/action?x=42 / The way to avoid this is to make a point of distinguishing between GET and POST when handling form submissions. This issue really isn't specific to Mason, though if you use Mason exclusively (as opposed to as part of Catalyst/Dancer/etc) you'll get no help in handling this. With Catalyst and Catalyst::Action::REST, it's trivial to designate controller actions that can only be reached via POST. In other words, dispatching can be done based on a combination of URI and HTTP method, rather than just the URI. You can fake this in Mason with something like this ... %init dont_accept_request() unless $r-method eq 'POST'; handle_form_submission(); /%init Just make sure that every form handling component goes through this logic (an autohandler is your friend). But I'll say for the millionth time, I think something like Catalyst is much better for the controller/dispatch side of things, and this is one reason among many. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */ -- 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
Re: [Mason] Post/Get collection 'collapse'
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=aparameter=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
Re: [Mason] Post/Get collection 'collapse'
On Fri, 2012-03-02 at 12:06 -0600, Dave Rolsky wrote: On Thu, 1 Mar 2012, 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. Basically every web framework in the world does this (at least in the Perl world). You _can_, if you like, distinguish between the two by using the underlying API (CGI.pm, mod_perl's Apache2::Request, Catalyst::Request). I think the issue here is not so much the collapsing the parameters, but whether you can use a get request to submit a form, for example. In other words, does this work ... img src=/bad/action?x=42 / Thanks for the response, Dave. HP WebInspect locates form element names in POST forms and attempts to insert them via GET. If it can, it generates the error. According to HPWI's auto-generated explanation, this causes a site to be potentially vulnerable to something called a Cross-Site Request Forgery: For anyone interested, here's HPWI's generic description of the issue: HPWI SUMMARY ON POST/GET COLLAPSE Some web frameworks collapse the POST and GET parameters into a single collection. This is a flawed design pattern from a security standpoint. If a page accepts POST parameters as GET parameters an attacker would be able to effect change on websites through Cross-Site Request Forgery or leverage this design flaw with other vulnerabilities to attack the system hosting the web application. /HPWI SUMMARY The way to avoid this is to make a point of distinguishing between GET and POST when handling form submissions. This issue really isn't specific to Mason, though if you use Mason exclusively (as opposed to as part of Catalyst/Dancer/etc) you'll get no help in handling this. With Catalyst and Catalyst::Action::REST, it's trivial to designate controller actions that can only be reached via POST. In other words, dispatching can be done based on a combination of URI and HTTP method, rather than just the URI. You can fake this in Mason with something like this ... %init dont_accept_request() unless $r-method eq 'POST'; handle_form_submission(); /%init The same occurred to me after mailing to the list -- placed a routine at the top of init in affected scripts to do essentially as you say: unless method = POST, redirect to error page. This satisfies the mindless vulnerability checker and does add a degree of control to the form handling. Just make sure that every form handling component goes through this logic (an autohandler is your friend). Thanks -- yes, will put routine into an autohandler over the weekend. But I'll say for the millionth time, I think something like Catalyst is much better for the controller/dispatch side of things, and this is one reason among many. I agree with you that Catalyst (et al) is a better solution for control/dispatch -- and if I was building the site today I'd likely opt for same. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */ -- 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 -- 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
Re: [Mason] Post/Get collection 'collapse'
On 03/02/2012 03:25 PM, Paul Wallingford wrote: 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=aparameter=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
[Mason] Post/Get collection 'collapse'
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 -- 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
