Reworded to modify the text around secret and some additional info on redirect-uri (with some input from Shane Weaden) and adding state in dynamic redirect-uri (with input from Torsten)
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. CSRF attacks against a client's redirect URI allow an attacker to inject their own authorization code (or access token for implicit grant flow). This may result in the client using an access token associated with the attackers account rather than the victims. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. It is strongly RECOMMENDED that the client sends the state parameter with authorization requests to the authorization server. The state parameter MUST be non-guessable and the client MUST be capable of keeping it in a location accessible only by the client or the user agent (i.e., protected by same-origin policy). e.g.: DOM variable (protected by _javascript_ or other DOM-binding language's enforcement of SOP), HTTP cookie, HTML5 client-side storage, etc. The authorization server will send it in the response when redirecting the user to back to the client which MUST then validate the state parameter matches on the response. Use of the state parameter by a client protects against this style of attack as the attacker cannot know the state parameter associated with the victims browser session at the client. While sending the state parameter is the preferred mechanism for linking the client to the authorization requests and callbacks, a state parameter (s) embedded into the redirect uri could be used for the same purpose. A prerequisite is that the authorization server's uri validation policy must allow for dynamic uri query parts. 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 Eran Hammer-Lahav <[email protected]> wrote on 04/07/2011 20:02:02: > From: > > Eran Hammer-Lahav <[email protected]> > > To: > > Mark Mcgloin/Ireland/IBM@IBMIE, Torsten Lodderstedt <[email protected]> > > Cc: > > "[email protected]" <[email protected]> > > Date: > > 04/07/2011 20:01 > > Subject: > > Re: [OAUTH-WG] Draft 16 Security Considerations additions > > This needs to be reworked to reflect reality. The state value must > be shared with the resource owner's browser and authorization > server, so it is not really a secret known only to the client… > > EHL > > From: Mark Mcgloin <[email protected]> > Date: Wed, 1 Jun 2011 11:28:33 -0700 > To: Torsten Lodderstedt <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions > > Hi Torsten > > It was implicit that the state parameter would be secret and not guessable > but that it probably worth spelling out, as you and Breno state. Here is a > modified version > > 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 state parameter MUST be non-guessable and MUST be > a secret only accessible to the client. The authorization server will send > it in the response when redirecting the user to back to the client which > MUST then validate the state parameter matches on the response. > > Regards > Mark > > Torsten Lodderstedt <[email protected]> wrote on 01/06/2011 09:11:31: > > From: > > Torsten Lodderstedt <[email protected]> > > To: > > Mark Mcgloin/Ireland/IBM@IBMIE > > Cc: > > [email protected] > > Date: > > 01/06/2011 09:11 > > Subject: > > Re: [OAUTH-WG] Draft 16 Security Considerations additions > > Hi Mark, > > Am 31.05.2011 22:58, schrieb Mark Mcgloin: > > 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. > > As far as I understand, the goal of the countermeasure is to bind the > authz flow to a certain user agent (instance). So client must verify > that the state parameter (or any other URL parameter?) matches some data > found in the user agent itself before further processing the authz code. > > Breno explained it as follows: > ----- > - Client or user-agent generates a secret. > - The secret is stored in a location accessible only by the client or > the user agent (i.e., protected by same-origin policy). E.g.: DOM > variable (protected by javascript or other DOM-binding language's > enforcement of SOP), HTTP cookie, HTML5 client-side storage, etc. > - The secret is attached to the state before a request is issued by the > client > - When the response is received, before accepting the token or code, the > client consults the user agent state and rejects the response altogether > if the state does not match the user agent's stored value. > ---- > > I would suggest to incorporate this into the decription: > > It is strongly RECOMMENDED that the client sends the state parameter > with authorization requests to the authorization server. _The state > parameter MUST refer to a secret value retained at the user agent._ > The authorization server will send the _state parameter_ in the > response when redirecting the user to back to the client which > _MUST_ then validate the state parameter_'s value against the secret > value in the user agent_. > > regards, > Torsten. > > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
