Hello, I always see some resistance from product teams to implements CSRF protection with the argument that This attacks requires too many prerequisites. User has to logged-in. Has to be enticed to click on some link. Has to click on that link etc etc. I know that social engineering is prevalent and enticing is not very remote possibility. But want to know how do you guys impart importance of CSRF among your product teams? Are you aware of any exploitation method other than social engineering/link enticing? I am interested in knowing thoughts about this and not about technical details of exploitation as I am aware of them. Thanks, Rohit Pitke

Hi, On 04/27/2011 06:24 PM, Rohit Pitke wrote: > Hello, > > I always see some resistance from product teams to implements CSRF > protection with the argument that > > This attacks requires too many prerequisites. User has to logged-in. > Has to be enticed to click on some link. Has to click on that link etc > etc. Yep, but it only needs to happen once and as time passes the chances of happening will steadily go up. > > I know that social engineering is prevalent and enticing is not very > remote possibility. > > But want to know how do you guys impart importance of CSRF among your > product teams? > Are you aware of any exploitation method other than social > engineering/link enticing? > Worst case scenario is that a high-traffic website has been compromised (using XSS for example) so as to realize an attack against a CSRF vulnerable site. So if -- let's say -- PayPal is vulnerable to CSRF and Slashdot had been made to include a piece of JS that requests Paypal to transfer money from a user's account to the account of evil.attacker@mail.com then every Paypal user that visits Slashdot will be robbed. And since Slashdot has a ridiculous amount of traffic and a high percentage of the visitors will have Paypal accounts the attacker will be able to retire to the Barbados. Cheers, Tasos L. > I am interested in knowing thoughts about this and not about technical > details of exploitation as I am aware of them. > > Thanks, > Rohit Pitke > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

* CSRF is possible without XSS
* CSRF is not limited to GET requests
* CSRF is not limited to dynamic content
* CSRF does not (always) require GET or POST parameters
* CSRF can either be on same site or on another site (no SOP)
* CSRF does not require any active scripting in the browser
* CSRF is not limited to cookie-based sessions (Basic/Digest Auth. and
  even Card-Readers can be vulnerable)
* idempotent actions can be vulnerable
* CSRF does not require clicking something

Am 27.04.11 19:24, schrieb Rohit Pitke: > Hello, > > I always see some resistance from product teams to implements CSRF protection > with the argument that > This attacks requires too many prerequisites. User has to logged-in. Has to be > enticed to click on some link. Has to click on that link etc etc. There're a couple of myths about exploitability and proper protection of CSRF around. Folowing applies if not proper protected: * CSRF is possible without XSS * CSRF is not limited to GET requests * CSRF is not limited to dynamic content * CSRF does not (always) require GET or POST parameters * CSRF can either be on same site or on another site (no SOP) * CSRF does not require any active scripting in the browser * CSRF is not limited to cookie-based sessions (Basic/Digest Auth. and even Card-Readers can be vulnerable) * idempotent actions can be vulnerable * CSRF does not require clicking something Some of the above need proper implementation of business logic, while some require a proper protection mechanism. I.g. both is necessary to inhibit CSRF. > I know that social engineering is prevalent and enticing is not very remote > possibility. As CSRF can often be hidden anywhere, it works without social engineering. > But want to know how do you guys impart importance of CSRF among your product > teams? > Are you aware of any exploitation method other than social engineering/link > enticing? > > I am interested in knowing thoughts about this and not about technical details > of exploitation as I am aware of them. Hope this helps to strengthen the threat. Achim

In addition to what's been mentioned already by the fine folks before this email, remember that CSRF can also be exploited within the intranet itself: there's also the insider problem needs to be considered too. Ray. On Thu, Apr 28, 2011 at 5:09 AM, Achim Hoffmann <websec10@sic-sec.org> wrote: > Am 27.04.11 19:24, schrieb Rohit Pitke: >> Hello, >> >> I always see some resistance from@ product teams to implements CSRF protection >> with the argument that >> This attacks requires too many prerequisites. User has to logged-in. Has to be >> enticed to click on some link. Has to click on that link etc etc. > > There're a couple of myths about exploitability and proper protection of CSRF > around. Folowing applies if not proper protected: > >        * CSRF is possible without XSS >        * CSRF is not limited to GET requests >        * CSRF is not limited to dynamic content >        * CSRF does not (always) require GET or POST parameters >        * CSRF can either be on same site or on another site (no SOP) >        * CSRF does not require any active scripting in the browser >        * CSRF is not limited to cookie-based sessions (Basic/Digest Auth. and >          even Card-Readers can be vulnerable) >        * idempotent actions can be vulnerable >        * CSRF does not require clicking something > > Some of the above need proper implementation of business logic, while some > require a proper protection mechanism. I.g. both is necessary to inhibit CSRF. > >> I know that social engineering is prevalent and enticing is not very remote >> possibility. > > As CSRF can often be hidden anywhere, it works without social engineering. > >> But want to know how do you guys impart  importance of CSRF among your product >> teams? >> Are you aware of any exploitation method other than social engineering/link >> enticing? >> >> I am interested in knowing thoughts about this and not about technical details >> of exploitation as I am aware of them. > > Hope this helps to strengthen the threat. > Achim > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >