" using a DOM variable (protected by JavaScript or other DOM-binding language's enforcement of SOP)"
This is not clear without a reference or more details description. EHL > -----Original Message----- > From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com] > Sent: Wednesday, July 06, 2011 8:56 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org; Torsten Lodderstedt > Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions > > 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 <e...@hueniverse.com> wrote on 04/07/2011 20:02:02: > > > From: > > > > Eran Hammer-Lahav <e...@hueniverse.com> > > > > To: > > > > Mark Mcgloin/Ireland/IBM@IBMIE, Torsten Lodderstedt > <tors...@lodderstedt.net> > > > > Cc: > > > > "oauth@ietf.org" <oauth@ietf.org> > > > > 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 <mark.mcgl...@ie.ibm.com> > > Date: Wed, 1 Jun 2011 11:28:33 -0700 > > To: Torsten Lodderstedt <tors...@lodderstedt.net> > > Cc: "oauth@ietf.org" <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> wrote on 01/06/2011 > 09:11:31: > > > > From: > > > > Torsten Lodderstedt <tors...@lodderstedt.net> > > > > To: > > > > Mark Mcgloin/Ireland/IBM@IBMIE > > > > Cc: > > > > 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 > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > 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
