Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a NextGenPSD2 OAuth SCA Mode Security Recommendations
Semelhante a NextGenPSD2 OAuth SCA Mode Security Recommendations (20)
Mais de Torsten Lodderstedt
Mais de Torsten Lodderstedt (20)
Último
Último (20)
NextGenPSD2 OAuth SCA Mode Security Recommendations
- 1. NextGenPSD2 OAuth SCA Mode Security Recommendations Torsten Lodderstedt @tlodderstedt yes®
- 2. OAuth 2.0 ● Standard for API access authorization ● Current version 2.0 published in 2012, broadly used and mature ● Updated Security Guidlines under way Design pattern: ● Separate authentication and authorization from actual API access ● Delegate user interactions to service provider ● User credentials are only touched by the service provider and no 3rd party ● Versatile, secure and, privacy preserving
- 3. ASPSPUser AIS with OAuth SCA Mode - High Level Create Account Access Consent Use access_token for AIS AISP Consent-ID User gives authorization for Account Access with Consent-ID access_token OAuth Authorization Code Grant Start XS2A
- 4. Closer Look: OAuth SCA Mode GET /authorize?scope=AIS:<Consent-ID>&... Redirect to ASPSP Redirect to aisp.com/authok?code=foo42&... POST /token, code=foo42... Send code=foo42 Send access_token ASPSPUser AISP User gives authorization for account access (incl. SCA)
- 5. ASPSPUser PIS with OAuth SCA Mode - High Level Create Payment Resource Use access_token PISP Payment-ID User gives authorization for Payment with Payment-ID access_token OAuth Authorization Code Grant Start Payment
- 6. User What happens when? Payment Initiation ASPSP Use access_token PISP Payment-ID User gives authorization for Payment with Payment-ID access_token Start Payment Payment authorized & executed Payment prepared Potential attacks!
- 7. ASPSPAttacker Cross-Browser Payment Initiation Attack Payment Initiation PISP Payment-ID User gives authorization for Payment with Payment-ID Pay my order Redirect to ASPSP User Redirect to ASPSP Attacker disguises as a merchant. User thinks she pays for her order at the merchant, but instead pays for the attacker’s order at PISP! Attacker’s Payment executed! Pay my order All details: https://cutt.ly/cross-browser-payment-initation
- 8. Security of OAuth ● Many security features of OAuth against CSRF, Replay, … come into play after user authorization ● Security of OAuth lies in the access token ● Therefore, any subsequent process, including payment, should be performed with the access token, not within the user authorization process
- 9. User Better Solution! Payment Initiation ASPSP Use access_token PISP Payment-ID User gives authorization for Payment with Payment-ID access_token Start Payment Payment authorized Payment prepared Payment executed
- 10. Security Threats
- 11. Security Threats needed to be coped with ● TPP Impersonation ● TPP Privilege Exceedance ● Open Redirection ● CSRF ● Authorization Code Replay ● Mix-Up ● Scope Swap ● Access Token Replay More details can be found at https://tools.ietf.org/html/draft-ietf-oauth-security- topics
- 13. Security Advice in Detail GET /authorize?... Redirect to ASPSP Redirect to aisp.com/authok?... POST /token Send code=foo42 Send access_token ASPSPUser PISP User gives authorization for account access Use access_token Start Create Payment Resource Payment ID
- 14. Resource Creation GET /authorize?... Redirect to ASPSP Redirect to aisp.com/authok?... POST /token Send code=foo42 Send access_token ASPSPUser PISP User gives authorization for account access Use access_token Start Create Payment Resource Payment ID
- 15. Resource Creation ● Mix-up attack* detection: TPP shall set up a redirect URI with the ASPSP which uniquely identifies the ASPSP Example: https://pisp.com/authok/aspsp2 *Mix-up attack: a malicious or compromised ASPSP confuses the TPP in order to learn an authorization code
- 16. Example Request POST https://api.testbank.com/v1/payments/sepa-credit-transfers Content-Type: application/json TPP-Redirect-URI: https%3A%2F%2Fpisp%2Ecom%2Fauthok%2Faspsp2 { "instructedAmount": { "currency": "EUR", "amount": "123" }, "creditor": { "name": "Merchant123" }, "creditorAccount": { "iban": "DE23100120020123456789" }, ... }
- 17. Resource Creation (ASPSP) ● TPP Impersonation and Privileges Exceedance: ASPSP needs to authentication TPP using eIDAS certificate and check TPP’s authorization to perform desired services.
- 18. Example Response HTTP/1.x 201 Created Location: https://api.testbank.com/psd2/v1/payments/sepa-credit-transfers/1234-wertiq-983 Content-Type: application/json { "transactionStatus": "RCVD", "paymentId": "1234-wertiq-983", "_links": { "scaOAuth": { "href": "https://www.testbank.com/oauth/.well-known/oauth-authorization-server" }, ... } } }
- 19. Example oauth-authorization-server { "issuer": "https://as.testbank.com", "authorization_endpoint": "https://as.example.com/authorize", "token_endpoint": "https://as.example.com/token", "token_endpoint_auth_methods_supported": ["tls_client_auth",”self_signed_tls_client_auth”], "scopes_supported": ["pis","ais","offline_access"], "response_types_supported": ["code"], "grant_types_supported": "authorization_code", "code_challenge_methods_supported": "S256", ... }
- 20. Authorization Request GET /authorize?... Redirect to ASPSP Redirect to aisp.com/authok?... POST /token Send code=foo42 Send access_token ASPSPUser PISP User gives authorization for account access Use access_token Start Create Payment Resource Payment ID
- 21. Authorization Request In preparation of sending the authorization request, the TPP shall 1. CSRF protection: Create a one-time use CSRF token to be conveyed to the ASPSP in the “state” parameter 2. Code replay protection: Create a one-time use nonce, whose SHA-256 value will be conveyed to the ASPSP in the “code_challenge” parameter 3. Bind those values to the current session in the user agent 4. Mix-Up protection: Memorize in the current session the identity of the ASPSP the request will be sent to
- 23. Authorization Request The ASPSP upon receiving this request must perform these checks: ● Open Redirection Prevention: “redirect_uri” value must exactly match the value sent to the ASPSP with the request used to create the payment or consent resource in the header “TPP-Redirect-URI”. ● Otherwise, the ASPSP must refuse to process the request and must not redirect the user agent back to the TPP.
- 24. Authorization Response GET /authorize?... Redirect to ASPSP Redirect to aisp.com/authok?... POST /token Send code=foo42 Send access_token ASPSPUser PISP User gives authorization for account access Use access_token Start Create Payment Resource Payment ID
- 25. Authorization Response The TPP upon receiving this response shall perform the following checks: 1. Mix-Up detection: Redirect URI where the response was received must match the ASPSP the response was expected to come from. 2. CSRF detection: The “state” value is linked to the current session in the user agent. If any of these check fails, the TPP must refuse to process the authorization response.
- 26. Example Authorization Response HTTP/1.1 302 Found Location: https%3A%2F%2Fpisp%2Ecom%2Fauthok%2Faspsp2? code=SplxlOBeZQQYbYS6WxSbIA& state=S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw
- 27. Token Request GET /authorize?... Redirect to ASPSP Redirect to aisp.com/authok?... POST /token Send code=foo42 Send access_token ASPSPUser PISP User gives authorization for account access Use access_token Start Create Payment Resource Payment ID
- 28. Token Request The ASPSP upon receiving the request shall perform the following checks: 1. TPP impersonation detection: Authenticate TPP with eIDAS certificate 2. Code leakage and replay detection: Check that code is bound to the TPP (client_id), is still valid, and was sent to exactly the redirect URI conveyed in the “redirect_uri” request parameter. 3. Code injection detection: “code_verifier” value, when hashed with S256, matches the “code_challenge” value the code parameter is bound to (see [RFC7636], Section 4.6). If any of these check fails, the ASPSP must refuse to process the token request. See [RFC6749], Section 10 and [OAuth 2.0 Security BCP], Section 2.1
- 29. Example Token Request POST /token HTTP/1.1 Host: https://api.testbank.com Content-Type: application/x-www-form-urlencoded client_id=PSDES-BDE-3DFD21 &grant_type=authorisation_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fpisp%2Ecom%2Fauthok%2Faspsp2 &code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
- 30. Token Response GET /authorize?... Redirect to ASPSP Redirect to aisp.com/authok?... POST /token Send code=foo42 Send access_token ASPSPUser PISP User gives authorization for account access Use access_token Start Create Payment Resource Payment ID
- 31. Token Response ● Access Token Replay Detection: ASPSP issues access token that is bound to the TPP’s client certificate ● Scope swap prevention ○ ASPSP must return scope values assigned to the access token ○ Upon receiving the token response, the TPP must check whether the scope assigned to the access token is the same as requested in the authorization request. ○ If this check fails, the TPP must refuse to process the token response
- 32. Example Token Response HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "access_token": "SlAV32hkKG", "token_type": "Bearer", "expires_in": 3600, "scope": "pis:1234-wertiq-983" }
- 33. API Requests GET /authorize?... Redirect to ASPSP Redirect to aisp.com/authok?... POST /token Send code=foo42 Send access_token ASPSPUser PISP User gives authorization for account access Use access_token Start Create Payment Resource Payment ID
- 34. API Requests ● Access Token Replay Detection ○ On every API request, the TPP shall authenticate using TLS client authentication and its eIDAS certificate according to [mTLS], Section 3. ○ The resource server must check whether the certificate used for TLS Client Authentication matches the certificate the access token is bound to (see [mTLS], Section 3). ● Authorization: The ASPSP must also check that the access token is still valid and whether the permission associated with the access token entitles the TPP to perform the specific request. ● If any of these checks fails, the request must be refused by responding with a suitable HTTP Status code.
- 35. Security Recommendations (Overview) ● Adhere to OAuth 2.0 Security Best Current Practice (https://tools.ietf.org/html/draft-ietf-oauth-security-topics) ● TPP authentication and access token replay protection using OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens ● Protection against code injection through Proof Key for Code Exchange ● Protection against CSRF using session-bound state parameter values ● Protection against Mix-Up attacks using session bound ASPSP specific redirect URIs ● Protection against session-fixation type of attacks by utilizing OAuth grant flow as designed
- 36. Q&A! Latest Drafts & Publications OAuth 2.0 Security Best Current Practice https://tools.ietf.org/html/draft-ietf-oauth-security-topics OAuth 2.0 Pushed Authorization Requests (PAR) https://cutt.ly/oauth-transaction-authorization OAuth 2.0 Rich Authorization Requests (RAR) https://openid.net/specs/openid-financial-api-jarm-ID1.html JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) https://tools.ietf.org/html/draft-fett-oauth-dpop Cross-Browser Payment Initiation Attack https://cutt.ly/cross-browser-payment-initation OpenID Connect 4 Identity Assurance https://openid.net/specs/openid-connect-4-identity-assurance.html Dr. Torsten Lodderstedt CTO, yes.com torsten@yes.com @tlodderstedt yes® Talk to me about - Details on OAuth Security Best Practices - The OAuth Security Workshop - Other emerging OAuth & OpenID stuff - Partnering with and working at yes.com
- 37. Mix-Up Attack
- 38. Mix-Up Attack GET /authorize... ASPSPPISPUser Forward Redirect to ASPSP1 2 ASPSP 1 Redirect to aisp.com/authok?code=42&... GET /authok?code=42&... User gives authorization for account access POST /token, code=42... Attacker learns code!
- 39. Mitigation GET /authorize... Redirect to aisp.com/authok?aspsp=2&code=42&... GET /authok?aspsp=2&code=... ASPSPPISP User gives authorization for account access User Redirect to ASPSP1 2 ASPSP 1 PISP can detect attack here! Mismatch between intended ASPSP (1) and ASPSP identity in the redirect URI (2) 1 Uses unique redirect URI for each ASPSP, e.g., by encoding ASPSP ID into URI parameter. Forward 2