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
