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