idnits 2.17.1 draft-bradley-oauth-open-redirector-01.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 (March 23, 2015) is 3321 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (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 3 Internet-Draft Ping Identity 4 Intended status: Standards Track A. Sanso, Ed. 5 Expires: September 24, 2015 Adobe Systems 6 H. Tschofenig 8 March 23, 2015 10 OAuth 2.0 Security: OAuth Open Redirector 11 draft-bradley-oauth-open-redirector-01.txt 13 Abstract 15 This document gives additional security considerations for OAuth, 16 beyond those in the OAuth 2.0 specification and in the OAuth 2.0 17 Threat Model and Security Considerations. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 24, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Authorization Server Error Response . . . . . . . . . . . . . 3 57 2.1. Abuse: The Authorization Server As Open Redirector . . . 3 58 2.2. Security Compromise: The Authorization Server As Open 59 Redirector . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Normative References . . . . . . . . . . . . . . . . . . . . 6 63 Appendix A. Document History . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 This document gives additional security considerations for OAuth, 69 beyond those in the OAuth 2.0 specification [RFC6749] and in the 70 OAuth 2.0 Threat Model and Security Considerations [RFC6819]. In 71 particular focuses its attention on the risk of abuse the 72 Authorization Server (AS) (Section 1.2) as an open redirector. 74 It contains the following content: 76 o Describes the Authorization Server Error Response as defined in 77 [RFC6749]. 78 o Describes the risk of abuse the Authorization Server as an open 79 redirector. 80 o Gives some mitigation details on how to hinder the risk of open 81 redirector in the ?AS?. 83 1.1. Notational Conventions 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 Unless otherwise noted, all the protocol parameter names and values 90 are case sensitive. 92 1.2. Terminology 94 Authorization Server (AS) 95 The server issuing access tokens to the client after successfully 96 authenticating the resource owner and obtaining authorization. 98 Redirection endpoint 99 Used by the authorization server to return responses containing 100 authorization credentials to the client via the resource owner 101 user-agent. 103 2. Authorization Server Error Response 105 The OAuth 2.0 specification [RFC6749] defines the Error Response 106 associated with the Authorization Code Grant flow and the Implicit 107 Grant flow. Both flows use a redirection endpoint where the resource 108 owner's user agent is directed after the resource owner has completed 109 interacting with the authorization server. The redirection endpoint 110 is also used in the error response scenario. As per RFC6749 111 Section 4.1.2.1 and 4.2.2.1 [RFC6749] if the resource owner denies 112 the access request or if the request fails for reasons other than a 113 missing or invalid redirection URI, the ?AS? redirects the user-agent 114 by sending the following HTTP response: 116 HTTP/1.1 302 Found Location: https://client.example.com/ 117 cb?error=access_denied 119 2.1. Abuse: The Authorization Server As Open Redirector 121 As described in [RFC6819] an attacker could utilize a user's trust in 122 an ?AS? to launch a phishing attack. The attack described here 123 though is not mitigated using the countermeasures listed in 124 [RFC6819]. In this scenario the attacker: 126 o Performs a client registration as per the core specification 127 [RFC6749]. The provided redirection URI is a malicious one e.g. 128 https://attacker.com (namely the one where the victim's user agent 129 will land without any validation) 131 o Prepare a forged URI using the assumption that the ?AS? complies 132 with the OAuth 2.0 specification [RFC6749]. In particular with 133 the ?AS? Error Response described in the previous section ( 134 Section 2 ). As an example he can use a wrong or not existing 135 scope e.g. 137 https://AUTHORIZATION_SERVER/authorize?response_type=code&client_i 138 d=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fattacker%2Ecom&s 139 cope=INVALID_SCOPE 141 o Attempt the pishing attack trying to have the victim clicking the 142 forged URI prepared on the previous step. Should the attack 143 succeeds the victim's user agent is redirected to 144 https://attacker.com (all with any user interaction) The HTTP 145 referer header will be set to the AS domain perhaps allowing 146 manipulation of the user. 148 2.2. Security Compromise: The Authorization Server As Open Redirector 150 The attacker can use a redirect error redirection to intercept 151 redirect based protocol messages via the Referer header and URI 152 fragment. In this scenario the attacker: 154 o Performs a registration of a malicious client as per the core 155 specification [RFC6749]. The provided redirection URI is a 156 malicious one e.g. https://attacker.com (This URI will capture 157 the fragment and referer header sent as part of the error) 159 o Creates a invalid Authentication request URI for the malicious 160 client. As an example he can use a wrong or not existing scope 161 e.g. 163 https://AUTHORIZATION_SERVER/authorize?response_type=code&client_i 164 d=malicious_client&redirect_uri=https%3A%2F%2Fattacker%2Ecom&scope 165 =INVALID_SCOPE 167 o If the AS supports sticky grants (not re-prompting for consent 168 based on a previous grant) a valid authentication request for the 169 user may also be used to trigger a 30x redirect. 171 o Performs a OAuth Authorization request using the invalid 172 Authorization request as the redirect_uri. This works if the AS 173 is pattern matching redirect_uri and has a public client that 174 shares the same domain as the AS. 176 (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 189 The legitimate OAuth Authorization response will include an access 190 token in the URI fragment. 192 Most web browsers will append the fragment to the URI sent in the 193 location header of a 302 response if no fragment is included in the 194 location URI. 196 If the Authorization request is code instead of token, the same 197 technique is used, but the code is leaked by the browser in the 198 referer header rather than the fragment. 200 This causes the access token from a successful authorization to be 201 leaked across the redirect to the malicious client. This is due to 202 browser behaviour and not because the AS has included any information 203 in the redirect URI other than the error code. 205 Protocols other than OAuth may be particularly vulnerable to this if 206 they are only verifying the domain of the redirect. Performing exact 207 redirect URI matching in OAuth will protect the AS, but not other 208 protocols. 210 It should be noted that a legitimate OAuth client registered with a 211 AS might be compromised and used as a redirect target by an attacker, 212 perhaps without the knowledge of the client site. This increases a 213 the attack surface for a ?AS?. 215 2.3. Mitigation 217 In order to defend against the attacks described in Section 2.1 and 218 Section 2.2 the ?AS? can either: 220 o Respond with an HTTP 400 (Bad Request) status code. 222 o Perform a redirect to an intermediate URI under the control of the 223 AS to clear referer information in the browser that may contain 224 security token information. This page SHOULD provide notice to 225 the resource owner that an error occurred, and request permission 226 to redirect them to an external site. 228 If redirected, the fragment "#_=_" MUST be appended to the error 229 redirect URI. This prevents the browser from reattaching the 230 fragment from a previous URI to the new location URI. 232 When redirecting via 30x a Content Security Policy header SHOULD be 233 added: 235 Content-Security-Policy: referrer origin; 237 Figure 2 239 When redirecting via a form post the following tag SHOULD be 240 included: 242 244 Figure 3 246 Only newer browsers support these headders, so users with older 247 browsers will be vulnerable to leaking referer information unless a 248 intermediate redirect is used.s 250 3. Acknowledgements 252 We would like to thank all the people that partecipated to the 253 discussion, namely Bill Burke, Hans Zandbelt, Justin P. Richer, Phil 254 Hunt, Takahiko Kawasaki, Torsten Lodderstedt, Sergey Beryozkin. 256 4. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, March 1997. 261 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 262 6749, October 2012. 264 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 265 Threat Model and Security Considerations", RFC 6819, 266 January 2013. 268 Appendix A. Document History 270 [[ to be removed by the RFC Editor before publication as an RFC ]] 272 -01 274 o Added information on HTTP headders to include to set referrer to 275 origin 277 -00 279 o Wrote the first draft. 281 o Changed Document name to conform to WG naming convention 283 o Added Section on redirect leaking security information 285 o Added Terminology section 287 o fixed file name 289 o cleaned up mitigations a bit 291 Authors' Addresses 293 John Bradley 294 Ping Identity 296 Email: ve7jtb@ve7jtb.com 297 URI: http://www.thread-safe.com/ 299 Antonio Sanso (editor) 300 Adobe Systems 302 Email: asanso@adobe.com 304 Hannes Tschofenig 306 Email: Hannes.Tschofenig@gmx.net 307 URI: http://www.tschofenig.priv.at