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.... But the concept of sessions, as in an identifier that identifies a user is not even built into the HTTP but is used with cookies that contain session ID which is tracked server side. Therein falls apart any notion of stateless HTTP in modern, Web 2.0/3.0 world. 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. 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. Cross-domain POST CSRF are harder to accomplish because the user has to be lured to visit a malicious page (while logged into the attacked site). But, how is the browser to know if the POST request is valid (web services) or not? 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. One way to handle this can be implemented with the Origin and Access-Control-Allow-Origin headers (which afaik only Firefox supports). That might help valid and authorized cross-domain XHR requests, but won't help cross domain POSTed forms, because the only way to allow "Origin" is to track the referrer tag which can be spoofed. One way that might solve this problem AND retrain fully stateless HTTP is extending keep-alive to application level. A user requests a form, the form is sent back on the same TCP connection which expires with keep-alive. The user fills in teh form and POSTs back, all within the single TCP connection. No tokens required, the statelesness is reflected in the fact that the request-response is three-fold and not over until user's submission or end of keep-alive period. But that has to be done at the low level, the TCP level itself, since the server has to receive FIN packet, otherwise an attacker could spoof the "legal" IP with single packet containing POSTed data, not requiring ACK response (which would never come). With HTTPS, the problem is solved automagically, though. Vlad -- 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.
