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
