On 3/5/2012 8:28 AM, [email protected] wrote: > On Thu, 01 Mar 2012 15:15:21 -0500 > RS Tech<[email protected]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mason-users
