Hi William Agree it is a good definition but I am not sure we need to spell out more details as we are trying to keep this section tight. Developers can look up CSRF if they are unsure. However, I will add the example of how it can happen
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated _(e.g., via HTTP redirects or HTML forms)_. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. Regards Mark "William J. Mills" <wmi...@yahoo-inc.com> wrote on 01/06/2011 00:17:44: > From: > > "William J. Mills" <wmi...@yahoo-inc.com> > > To: > > Mark Mcgloin/Ireland/IBM@IBMIE, "oauth@ietf.org" <oauth@ietf.org> > > Date: > > 01/06/2011 00:17 > > Subject: > > Re: [OAUTH-WG] Draft 16 Security Considerations additions > > http://tools.ietf.org/html/rfc6265#section-8.2 has good text on CSRF > definition, which I think is clearer. Perhaps that can be used to > touch up your first paragraph? > > From: Mark Mcgloin <mark.mcgl...@ie.ibm.com> > To: oauth@ietf.org > Sent: Tuesday, May 31, 2011 1:58 PM > Subject: [OAUTH-WG] Draft 16 Security Considerations additions > > Eran > > Here are some additional sections to add to the next draft under security > considerations > > CSRF > Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP > requests are transmitted from a user that the website trusts or has > authenticated. CSRF attacks on OAuth approvals can allow an attacker to > obtain authorization to OAuth Protected Resources without the consent of > the User. > The state parameter should be used to mitigate against CSRF attacks, > particularly for login CSRF attacks. It is strongly RECOMMENDED that the > client sends the state parameter with authorization requests to the > authorization server. The authorization server will send it in the response > when redirecting the user to back to the client which SHOULD then validate > the state parameter matches on the response. > > Clickjacking > Clickjacking is the process of tricking users into revealing confidential > information or taking control of their computer while clicking on seemingly > innocuous web pages. In more detail, a malicious site loads the target site > in a transparent iframe overlaid on top of a set of dummy buttons which are > carefully constructed to be placed directly under important buttons on the > target site. When a user clicks a visible button, they are actually > clicking a button (such as an "Authorize" button) on the hidden page. > To prevent clickjacking (and phishing attacks), native applications SHOULD > use external browsers instead of embedding browsers in an iFrame when > requesting end-user authorization. For newer browsers, avoidance of iFrames > can be enforced server side by using the X-FRAME-OPTION header. This header > can have two values, deny and sameorigin, which will block any framing or > framing by sites with a different origin, respectively. For older browsers, > javascript framebusting techniques can be used but may not be effective in > all browsers. > > > Regards > Mark > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
