idnits 2.17.1 draft-lodderstedt-oauth-security-topics-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2016) is 2722 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Authentication Protocol T. Lodderstedt, Ed. 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Informational J. Bradley 5 Expires: May 16, 2017 Ping Identity 6 A. Labunets 7 Facebook 8 November 12, 2016 10 OAuth Security Topics 11 draft-lodderstedt-oauth-security-topics-00 13 Abstract 15 This draft gives a comprehensive overview on open OAuth security 16 topics. It is intended to serve as a tool for the OAuth working 17 group to systematically address these open security topics, 18 recommending mitigations, and potentially also defining OAuth 19 extensions needed to cope with the respective security threats. This 20 draft will potentially become a BCP over time. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 16, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. OAuth Credentials Leakage . . . . . . . . . . . . . . . . . . 3 58 2.1. Redirect URI validation of authorization requests . . . . 3 59 2.1.1. Authorization Code Grant . . . . . . . . . . . . . . 3 60 2.1.2. Implicit Grant . . . . . . . . . . . . . . . . . . . 4 61 2.1.3. Countermeasure: exact redirect URI matching . . . . . 6 62 2.2. Authorization code leakage via referrer headers . . . . . 7 63 2.2.1. Countermeasures . . . . . . . . . . . . . . . . . . . 7 64 2.3. Code in browser history (TBD) . . . . . . . . . . . . . . 8 65 2.4. Access token in browser history (TBD) . . . . . . . . . . 8 66 2.5. Access token on bad resource servers (TBD) . . . . . . . 8 67 2.6. Mix-Up (TBD) . . . . . . . . . . . . . . . . . . . . . . 9 68 3. OAuth Credentials Injection . . . . . . . . . . . . . . . . . 9 69 3.1. Code Injection . . . . . . . . . . . . . . . . . . . . . 9 70 3.1.1. Proposed Counter Measures . . . . . . . . . . . . . . 11 71 3.1.2. Access Token Injection (TBD) . . . . . . . . . . . . 13 72 3.1.3. XSRF (TBD) . . . . . . . . . . . . . . . . . . . . . 13 73 4. Other Attacks . . . . . . . . . . . . . . . . . . . . . . . . 14 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 It's been a while since OAuth has been published in RFC 6749 83 [RFC6749] and RFC 6750 [RFC6750]. Since publication, OAuth 2.0 has 84 gotten massive traction in the market and became the standard for API 85 protection and, as foundation of OpenID Connect, identity providing. 87 o OAuth implementations are being attacked through known 88 implementation weaknesses and anti-patterns (XSRF, referrer 89 header). Although most of these threats are discussed in RFC 6819 90 [RFC6819], continued exploitation demonstrates there may be a need 91 for more specific recommendations or that the existing mitigations 92 are too difficult to deploy. 94 o Technology has changed, e.g. the way browsers treat fragments in 95 some situations, which may change the implicit grant's underlying 96 security model. 98 o OAuth is used in much more dynamic setups than originally 99 anticipated, creating new challenges with respect to security. 100 Those challenges go beyond the original scope of both RFC 6749 101 [RFC6749] and RFC 6819 [RFC6819]. 103 This remainder of the document is organized as follows: The next 104 section describes various scenarios how OAuth credentials (namely 105 access tokens and authorization codes) may be disclosed to attackers 106 and proposes countermeasures. Afterwards, the document discusses 107 attacks possible with captured credential and how they may be 108 prevented. The last sections discuss additional threats. 110 2. OAuth Credentials Leakage 112 2.1. Redirect URI validation of authorization requests 114 The following implementation issue has been observed: Some 115 authorization servers allow clients to register redirect URI patterns 116 instead of complete redirect URIs. In those cases, the authorization 117 servers, at runtime, match the actual redirect URI parameter value at 118 the authorization endpoint against this pattern. This approach 119 allows clients to encode transaction state into additional redirect 120 URI parameters or to register just a single pattern for multiple 121 redirect URIs. As a downside, it turned out to be more complex to 122 implement and error prone to manage than exact redirect URI matching. 123 Several successful attacks have been observed in the wild, which 124 utilized flaws in the pattern matching implementation or concrete 125 configurations. Such a flaw effectively breaks client identification 126 or authentication (depending on grant and client type) and allows the 127 attacker to obtain an authorization code or access token, either 129 o by directly sending the user agent to a URI under the attackers 130 control or 132 o usually via the client as open redirector in conjunction with 133 fragment handling (implicit grant) carrying the response including 134 the respective OAuth credentials. 136 2.1.1. Authorization Code Grant 138 For a public client using the grant type code, an attack would look 139 as follows: 141 Let's assume the pattern "https://*.example.com/*" had been 142 registered for the client "s6BhdRkqt3". This pattern allows redirect 143 URI from any host residing in the domain example.com. So if an 144 attacker manager to establish a host or subdomain in "example.com" he 145 can impersonate the legitimate client. Assume the attacker sets up 146 the host "evil.example.com". 148 (1) The attacker needs to trick the user into opening a tampered URL 149 in his browser, which launches a page under the attacker's 150 control, say "https://www.evil.com". 152 (2) This URL initiates an authorization request with the client id 153 of a legitimate client to the authorization endpoint. This is 154 the example authorization request (line breaks are for display 155 purposes only): 157 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz 158 &redirect_uri=https%3A%2F%2Fevil.client.example.com%2Fcb HTTP/1.1 159 Host: server.example.com 161 (3) The authorization validates the redirect URI in order to 162 identify the client. Since the pattern allows arbitrary domains 163 host names in "example.com", the authorization request is 164 processed under the legitimate client's identity. This includes 165 the way the request for user consent is presented to the user. 166 If auto-approval is allowed (which is not recommended for public 167 clients according to RFC 6749), the attack can be performed even 168 easier. 170 (4) If the user does not recognize the attack, the code is issued 171 and directly sent to the attacker's client. 173 (5) Since the attacker impersonated a public client, it can directly 174 exchange the code for tokens at the respective token endpoint. 176 Note: This attack will not work for confidential clients, since the 177 code exchange requires authentication with the legitimate client's 178 secret. The attacker will need to utilize the legitimate client to 179 redeem the code. This and other kinds of injections are covered in 180 Section OAuth Credentials Injection. 182 2.1.2. Implicit Grant 184 The attack described above for grant type authorization code works 185 similarly for the implicit grant. If the attacker is able to send 186 the authorization response to a URI under his control, he will 187 directly get access to the fragment carrying the access token. 189 Additionally, it is possible to conduct an attack utilizing the way 190 user agents treat fragments in case of redirects. User agents re- 191 attach fragments to the destination URL of a redirect if the location 192 header does not contain a fragment (see [RFC7231], section 9.5). In 193 this attack this behavior is combined with the client as an open 194 redirector in order to get access to access tokens. This allows 195 circumvention even of strict redirect URI patterns. 197 Assume the pattern for client "s6BhdRkqt3" is 198 "https://client.example.com/cb?*", i.e. any parameter is allowed for 199 redirects to "https://client.example.com/cb". Unfortunately, the 200 client exposes an open redirector. This endpoint supports a 201 parameter "redirect_to", which takes a target URL and will send the 202 browser to this URL using a HTTP 302. 204 (1) Same as above, the attacker needs to trick the user into opening 205 a tampered URL in his browser, which launches a page under the 206 attacker's control, say "https://www.evil.com". 208 (2) The URL initiates an authorization request, which is very 209 similar to the attack on the code flow. As differences, it 210 utilizes the open redirector by encoding 211 "redirect_to=https://client.evil.com" into the redirect URI and 212 it uses the response type "token" (line breaks are for display 213 purposes only): 215 GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz 216 &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb%26redirect_to 217 %253Dhttps%253A%252F%252Fclient.evil.com%252Fcb HTTP/1.1 218 Host: server.example.com 220 (3) Since the redirect URI matches the registered pattern, the 221 authorization server allows the request and sends the resulting 222 access token with a 302 redirect (some response parameters are 223 omitted for better readability) 225 HTTP/1.1 302 Found 226 Location: https://client.example.com/cb? 227 redirect_to%3Dhttps%3A%2F%2Fclient.evil.com%2Fcb 228 #access_token=2YotnFZFEjr1zCsicMWpAA&... 230 (4) At the example.com, the request arrives at the open redirector. 231 It will read the redirect parameter and will issue a HTTP 302 to 232 the URL "https://evil.example.com/cb". 234 HTTP/1.1 302 Found 235 Location: https://client.evil.com/cb 237 (5) Since the redirector at example.com does not include a fragment 238 in the Location header, the user agent will re-attach the 239 original fragment 240 "#access_token=2YotnFZFEjr1zCsicMWpAA&..." to the URL and will 241 navigate to the following URL: 243 https://client.evil.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&... 245 (6) The attacker's page at client.evil.com can access the fragment 246 and obtain the access token. 248 2.1.3. Countermeasure: exact redirect URI matching 250 Since the cause of the implementation and management issues is the 251 complexity of the pattern matching, this document proposes to 252 recommend general use of exact redirect URI matching instead, i.e. 253 the authorization server shall compare the two URIs using simple 254 string comparison as defined in [RFC3986], Section 6.2.1.. 256 This would cause the following impacts: 258 o This change will require all OAuth clients to maintain the 259 transaction state (and XSRF tokens) in the "state" parameter. 260 This is a normative change to RFC 6749 since section 3.1.2.2 261 allows for dynamic URI query parameters in the redirect URI. In 262 order to assess the practical impact, the working group needs to 263 collect data whether this feature is used in deployed reality 264 today. 266 o The working group might also consider this change as a step 267 towards improved interoperability for OAuth implementations since 268 RFC 6749 is somehow vague on redirect URI validation. There is 269 especially no rule for pattern matching. So one may assume all 270 clients utilizing pattern matching will do so in a deployment 271 specific way. On the other hand, RFC 6749 already recommends 272 exact matching if the full URL had been registered. 274 o Clients with multiple redirect URIs need to register all of them 275 explicitly. 276 Note: clients with just a single redirect URI would not even need 277 to send a redirect URI with the authorization request. Does it 278 make sense to emphasize this option? Would that further simplify 279 use of the protocol? 281 o Exact redirect matching does not work for native apps utilizing a 282 local web server due to dynamic port numbers - at least wild cards 283 for port numbers are required. 284 Note: Does redirect uri validation solve any problem for native 285 apps? Effective against impersonation when used in conjunction 286 with claimed HTTPS redirect URIs only. 288 Additional recommendations: 290 o It is also advisable that the domains on which callbacks are 291 hosted should not expose open redirectors (see respective 292 section). 294 o As a further recommendation, clients may drop fragments via 295 intermediary URL with fix fragment (e.g. 296 https://developers.facebook.com/blog/post/552/) to prevent the 297 user agent from appending any unintended fragments. 299 Alternatives to exact redirect URI matching: authenticate client 300 using digital signatures (JAR? https://tools.ietf.org/html/draft- 301 ietf-oauth-jwsreq-09), ... 303 2.2. Authorization code leakage via referrer headers 305 The section above already discussed use of the referrer header for 306 one kind of attack to obtain OAuth credentials. It is also possible 307 authorization codes are unintentionally disclosed to attackers, if a 308 OAuth client renders a page containing links to other pages (ads, 309 faq, ...) as result of a successful authorization request. 311 If the user clicks onto one of those links and the target is under 312 the control of an attacker, it can get access to the response URL in 313 the referrer header. 315 It is also possible that an attacker injects cross-domain content 316 somehow into the page, such as (f.e. if this is blog web site 317 etc.): the implication is obviously the same - loading this content 318 by browser results in leaking referrer with a code. 320 2.2.1. Countermeasures 322 There are some means to prevent leakage as described above: 324 o Use of the HTML link attribute rel="noreferrer" (Chrome 325 52.0.2743.116, FF 49.0.1, Edge 38.14393.0.0, IE/Win10) 327 o Use of the "referrer" meta link attribute (possible values e.g. 328 noreferrer, origin, ...) (cf. https://w3c.github.io/webappsec- 329 referrer-policy/ - work in progress (seems Google, Chrome and Edge 330 support it)) 332 o Redirect to intermediate page (sanitize history) before sending 333 user agent to other pages 334 Note: double check redirect/referrer header behavior 336 o Use form post mode instead of redirect for authorization response 338 Note: There shouldn't be a referer header when loading HTTP content 339 from a HTTPS -loaded page (e.g. help/faq pages) 341 Note: This kind of attack is not applicable to the implicit grant 342 since fragments are not be included in referrer headers (cf. 343 https://tools.ietf.org/html/rfc7231#section-5.5.2) 345 2.3. Code in browser history (TBD) 347 When browser navigates to "client.com/redirection_endpoint?code=abcd" 348 as a result of a redirect from a provider's authorization endpoint. 350 Proposal for counter-measures: code is one time use, has limited 351 duration, is bound to client id/secret (confidential clients only) 353 2.4. Access token in browser history (TBD) 355 When a client or just a web site which already has a token 356 deliberately navigates to a page like provider.com/ 357 get_user_profile?access_token=abcdef.. Actually RFC6750 discourages 358 this practice and asks to transfer tokens via a header, but in 359 practice web sites often just pass access token in query 361 When browser navigates to client.com/ 362 redirection_endpoint#access_token=abcef as a result of a redirect 363 from a provider's authorization endpoint. 365 Proposal: replace implicit flow with postmessage communication 367 2.5. Access token on bad resource servers (TBD) 369 In the beginning, the basic assumption of OAuth 2.0 was that the 370 OAuth client is implemented for and tightly bound to a certain 371 deployment. It therefore knows the URLs of the authorization and 372 resource servers upfront, at development/deployment time. So well- 373 known URLs to resource servers serve as trust anchor. The validation 374 whether the client talks to a legitimate resource server is based on 375 TLS server authentication (see [RFC6819], Section 4.5.4). 377 As OAuth clients nowadays more and more bind dynamically at runtime 378 to authorization and resource servers, there need to be alternative 379 solutions to ensure, client do not deliver access tokens to bad 380 resource servers. 382 ... 384 Potential mitigations: 386 o PoP 388 o Token Binding 390 o AS-provided Meta Data 392 o ... 394 2.6. Mix-Up (TBD) 396 Mix-up is another kind of attack on more dynamic OAuth scenarios (or 397 at least scenarios where a OAuth client interacts with multiple 398 authorization servers). The goal of the attack is to obtain an 399 authorization code or an access token by tricking the client into 400 sending those credentials to the attacker (which acts as MITM between 401 client and authorization server) 403 A detailed description of the attack and potential counter-measures 404 is given in cf. https://tools.ietf.org/html/draft-ietf-oauth-mix-up- 405 mitigation-01. 407 Potential mitigations: 409 o AS returns client_id and its iss in the response. Client compares 410 this data to AS it believed it sent the user agent to. 412 o ID token (so requires OpenID Connect) carries client id and issuer 414 o register AS-specific redirect URIs, bind transaction to AS 416 o ... 418 3. OAuth Credentials Injection 420 Credential injection means an attacker somehow obtained a valid OAuth 421 credential (code or token) and is able to utilize this to impersonate 422 the legitimate resource owner or to cause a victim to access 423 resources under the attacker's control (XSRF). 425 3.1. Code Injection 427 In such an attack, the adversary attempts to inject a stolen 428 authorization code into a legitimate client on a device under his 429 control. In the simplest case, the attacker would want to use the 430 code in his own client. But there are situations where this might 431 not be possible or intended. Example are: 433 o The code is bound to a particular confidential client and the 434 attacker is unable to obtain the required client credentials to 435 redeem the code himself and/or 437 o The attacker wants to access certain functions in this particular 438 client. As an example, the attacker potentially wants to 439 impersonate his victim in a certain app. 441 o Another example could be that access to the authorization and 442 resource servers is some how limited to networks, the attackers is 443 unable to access directly. 445 How does an attack look like? 447 (1) The attacker obtains an authorization code by executing any of 448 the attacks described above (OAuth Credentials Leakage). 450 (2) It performs an OAuth authorization process with the legitimate 451 client on his device. 453 (3) The attacker injects the stolen authorization code in the 454 response of the authorization server to the legitimate client. 456 (4) The client sends the code to the authorization server's token 457 endpoint, along with client id, client secret and actual 458 redirect_uri. 460 (5) The authorization server checks the client secret, whether the 461 code was issued to the particular client and whether the actual 462 redirect URI matches the redirect_uri parameter. 464 (6) If all checks succeed, the authorization server issues access 465 and other tokens to the client. 467 (7) The attacker just impersonated the victim. 469 Obviously, the check in step (5) will fail, if the code was issued to 470 another client id, e.g. a client set up by the attacker. 472 An attempt to inject a code obtained via a malware pretending to be 473 the legitimate client should also be detected, if the authorization 474 server stored the complete redirect URI used in the authorization 475 request and compares it with the redirect_uri parameter. 477 [RFC6749], Section 4.1.3, requires the AS to ... "ensure that the 478 "redirect_uri" parameter is present if the "redirect_uri" parameter 479 was included in the initial authorization request as described in 480 Section 4.1.1, and if included ensure that their values are 481 identical." In the attack scenario described above, the legitimate 482 client would use the correct redirect URI it always uses for 483 authorization requests. But this URI would not match the tampered 484 redirect URI used by the attacker (otherwise, the redirect would not 485 land at the attackers page). So the authorization server would 486 detect the attack and refuse to exchange the code. 488 Note: this check could also detect attempt to inject a code, which 489 had been obtained from another instance of the same client on another 490 device, if certain conditions are fulfilled: 492 o the redirect URI itself needs to contain a nonce or another kind 493 of one-time use, secret data and 495 o the client has bound this data to this particular instance 497 But this approach conflicts with the idea to enforce exact redirect 498 URI matching at the authorization endpoint. Moreover, it has been 499 observed that providers very often ignore the redirect_uri check 500 requirement at this stage, maybe, because it doesn't seem to be 501 security-critical from reading the spec. 503 Other providers just pattern match the redirect_uri parameter against 504 the registered redirect URI pattern. This saves the authorization 505 server from storing the link between the actual redirect URI and the 506 respective authorization code for every transaction. But this kind 507 of check obviously does not fulfill the intent of the spec, since the 508 tampered redirect URI is not considered. So any attempt to inject a 509 code obtained using the client_id of a legitimate client or by 510 utilizing the legitimate client on another device won't be detected 511 in the respective deployments. 513 It is also assumed that the requirements defined in [RFC6749], 514 Section 4.1.3, increase client implementation complexity as clients 515 need to memorize or re-construct the correct redirect URI for the 516 call to the tokens endpoint. 518 The authors therefore propose to the working group to drop this 519 feature in favor of more effective and (hopefully) simpler approaches 520 to code injection prevention as described in the following section. 522 3.1.1. Proposed Counter Measures 524 The general proposal is to bind every particular authorization code 525 to a certain client on a certain device (or in a certain user agent) 526 in the context of a certain transaction. There are multiple 527 technical solutions to achieve this goal: 529 Nonce OpenID Connect's existing "nonce" parameter is used for this 530 purpose. The nonce value is one time use and created by the 531 client. The client is supposed to bind it to the user agent 532 session and sends it with the initial request to the OpenId 533 Provider (OP). The OP associates the nonce to the 534 authorization code and attests this binding in the ID token, 535 which is issued as part of the code exchange at the token 536 endpoint. If an attacker injected an authorization code in 537 the authorization response, the nonce value in the client 538 session and the nonce value in the ID token will not match 539 and the attack is detected. assumption: attacker cannot get 540 hold of the user agent state on the victims device, where he 541 has stolen the respective authorization code. 542 pro: 543 - existing feature, used in the wild 544 con: 545 - OAuth does not have an ID Token - would need to push that 546 down the stack 548 State It has been discussed in the security workshop in December to 549 use the OAuth state value much similar in the way as 550 described above. In the case of the state value, the idea is 551 to add a further parameter state to the code exchange 552 request. The authorization server then compares the state 553 value it associated with the code and the state value in the 554 parameter. If those values do not match, it is considered an 555 attack and the request fails. Note: a variant of this 556 solution would be send a hash of the state (in order to 557 prevent bulky requests and DoS). 558 pro: 559 - use existing concept 560 con: 561 - state needs to fulfil certain requirements (one time use, 562 complexity) 563 - new parameter means normative spec change 565 PKCE Basically, the PKCE challenge/verifier could be used in the 566 same way as Nonce or State. In contrast to its original 567 intention, the verifier check would fail although the client 568 uses its correct verifier but the code is associated with a 569 challenge, which does not match. 570 pro: 571 - existing and deployed OAuth feature 572 con: 573 - currently used and recommended for native apps, not web 574 apps 576 Token Binding Code must be bind to UA-AS and UA-Client legs - 577 requires further data (extension to response) to manifest 578 binding id for particular code. 579 pro: 580 - highly secure 581 con: 582 - highly sophisticated, requires browser support, will it 583 work for native apps? 585 per instance client id/secret ... 587 Note on pre-warmed secrets: An attacker can circumvent the counter- 588 measures described above if he is able to create the respective 589 secret on a device under his control, which is then used in the 590 victim's authorization request. 591 Exact redirect URI matching of authorization requests can prevent the 592 attacker from using the pre-warmed secret in the faked authorization 593 transaction on the victim's device. 594 Unfortunately it does not work for all kinds of OAuth clients. It is 595 effective for web and JS apps, for native apps with claimed URLs. 596 What about other native apps? Treat nonce or PKCE challenge as 597 replay detection tokens (needs to ensure cluster-wide one-time use)? 599 3.1.2. Access Token Injection (TBD) 601 Note: An attacker in possession of an access token can access any 602 resources the access token gives him the permission to. This kind of 603 attacks simply illustrates the fact that bearer tokens utilized by 604 OAuth are reusable similar to passwords unless they are protected by 605 further means. 606 (where do we treat access token replay/use at the resource server? 607 https://tools.ietf.org/html/rfc6819#section-4.6.4 has some text about 608 it but is it sufficient?) 610 The attack described in this section is about injecting a stolen 611 access token into a legitimate client on a device under the 612 adversaries control. The attacker wants to impersonate a victim and 613 cannot use his own client, since he wants to access certain functions 614 in this particular client. 616 Proposal: token binding, hybrid flow+nonce(OIDC), other 617 cryptographical binding between access token and user agent instance 619 3.1.3. XSRF (TBD) 621 injection of code or access token on a victim's device (e.g. to cause 622 client to access resources under the attacker's control) 623 mitigation: XSRF tokens (one time use) w/ user agent binding (cf. 624 https://www.owasp.org/index.php/ 625 CrossSite_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet) 627 4. Other Attacks 629 Using the AS as Open Redirector - error handling AS (redirects) 630 (draft-ietf-oauth-closing-redirectors-00) 632 Using the Client as Open Redirector 634 redirect via status code 307 - use 302 636 5. Acknowledgements 638 We would like to thank ... for their valuable feedback. 640 6. IANA Considerations 642 This draft includes no request to IANA. 644 7. Security Considerations 646 All relevant security considerations have been given in the 647 functional specification. 649 8. Normative References 651 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 652 Resource Identifier (URI): Generic Syntax", STD 66, 653 RFC 3986, DOI 10.17487/RFC3986, January 2005, 654 . 656 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 657 RFC 6749, DOI 10.17487/RFC6749, October 2012, 658 . 660 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 661 Framework: Bearer Token Usage", RFC 6750, 662 DOI 10.17487/RFC6750, October 2012, 663 . 665 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 666 Threat Model and Security Considerations", RFC 6819, 667 DOI 10.17487/RFC6819, January 2013, 668 . 670 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 671 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 672 DOI 10.17487/RFC7231, June 2014, 673 . 675 Authors' Addresses 677 Torsten Lodderstedt (editor) 678 Deutsche Telekom AG 680 Email: torsten@lodderstedt.net 682 John Bradley 683 Ping Identity 685 Email: ve7jtb@ve7jtb.com 687 Andrey Labunets 688 Facebook 690 Email: isciurus@fb.com