W liście Haron Media z dnia środa 10 lutego 2010: > On 02/09/2010 11:26 PM, Paweł Stradomski wrote: > > W liście Haron Media z dnia wtorek 09 lutego 2010: > >> In an ideal world, yeah. But it is the very nature of stateless HTTP > >> that is the reason attacks such CSRF exist. > > > > Isn't it more problem with poor browser security policy that allows > > submitting cross-domain forms, submitting forms with javascript (wihtout > > user confirmation) etc. rather than statelessnes of HTTP itself? > > No. Disallowing cross-domain forms would effectively disable a lot of > web services that do not require cross-domain security. For starters, > there are many payment processing services that allow purchase data be > POSTed to their servers which present the CC entry form to the user, > collect the data and callback predetermined merchant URL. The > alternative is collecting and validating CC data yourself on your > servers which requires special certificates (I don't mean SSL, 3D secure > protocols etc....
All payment gateways I've dealt with used redirects (GET), not POSTs. So my application would redirect to payment gateway page, it would do whatever it needs and then redirect back to my page (there were also some direct server- server requests that did not originate from the browser, but it's irrelevant). And GET requests shouldn't be a threat from CSRF point of view, unless dev is stupid enough to have a GET that has side effects (which it shouldn't). > > The most important problem with CSRF is that it is the victim's browser > used, against a web application within single domain! In its simplest > form, an image with vulnerable URL is sufficient (if teh webapp dev was > dumb enough to put a critical command behind a GET request). That way it > is not cross-domain at all, for example in multi user websites, all > pages under one domain, one user posts an image with URL like > /users/delete/123, and when the admin, who is authenticated to the > system, visits the page, the browser sends a valid GET request, along > with all the session cookies, to that URL as if s/he clicked a link to > it deliberately. I once happily "ddosed" a friend application by putting > an image in the forum which SRC'ed to /user/logout. :) That was proof of > concept because he thought I was too paranoid and that no one would care > to exploit it. Ditto. GET having a side effect is a problem in itself, not only CSRF vulnerability. > Single domain POSTed CSRF is possible if XSS exists as well. Just inject > some javascript to dynamically create an autosubmitted form (instead of > an image) and teh result is the same, just for POST. In which case much > more damage can be done, for instance user's password can be changed, or > something even worse. If you can XSS a site, then game over, you need no other vulnerabilities. Just script away whatever you want. > Besides, application security should NOT be put in the > hands of browsers. Too many people use too many different versions of > (unpatched) browsers, and one incident is sufficient to ruin someone's > life. CSRF is a case of confused deputy problem known in the 70s/80s. In my opinion it stems exactly from the fact that browsers perform actions on users behalf where they shouldn't (eg POSTing to arbitrary URLS without user's consent, even though HTTP spec forbids such behaviour). -- Paweł Stradomski -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
