jiebi/CodeConvo huggingface dataset:
In all of the attack scenarios listed above, a user is tricked or exploited.  For other attacks, where the user is willingly colluding <del> with the attacker, the security implications and potential mitigations are very different.  For example, a cooperating user can bypass software mitigations on their device, share access to hardware tokens with the attacker, and install additional devices to forward radio signals to trick proximity checks. </del> <ins> with the attacker, the threat model, security implications and potential mitigations are very different.  For example, a cooperating user can bypass software mitigations on their device, share access to hardware tokens with the attacker, and install additional devices to forward radio signals to circumvent proximity checks. </ins> This document only considers scenarios where a user does not collude with an attacker.
equipped to authenticate the channel between the two devices. Mitigations should focus on: <del> To achieve the above outcomes, mitigating the exploits of cross- device flows require a three-pronged approach: </del> <ins> To achieve the above outcomes, mitigating against Cross-Device Consent Phishing attacks require a three-pronged approach: </ins> 5.1. A number of protocols that enable cross-device flows that are <del> susceptible to illicit consent grant attacks are already deployed. The security profile of these protocols can be improved through practical mitigations that provide defense in depth that either: </del> <ins> susceptible to Cross-Device Consent Phishing attacks are already deployed.  The security profile of these protocols can be improved through practical mitigations that provide defense in depth that either: </ins> It is recommended that one or more of the mitigations are applied whenever implementing a cross-device flow.  Every mitigation provides an additional layer of security that makes it harder to initiate the <del> attack, disrupts attacks when in process or reduces the impact of a </del> <ins> attack, disrupts attacks in progress or reduces the impact of a </ins> successful attack. 5.1.1.
5.2.1.2. There are several reports in the public domain outlining how the <del> unauthenticated channel may be exploited to execute an illicit consent grant attack. </del> <ins> unauthenticated channel may be exploited to execute a Cross-Device Consent Phishing attack (Exploit1, Exploit2, Exploit3, Exploit4, Exploit5, Exploit6). </ins> 5.2.1.3.
RFC6749 and PKCE RFC7663, to grant authorization to an Initiating Device (e.g., Smart TV or interactive whiteboard) using a mobile phone as the authenticating device.  This combination of FIDO2/ <del> WebAuthn and Authorization Code Flow with PKCE enables cross device </del> <ins> WebAuthn and Authorization Code Flow with PKCE enables cross-device </ins> authorization flows, without the risks posed by the Device Authorization Grant RFC8628. 5.2.4. The FIDO Cross-Device Authentication (CDA) flow provides the best <del> protection against attacks on the unauthenticated channel for cross </del> <ins> protection against attacks on the unauthenticated channel for cross- </ins> device flows.  It can be combined with OAuth 2.0 and OpenID Connect protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated
Cross-device flows enable a user to initiate an authorization flow on one device (the Initiating Device) and then use a second, personally <del> trusted, device (Authorization Device) to authorize access to a resource (e.g., access to a service). </del> <ins> trusted, device (Authorization Device) to authorize the Initiating Device to access a resource (e.g., access to a service).  The Device Authorization Grant (RFC8628) and Client Initiated Backchannel Authentication CIBA are two examples of popular cross-device flows. </ins> These flows are increasingly popular and typically involve using a mobile phone to scan a QR code or enter a user code displayed on an
In cross-device flows that follow the user-transferred authorization data pattern, the client on the Initiating Device initiates the authorization request, but the user still has to transfer the <del> authorization code to the Initiating Device.  The authorization request may happen as a result of user interaction with the Initiating Device, but may also be triggered without the user's direct interaction with the Initiating Device. </del> <ins> authorization data to the Initiating Device.  The authorization data may take different forms, including a numerical value such as a 6 digit authorization code.  The authorization request may happen as a result of user interaction with the Initiating Device, but may also be triggered without the user's direct interaction with the Initiating Device. </ins> Attackers exploit the user-transferred authorization data pattern by combining the social engineering techniques used to set context for <del> users and tricking users into providing them with access codes sent to their phones.  These attacks are very similar to phishing attacks, except that the attacker also has the ability to trigger the </del> <ins> users and tricking users into providing them with authorization data sent to their phones.  These attacks are very similar to phishing attacks, except that the attacker also has the ability to trigger the </ins> authorization request to be sent to the user directly by the Authorization Server. The unauthenticated channel may also be exploited in variations of <del> the above scenario where the user (as opposed tot he attacker) initiates the flow and is then tricked into sending the authorization data (e.g. access code) to the attacker.  In these flows, the user is already authenticated and they request authroization data to transfer </del> <ins> the above scenario where the user (as opposed to the attacker) initiates the flow and is then convinced using social engineering techniques into sending the authorization data (e.g. a 6 digit authorization code) to the attacker.  In these flows, the user is already authenticated and they request authorization data to transfer </ins> a session or obtain some other privilege such as joining a device to <del> a network.  The authorization data may be represented as a QR code o text message.  The attacker then proceeds to exploit the </del> <ins> a network.  The authorization data may be represented as a QR code or authorization code.  The attacker then proceeds to exploit the </ins> unauthenticated channel by using social engineering techniques to <del> trick the user into initiating a flow and send the QR code or user code to the attacker, which the attacker use to obtain the privileges </del> <ins> convince the user to send the QR code or user code to the attacker. The attacker then use the authroization data to obtain the privileges </ins> that would have been assigned to the user. 3.4.
5.2.4. The FIDO Cross-Device Authentication (CDA) flow provides the best <del> protection against attacks on the unauthenticated channel for cross- </del> <ins> protection against attacks on the unauthenticated channel for cross </ins> device flows.  It can be combined with OAuth 2.0 and OpenID Connect <del> protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated </del> <ins> protocols for standards-based authorization and authentication flows. If FIDO2/WebAuthn support is not available, Client Initiated </ins> Backchannel Authentication (CIBA) provides an alternative, provided that there is a channel through which the authorization server can contact the end user.  Examples of such a channel include device push
filtering (e.g., anti-spam filter), these messages can be blocked and prevented from reaching the end-users.  It may be possible to fine- tune content filtering solutions to detect artefacts like QR codes or <del> user codes that are being reused in multiple messages to disrupt spray attacks. Content filtering may be better suited to interrupt large scale spray attacks since some scenarios may require re-transmission of user, QR and access codes.  Content filtering may also be fragmented across multiple communications systems and channels (e-mail, messaging, text etc), making it harder to detect or interrupt attacks that are executed over multiple channels, unless here is a high degree of integration between content filtering systems. </del> <ins> user codes that are included in a message that is sent to multiple recipients in the expectation that at least one of the recipients will be convinced by the message and grant authroization to access restricted resources. Some scenarios may require legitimate re-transmission of user, QR and authorization data (e.g. retries).  To prevent the disruption of legitimate scenarios, content filters may use a threshold and allow a limited number of messages with the same QR or user codes to be transmitted before interrupting the delivery of those messages. Content filtering may also be fragmented across multiple communications systems and channels (e-mail, messaging, text etc), making it harder to detect or interrupt attacks that are executed over multiple channels, unless here is a high degree of integration between content filtering systems. </ins> 5.1.6.
attacker gathers a large number of access and refresh tokens on a single device and then sells them for profit more difficult, since the attacker would also have to export the cryptographic keys used to <del> sender constrain the tokens or be able to access them and generate </del> <ins> sender-constrain the tokens or be able to access them and generate </ins> signatures for future use.  If the attack is being executed on a trusted device to a device with anti-malware, any attempts to exfiltrate tokens or keys may be detected and the device's trust <del> status may be changed.  Using hardware keys for sender constraining </del> <ins> status may be changed.  Using hardware keys for sender-constraining </ins> tokens will further reduce the ability of the attacker to move tokens to another device. Sender-constrained tokens, especially sender-constrained tokens that require proof-of-posession, raise the bar for executing the attack <del> and and profiting from exfiltrating tokens.  The quality of key protection has an impact on the effectiveness of the attack. Although a software proof-of-posession key is better than no proof- of-posession key, an attacker may still exfiltrate the software key. Hardware keys will be harder to exfiltrate, but come with additional implementation complexity.  An attacker that controls the Initiating Device may still be able to excercise they key, even if it is in hardware, thus the main protection derived from sender constrianed tokens is preventing them from being moved from the Initiating Device to another device that can be used to profit from the attack. </del> <ins> and profiting from exfiltrating tokens.  Although a software proof- of-posession key is better than no proof-of-posession key, an attacker may still exfiltrate the software key.  Hardware keys are harder to exfiltrate, but come with additional implementation complexity.  An attacker that controls the Initiating Device may still be able to excercise the key, even if it is in hardware. Consequently the main protection derived from sender-constrained tokens is preventing tokens from being moved from the Initiating Device to another device, thereby making it harder sell stolen tokens and profit from the attack. </ins> 5.1.13.
The unauthenticated channel between the Initiating Device and Authorization Device allows attackers to obtain a QR code or user <del> code in one location and display in another location.  Establishing proximity between the location of the Initiating Device and the Authorization Device limits an attacker's ability to launch attacks by sending the user or QR codes to large numbers of users across the globe.  There are a couple of ways to establish proximity: </del> <ins> code in one location and display it in another location. Consequently, proximity-enforced cross-device flows are more resistant to Cross-Device Consent Phishing attacks than proximity- less cross-device flows.  Establishing proximity between the location of the Initiating Device and the Authorization Device limits an attacker's ability to launch attacks by sending the user or QR codes to large numbers of users that are geographically distributed.  There are a couple of ways to establish proximity: </ins> Depending on the risk profile and the threat model in which a system is operating, it may be necessary to use more than one mechanism to
the user in order to convince them to grant authorization on the Authorization Device.  The attacker is able to change the context of the authorization request because the channel between the Initiating <del> Device and the Authorizing Device is unauthenticated.  These attacks are also known as Cross-Device Consent Phishing (CDCP) attacks. </del> <ins> Device and the Authorization Device is unauthenticated.  These attacks are also known as Cross-Device Consent Phishing (CDCP) attacks. </ins> 3.1.
It is up to the user to decide whether they should trust the QR code or user code.  In effect the user is asked to compensate for the absence of an authenticated channel between the Initiating Device <del> (e.g., smart TV) and the Authorizing Device (e.g., the mobile phone). </del> <ins> (e.g., smart TV) and the Authorization Device (e.g., the mobile phone). </ins> Attackers exploit this absence of an authenticated channel between the two devices by obtaining QR codes or user codes (e.g., by
5.1.13. <ins> Research shows that user education is effective in reducing the risk of phishing attacks Baki2023.  The service provider MAY educate users on the risks of cross-device consent phishing and provide out-of-band reinforcement to the user on the context and conditions under which an authorization grant may be requested.  For example, if the service provider does not send e-mails with QR codes requesting users to grant authorization, this may be reinforced in marketing messages and anti-fraud awareness campaigns.  The service provider MAY also choose to reinforce these user education messages through in-app experiences. Although user education helps to raise awareness and reduce the overall risk to users, it is insufficient on its own to mitigate cross-device consent phishing attacks.  In particular, carefully designed phishing attacks can be practically indistinguishable from benign authorization flows even for well-trained users.  User education SHOULD therefore be used in conjunction with other controls described in this document. 5.1.14. </ins> The user experience SHOULD preserve the context within which the protocols were initiated and communicate this clearly to the user when they are asked to authorize, authenticate or present a
default option or given similar prominence in the user experience as the "grant" option. <ins> The user experience MAY include information to further educate the user on cross-device consent phishing attacks and reinforce the conditions under which authorization grants may be requested. </ins> This information may be communicated graphically or in a simple message (e.g., "It looks like you are trying to access your files on a digital whiteboard in your city center office.  Click here to grant access to your files.  If you are not trying to access your files, you should decline this request and notify the security department"). <del> The service may provide out-of-band reinforcement to the user on the context and conditions under which an authorization grant may be requested.  For example if the service provider does not send e-mails with QR codes requesting users to grant authorization, this may be reinforced in marketing messages, in-app experiences and through anti-fraud awareness campaigns. </del> Improvements to user experience on their own is unlikely to be sufficient and SHOULD be used in conjunction with other controls described in this document. <del> 5.1.14. </del> <ins> 5.1.15. </ins> By requiring a user to authenticate on the Initiating Device with a phishing resistant authentication method before initiating a cross-
message that unless the user initiated the authorization request, or was expecting it, they should decline the request. <ins> If the user uses an application on a mobile device to scan a QR code, the application MAY display information advising the user under which conditions they should expect to be asked to scan a QR code and under which circumstances they should never scan a QR code (e.g. display a message that the QR code will only be displayed on kiosks within trusted locations or on trusted websites hosted on a specific domain, and never in e-mail or other media and locations). </ins> It SHOULD be clear to the user how to decline the request.  To avoid accidental authorization grants, the "decline" option SHOULD be the default option or given similar prominence in the user experience as
5.1.16. <ins> The user MAY be asked to verify if they initiated an authentication or authorization request by sending a one-time password (OTP) or PIN to the user's Authorization Device and asking them to enter it on the Initiating Device to confirm the request.  If the request was initiated without the users' consent, they would receive an OTP or PIN out of context which may raise suspicion for the user.  In addition, they would not have information on where to enter the OTP or PIN.  The user experience on the Authorization Device MAY reinforce the risk of receiving an out-of-context OTP or PIN and provide information to the user on how to report an unauthorized authentication or authorization request. The additional verification step may reduce the overall usability of the system as it is one more thing users need to do right.  Attackers may combine traditional phishing attacks and target users who respond to those messages with an interactive attack that sets the expectation with the user that they will have to provide the OTP or PIN, in addition to granting authorization for the request. 5.1.17. </ins> The practical mitigations described in this section can prevent the attacks from being initiated, disrupt attacks once they start or reduce the impact or remediate an attack if it succeeds.  When
Abstract This document extends the OAuth 2.0 Authorization Framework RFC6749 <del> with new grant types to support first-party native applications that want to control the user experience of the process of obtaining authorization from the user. </del> <ins> with a new endpoint "authorization_challenge_endpoint" to support first-party native applications that want to control the process of obtaining authorization from the user using a native experience. </ins> In many cases, this can provide an entirely browserless experience suited for native applications, only delegating to the browser in
1.2. <del> TODO If the service provides multiple applications, then it creates an additional burden to build and maintain native login flows within each application.  Instead, the redirect-based authorization code flow removes the burden of implementing login flows from each application by centralizing all aspects of logging in at the authorization server. See phishing section below. </del> <ins> It's important to remember that the scope of this specification is limited to 1st party native applications.  Please review the entirety of security-considerations and when more than one 1st party native application is supported, multiple-applications. </ins> 2.
this specification which the native application uses to obtain an authorization code. <ins> Authorization servers supporting this specification SHOULD include the URL of their authorization challenge endpoint in their authorization server metadata document RFC8414 using the "authorization_challenge_request_endpoint" parameter as defined in authorization-server-metadata. The endpoint accepts the authorization request parameters defined in RFC6749 for the authorization endpoint as well as all applicable extensions defined for the authorization endpoint.  Some examples of such extensions include Proof Key for Code Exchange (PKCE) RFC7636, Resource Indicators RFC8707, and OpenID Connect (OIDC) [OIDC].  It is important to note that some extension parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query).  It is out of scope as to what the AS does in the case that an extension defines a parameter that is has no meaning in this use case. </ins> The client initiates the authorization flow with or without information collected from the user (e.g. a password or MFA code).
PoP binding of device session parameter <del> 8.4.1. </del> <ins> 9.4.1. </ins> The client SHOULD use DPoP for every request, the AS SHOULD bind any artifacts returned to the DPoP key <del> 8.4.2. </del> <ins> 9.4.2. </ins> Possible, but of scope of this document. <del> 8.5. </del> <ins> 9.5. </ins> <del> Increased phishing risk </del> <ins> When there there is more than one 1st-party native applications supported by the AS, then it is important to consider a number of additional risks.  These risks fall into two main categories: Experience Risk and Technical Risk which are described below. </ins> <del> User confusion </del> <ins> 9.5.1. </ins> <del> Increased attack surface </del> <ins> Any time a user is asked to provide the authentication credentials in user experiences that differ, it has the effect of increasing the likelihood that the user will fall prey to a phishing attack because they are used to entering credentials in different looking experiences.  When multiple native applications are support, the implementation MUST ensure the native experience is identical across all the 1st party native applications. </ins> <del> Higher chance of incorrect implementations </del> <ins> Another experience risk is user confusion caused by different looking experiences and behaviors.  This can increase the likelihood the user will not complete the authentication experience for the 1st party native application. </ins> <del> 9. </del> <ins> 9.5.2. In addition to the experience risks, multiple implementations in 1st party native applications increases the risk of an incorrect implementation as well as increasing the attack surface as each implementation may expose it's own weaknesses. 9.5.3. To address these risk, when multiple 1st party native applications must be supported, and other methods such as [Native SSO] are not applicable, it is RECOMMENDED that a client-side SDK be used to ensure the implementation is consistent across the different native apps and to ensure the user experience is identical for all 1st party apps. 10. </ins> This document has no IANA actions.
DPoP is an application-level mechanism for sender-constraining OAuth RFC6749 access and refresh tokens I-D.ietf-oauth-dpop.  If DPoP is used to sender constrain tokens, the native client SHOULD use DPoP <del> for every token request to the Authroization Server and interaction </del> <ins> for every token request to the authorization Server and interaction </ins> with the Resource Server. DPoP includes an optional capability to bind the authorization code
9.3. <ins> The authorization challenge endpoint is capable of directly receiving user credentials and returning authorization codes.  This exposes a new vector to perform credential stuffing attacks, if additional measures are not taken to ensure the authenticity of the application. An authorization server may already have a combination of built-in or 3rd party security tools in place to monitor and reduce this risk in browser-based authentication flows.  Implementors SHOULD consider similar security measures to reduce this risk in the authorization challenge endpoint.  Additionally, the attestation APIs SHOULD be used when possible to assert a level of confidence to the authorization server that the request is originating from an application owned by the same party. 9.4. </ins> Typically, mobile and desktop applications are considered "public clients" in OAuth, since they cannot be shipped with a statically configured set of client credentials RFC8252.  Because of this,