idnits 2.17.00 (12 Aug 2021) /tmp/idnits58698/draft-oauth-sanso-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 20, 2015) is 2671 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) == Unused Reference: 'RFC5226' is defined on line 228, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6819 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 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 24, 2015 Adobe Systems 6 H. Tschofenig 8 January 20, 2015 10 OAuth 2.0 Security: OAuth Open Redirector 11 draft-oauth-sanso-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 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 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 . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Normative References . . . . . . . . . . . . . . . . . . . . 5 62 Appendix A. Document History . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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 an open redirector. It contains the 72 following content: 74 o Describes the Authorization Server Error Response as defined in 75 [RFC6749]. 77 o Describes the risk of abuse the Authorization Server as an open 78 redirector. 80 o Gives some mitigation details on how to hinder the risk of open 81 redirector in the Authorization Server. 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 2. Authorization Server Error Response 94 The OAuth 2.0 specification [RFC6749] defines the Error Response 95 associated with the Authorization Code Grant flow and the Implicit 96 Grant flow. Both flows use a redirection endpoint where the resource 97 owner's user agent is directed after the resource owner has completed 98 interacting with the authorization server. The redirection endpoint 99 is also used in the error response scenario. As per [RFC6749] if the 100 resource owner denies the access request or if the request fails for 101 reasons other than a missing or invalid redirection URI, the 102 authorization server redirects the user-agent by sending the 103 following HTTP response: 105 HTTP/1.1 302 Found Location: https://client.example.com/ 106 cb?error=access_denied 108 2.1. Abuse: The Authorization Server As Open Redirector 110 As described in [RFC6819] an attacker could utilize a user's trust in 111 an authorization server to launch a phishing attack. The attack 112 described here though is not mitigated using the countermeasures 113 listed in [RFC6819]. In this scenario the attacker: 115 o Performs a client registration as per the core specification 116 [RFC6749]. The provided redirection URI is a malicious one e.g. 117 https://attacker.com (namely the one where the victim's user agent 118 will land without any validation) 120 o Prepare a forged URI using the assumption that the Authorization 121 Server complies with the OAuth 2.0 specification [RFC6749]. In 122 particular with the Authorization Server Error Response described 123 in the previous section ( Section 2 ). As an example he can use a 124 wrong or not existing scope e.g. 126 https://AUTHORIZATION_SERVER/authorize?response_type=code&client_i 127 d=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fattacker%2Ecom&s 128 cope=INVALID_SCOPE 130 o Attempt the pishing attack trying to have the victim clicking the 131 forged URI prepared on the previous step. Should the attack 132 succeeds the victim's user agent is redirected to 133 https://attacker.com (all with any user interaction) The HTTP 134 referer header will be set to the AS domain perhaps allowing 135 manipulation of the user. 137 2.2. Security Compromise: The Authorization Server As Open Redirector 139 The attacker can use a redirect error redirection to intercept 140 redirect based protocol messages via the Referer header and URI 141 fragment. In this scenario the attacker: 143 o Performs a registration of a malicious client as per the core 144 specification [RFC6749]. The provided redirection URI is a 145 malicious one e.g. https://attacker.com (This URI will capture 146 the fragment and referrer header sent as part of the error) 148 o Creates a invalid Authentication request URI for the malicious 149 client. As an example he can use a wrong or not existing scope 150 e.g. 152 https://AUTHORIZATION_SERVER/authorize?response_type=code&client_i 153 d=malicious_client&redirect_uri=https%3A%2F%2Fattacker%2Ecom&scope 154 =INVALID_SCOPE 156 o Performs a OAuth Authorization request using the invalid 157 Authorization request as the redirect_uri. This works if the AS 158 is pattern matching redirect_uri and has a public client that 159 shares the same domain as the AS. 161 (line breaks for display only) 163 https://AUTHORIZATION_SERVER/authorize?response_type=token 164 &client_id=good-client&scope=VALID_SCOPE 165 &redirect_uri=https%3A%2F%2AUTHORIZATION_SERVER%Fauthorize 166 %3Fresponse_type%3Dcode 167 %26client_id%3Dattacker-client-id 168 %26scope%3DINVALID_SCOPE 169 %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com 171 Figure 1 173 o Receive the response redirected to https://attacker.Com 175 The legitimate OAuth Authorization response will include an access 176 token in the URI fragment. 178 Most web browsers will append the fragment to the URI sent in the 179 location header of a 302 response if no fragment is included in the 180 location URI. 182 If the Authorization request is code instead of token, the same 183 technique is is used, but the code is leaked by the browser in the 184 referer header rather than the fragment. 186 This causes the access token from a successful authorization to be 187 leaked across the redirect to the malicious client. This is due to 188 browser behaviour and not because the AS has included any information 189 in the redirect URI other than the error code. 191 Protocols other than OAuth may be particularly vulnerable to this if 192 they are only verifying the domain of the redirect. Performing exact 193 redirect URI matching in OAuth will protect the AS, but not other 194 protocols. 196 It should be noted that a legitimate OAuth client registered with a 197 AS might be compromised and used as a redirect target by an attacker, 198 perhaps without the knowledge of the client site. This increases a 199 the attack surface for a authorization server. 201 2.3. Mitigation 203 In order to defend against the attack described in Section 2.2 the 204 authorization server can either: 206 o Append a empty fragment "#_" to all error redirect URI 207 o Perform a redirect to an intermediate URI under the controll of 208 the AS to clear the referer information in the browser that may 209 contain security token information. 210 o Respond with an HTTP 400 (Bad Request) status code. 212 o Force the resource owner to grants the access request (via a 213 consent screen) also in the error case at least once. The way the 214 authorization server achieves the connsent screen validation is 215 out of scope of this document. 217 3. Acknowledgements 219 We would like to thank all the people that partecipated to the 220 discussion, namely Bill Burke, Hans Zandbelt, Justin P. Richer, Phil 221 Hunt, Takahiko Kawasaki, Torsten Lodderstedt, Sergey Beryozkin. 223 4. Normative References 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, March 1997. 228 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 229 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 230 May 2008. 232 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 233 6749, October 2012. 235 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 236 Threat Model and Security Considerations", RFC 6819, 237 January 2013. 239 Appendix A. Document History 241 [[ to be removed by the RFC Editor before publication as an RFC ]] 243 -00 245 o Wrote the first draft. 247 o Changed Document name to conform to WG naming convention 249 o Added Section on redirect leaking security information 251 Authors' Addresses 253 John Bradley 254 Ping Identity 256 Email: ve7jtb@ve7jtb.com 257 URI: http://www.thread-safe.com/ 259 Antonio Sanso (editor) 260 Adobe Systems 262 Email: asanso@adobe.com 264 Hannes Tschofenig 266 Email: Hannes.Tschofenig@gmx.net 267 URI: http://www.tschofenig.priv.at