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 <mark.mcgl...@ie.ibm.com<mailto:mark.mcgl...@ie.ibm.com>> Date: Wed, 1 Jun 2011 11:28:33 -0700 To: Torsten Lodderstedt <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> Cc: "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> 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 <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> wrote on 01/06/2011 09:11:31: From: Torsten Lodderstedt <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> To: Mark Mcgloin/Ireland/IBM@IBMIE Cc: oauth@ietf.org<mailto:oauth@ietf.org> 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 > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
