idnits 2.17.1
draft-ietf-oauth-closing-redirectors-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 04, 2016) is 2997 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Downref: Normative reference to an Informational RFC: RFC 6819
Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 OAuth Working Group J. Bradley, Ed.
3 Internet-Draft Ping Identity
4 Intended status: Best Current Practice A. Sanso
5 Expires: August 7, 2016 Adobe Systems
6 H. Tschofenig
7 February 04, 2016
9 OAuth 2.0 Security: Closing Open Redirectors in OAuth
10 draft-ietf-oauth-closing-redirectors-00.txt
12 Abstract
14 This document gives additional security considerations for OAuth,
15 beyond those in the OAuth 2.0 specification and in the OAuth 2.0
16 Threat Model and Security Considerations.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on August 7, 2016.
35 Copyright Notice
37 Copyright (c) 2016 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2
54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
55 2. Authorization Server Error Response . . . . . . . . . . . . . 3
56 2.1. Abuse: The Authorization Server As Open Redirector . . . 3
57 2.2. Security Compromise: The Authorization Server As Open
58 Redirector . . . . . . . . . . . . . . . . . . . . . . . 4
59 2.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 5
60 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
61 4. Normative References . . . . . . . . . . . . . . . . . . . . 6
62 Appendix A. Document History . . . . . . . . . . . . . . . . . . 6
63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
65 1. Introduction
67 This document gives additional security considerations for OAuth,
68 beyond those in the OAuth 2.0 specification [RFC6749] and in the
69 OAuth 2.0 Threat Model and Security Considerations [RFC6819]. In
70 particular focuses its attention on the risk of abuse the
71 Authorization Server (AS) (Section 1.2) as an open redirector.
73 It contains the following content:
75 o Describes the Authorization Server Error Response as defined in
76 [RFC6749].
77 o Describes the risk of abuse the Authorization Server as an open
78 redirector.
79 o Gives some mitigation details on how to hinder the risk of open
80 redirector in the ?AS?.
82 1.1. Notational Conventions
84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
86 document are to be interpreted as described in RFC 2119 [RFC2119].
88 Unless otherwise noted, all the protocol parameter names and values
89 are case sensitive.
91 1.2. Terminology
93 Authorization Server (AS)
94 The server issuing access tokens to the client after successfully
95 authenticating the resource owner and obtaining authorization.
97 Redirection endpoint
98 Used by the authorization server to return responses containing
99 authorization credentials to the client via the resource owner
100 user-agent.
102 2. Authorization Server Error Response
104 The OAuth 2.0 specification [RFC6749] defines the Error Response
105 associated with the Authorization Code Grant flow and the Implicit
106 Grant flow. Both flows use a redirection endpoint where the resource
107 owner's user agent is directed after the resource owner has completed
108 interacting with the authorization server. The redirection endpoint
109 is also used in the error response scenario. As per RFC6749
110 Section 4.1.2.1 and 4.2.2.1 [RFC6749] if the resource owner denies
111 the access request or if the request fails for reasons other than a
112 missing or invalid redirection URI, the ?AS? redirects the user-agent
113 by sending the following HTTP response:
115 HTTP/1.1 302 Found Location: https://client.example.com/
116 cb?error=access_denied
118 2.1. Abuse: The Authorization Server As Open Redirector
120 As described in [RFC6819] an attacker could utilize a user's trust in
121 an ?AS? to launch a phishing attack. The attack described here
122 though is not mitigated using the countermeasures listed in
123 [RFC6819]. In this scenario the attacker:
125 o Performs a client registration as per the core specification
126 [RFC6749]. The provided redirection URI is a malicious one e.g.
127 https://attacker.com (namely the one where the victim's user agent
128 will land without any validation)
130 o Prepare a forged URI using the assumption that the ?AS? complies
131 with the OAuth 2.0 specification [RFC6749]. In particular with
132 the ?AS? Error Response described in the previous section (
133 Section 2 ). As an example he can use a wrong or not existing
134 scope e.g.
136 https://AUTHORIZATION_SERVER/authorize?response_type=code&client_i
137 d=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fattacker%2Ecom&s
138 cope=INVALID_SCOPE
140 o Attempt the pishing attack trying to have the victim clicking the
141 forged URI prepared on the previous step. Should the attack
142 succeeds the victim's user agent is redirected to
143 https://attacker.com (all with any user interaction) The HTTP
144 referer header will be set to the AS domain perhaps allowing
145 manipulation of the user.
147 2.2. Security Compromise: The Authorization Server As Open Redirector
149 The attacker can use a redirect error redirection to intercept
150 redirect based protocol messages via the Referer header and URI
151 fragment. In this scenario the attacker:
153 o Performs a registration of a malicious client as per the core
154 specification [RFC6749]. The provided redirection URI is a
155 malicious one e.g. https://attacker.com (This URI will capture
156 the fragment and referer header sent as part of the error)
158 o Creates a invalid Authentication request URI for the malicious
159 client. As an example he can use a wrong or not existing scope
160 e.g.
162 https://AUTHORIZATION_SERVER/authorize?response_type=code&client_i
163 d=malicious_client&redirect_uri=https%3A%2F%2Fattacker%2Ecom&scope
164 =INVALID_SCOPE
166 o If the AS supports sticky grants (not re-prompting for consent
167 based on a previous grant) a valid authentication request for the
168 user may also be used to trigger a 30x redirect.
170 o Performs a OAuth Authorization request using the invalid
171 Authorization request as the redirect_uri. This works if the AS
172 is pattern matching redirect_uri and has a public client that
173 shares the same domain as the AS.
175 (line breaks for display only)
177 https://AUTHORIZATION_SERVER/authorize?response_type=token
178 &client_id=good-client&scope=VALID_SCOPE
179 &redirect_uri=https%3A%2F%2AUTHORIZATION_SERVER%Fauthorize
180 %3Fresponse_type%3Dcode
181 %26client_id%3Dattacker-client-id
182 %26scope%3DINVALID_SCOPE
183 %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com
185 Figure 1
187 o Receive the response redirected to https://attacker.Com
188 The legitimate OAuth Authorization response will include an access
189 token in the URI fragment.
191 Most web browsers will append the fragment to the URI sent in the
192 location header of a 302 response if no fragment is included in the
193 location URI.
195 If the Authorization request is code instead of token, the same
196 technique is used, but the code is leaked by the browser in the
197 referer header rather than the fragment.
199 This causes the access token from a successful authorization to be
200 leaked across the redirect to the malicious client. This is due to
201 browser behaviour and not because the AS has included any information
202 in the redirect URI other than the error code.
204 Protocols other than OAuth may be particularly vulnerable to this if
205 they are only verifying the domain of the redirect. Performing exact
206 redirect URI matching in OAuth will protect the AS, but not other
207 protocols.
209 It should be noted that a legitimate OAuth client registered with a
210 AS might be compromised and used as a redirect target by an attacker,
211 perhaps without the knowledge of the client site. This increases a
212 the attack surface for a ?AS?.
214 2.3. Mitigation
216 In order to defend against the attacks described in Section 2.1 and
217 Section 2.2 the ?AS? can either:
219 o Respond with an HTTP 400 (Bad Request) status code.
221 o Perform a redirect to an intermediate URI under the control of the
222 AS to clear referer information in the browser that may contain
223 security token information. This page SHOULD provide notice to
224 the resource owner that an error occurred, and request permission
225 to redirect them to an external site.
227 If redirected, a fragment "#" MUST be appended to the error
228 redirect URI. This prevents the browser from reattaching the
229 fragment from a previous URI to the new location URI.
231 Some
233 When redirecting via 30x a Content Security Policy header SHOULD be
234 added:
236 Content-Security-Policy: referrer origin;
238 Figure 2
240 When redirecting via a form post the following tag SHOULD be
241 included:
243
245 Figure 3
247 Only newer browsers support these headders, so users with older
248 browsers will be vulnerable to leaking referer information unless a
249 intermediate redirect is used.s
251 3. Acknowledgements
253 We would like to thank all the people that partecipated to the
254 discussion, namely Bill Burke, Hans Zandbelt, Justin P. Richer, Phil
255 Hunt, Takahiko Kawasaki, Torsten Lodderstedt, Sergey Beryozkin.
257 4. Normative References
259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
260 Requirement Levels", BCP 14, RFC 2119,
261 DOI 10.17487/RFC2119, March 1997,
262 .
264 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
265 RFC 6749, DOI 10.17487/RFC6749, October 2012,
266 .
268 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
269 Threat Model and Security Considerations", RFC 6819,
270 DOI 10.17487/RFC6819, January 2013,
271 .
273 Appendix A. Document History
275 [[ to be removed by the RFC Editor before publication as an RFC ]]
277 -01
279 o Added information on HTTP headders to include to set referrer to
280 origin
282 -00
283 o Wrote the first draft.
285 o Changed Document name to conform to WG naming convention
287 o Added Section on redirect leaking security information
289 o Added Terminology section
291 o fixed file name
293 o cleaned up mitigations a bit
295 Authors' Addresses
297 John Bradley (editor)
298 Ping Identity
300 Phone: +1 202-630-5272
301 Email: ve7jtb@ve7jtb.com
302 URI: http://www.thread-safe.com/
304 Antonio Sanso
305 Adobe Systems
307 Email: asanso@adobe.com
309 Hannes Tschofenig
311 Email: Hannes.Tschofenig@gmx.net
312 URI: http://www.tschofenig.priv.at