-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add first draft for documentation Part 5: Security considerations.
- Loading branch information
Showing
1 changed file
with
139 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,139 @@ | ||
| # Building a resource server in PHP, Part 5: Security considerations | ||
|
|
||
| This article is part of a series describing how to implement a resource server in PHP. | ||
|
|
||
| 1. Introduction | ||
| 2. Resource Server | ||
| 3. Authorization | ||
| 4. Authentication | ||
| 5. Security considerations | ||
|
|
||
| ## Part 5: Security consideration | ||
|
|
||
| ## Security Considerations (from [RFC6749: OAuth 2.0](https://tools.ietf.org/html/rfc6749)) | ||
|
|
||
| 1. **Client Authentication**<br> | ||
| - Web application clients MUST ensure confidentiality of client passwords and other client credentials. | ||
| - The authorization server MUST NOT issue client passwords or other client credentials to native application or user-agent-based application clients for the purpose of client authentication. | ||
| 2. **Client Impersonation**<br> | ||
| - The authorization server MUST authenticate the client whenever possible. | ||
| - The authorization server MUST require the registration of any redirection URI used for receiving authorization responses | ||
| 3. **Access Tokens**<br> | ||
| - Access token credentials MUST only be transmitted using TLS | ||
| - The client SHOULD request access tokens with the minimal scope necessary. | ||
| - The authorization server SHOULD take the client identity into account when choosing how to honor the requested scope | ||
| 4. **Refresh Tokens**<br> | ||
| - The authorization server MUST maintain the binding between a refresh token and the client to whom it was issued. | ||
| - Refresh tokens MUST only be transmitted using TLS | ||
| - The authorization server MUST verify the binding between the refresh token and client identity whenever the client identity can be authenticated. | ||
| 5. **Authorization Codes**<br> | ||
| - The transmission of authorization codes SHOULD be made over a secure channel, and the client SHOULD require the use of TLS with its redirection URI. | ||
| - Authorization codes MUST be short lived and single-use. | ||
| - If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code. | ||
| 6. **Authorization Code Redirection URI Manipulation**<br> | ||
| - the authorization server MUST ensure that the redirection URI used to obtain the authorization code is identical to the redirection URI provided when exchanging the authorization code for an access token. | ||
| - The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. | ||
| - If a redirection URI is provided in the request, the authorization server MUST validate it against the registered value. | ||
| 7. **Resource Owner Password Credentials**<br> | ||
| - Obsolete, do not use | ||
| 8. **Request Confidentiality**<br> | ||
| - Access tokens, refresh tokens, resource owner passwords, and client credentials MUST NOT be transmitted "in the clear". (i.e. without encryption) | ||
| - Authorization codes SHOULD NOT be transmitted in the clear. | ||
| - The "state" and "scope" parameters SHOULD NOT include sensitive client or resource owner information in plain text, as they can be transmitted over insecure channels or stored insecurely. | ||
| 9. **Ensuring Endpoint Authenticity**<br> | ||
| - the authorization server MUST require the use of TLS with server authentication | ||
| 10. **Credentials-Guessing Attacks**<br> | ||
| - The probability of an attacker guessing generated tokens (and other credentials not intended for handling by end-users) MUST be less than or equal to 2^(-128) | ||
| - The probability of an attacker guessing generated tokens (and other credentials not intended for handling by end-users) SHOULD be less than or equal to 2^(-160). | ||
| 11. **Phishing Attacks**<br> | ||
| - the authorization servers MUST require the use of TLS on every endpoint used for end-user interaction. | ||
| 12. **Cross-Site Request Forgery**<br> | ||
| - The client MUST implement CSRF protection for its redirection URI. | ||
| - The client SHOULD utilize the "state" request parameter to deliver this value (i.e. session cookie hash) to the authorization server when making an authorization request. | ||
| - The binding value used for CSRF protection MUST contain a non-guessable value | ||
| and the user-agent's authenticated state (e.g., session cookie, HTML5 local storage) MUST be kept in a location accessible only to the client and the user-agent (i.e., protected by same-origin policy). | ||
| - The authorization server MUST implement CSRF protection for its authorization endpoint | ||
| 13. **Clickjacking**<br> | ||
| - native applications SHOULD use external browsers instead of embedding browsers within the application when requesting end-user authorization. | ||
| 14. **Code Injection and Input Validation**<br> | ||
| - The authorization server and client MUST sanitize (and validate when possible) any value received -- in particular, the value of the "state" and "redirect_uri" parameters. | ||
| 15. **Open Redirectors**<br> | ||
| - No recommendation, obviously, do not allow open (i.e. unregistered) redirects | ||
| 16. **Misuse of Access Token to Impersonate Resource Owner in Implicit Flow**<br> | ||
| - Obsolete, do not use | ||
|
|
||
| ## Recommendations (from [OAuth 2.0 Security Best Current Practice](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15)) | ||
|
|
||
| 1. Protecting Redirect-Based Flows | ||
| - When comparing client redirect URIs against pre-registered URIs, authorization servers MUST utilize exact string matching. | ||
| - Clients MUST NOT expose URLs that forward the user's browser to arbitrary URIs obtained from a query parameter ("open redirector"). | ||
| - Clients MUST prevent Cross-Site Request Forgery (CSRF). | ||
| - Clients that have ensured that the authorization server supports PKCE [RFC7636] MAY rely the CSRF protection provided by PKCE. | ||
| - In OpenID Connect flows, the "nonce" parameter provides CSRF protection. Otherwise, one-time use CSRF tokens carried in the "state" parameter that are securely bound to the user agent MUST be used for CSRF protection | ||
| - clients MUST only process redirect responses of the authorization server they sent the respective request to and from the same user agent this authorization request was initiated with. | ||
| - Clients MUST store the authorization server they sent an authorization request to and bind this information to the user agent and check that the authorization request was received from the correct authorization server. | ||
| - Clients MUST ensure that the subsequent token request, if applicable, is sent to the same authorization server. | ||
| - Clients SHOULD use distinct redirect URIs for each authorization server as a means to identify the authorization server a particular response came from. | ||
| - An AS that redirects a request potentially containing user credentials MUST avoid forwarding these user credentials accidentally | ||
| - Authorization servers MUST support PKCE | ||
| - Authorization servers MUST provide a way to detect their support for PKCE. To this end, they MUST | ||
| (a) publish the element "code_challenge_methods_supported" in their AS metadata [RFC8414] OR | ||
| (b) provide a deployment-specific way to ensure or determine PKCE support by the AS. | ||
| - Clients MUST prevent injection (replay) of authorization codes into the authorization response by attackers. | ||
| The use of PKCE [RFC7636] is RECOMMENDED to this end. The OpenID Connect "nonce" parameter and ID Token Claim [OpenID] MAY be used as well. | ||
| - The PKCE challenge or OpenID Connect "nonce" MUST be transaction-specific and securely bound to the client and the user agent in which the transaction was started. | ||
| - When using PKCE, clients SHOULD use PKCE code challenge methods that do not expose the PKCE verifier in the authorization request. | ||
| - Clients SHOULD NOT use the implicit grant (response type "token") Clients SHOULD instead use the response type "code" (aka authorization code grant type) | ||
| 2. Token Replay Prevention | ||
| !!! HIER GEBLEVEN !!! https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.2 | ||
| 3. Access Token Privilege Restriction | ||
| 4. Resource Owner Password Credentials Grant | ||
| 5. Client Authentication | ||
| 6. Other Recommendations | ||
|
|
||
| ## Attacks and Mitigations (from [OAuth 2.0 Security Best Current Practice](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15)) | ||
|
|
||
| 1. Insufficient Redirect URI Validation | ||
| 1. Redirect URI Validation Attacks on Authorization Code Grant | ||
| 2. Redirect URI Validation Attacks on Implicit Grant | ||
| 2. Credential Leakage via Referer Headers | ||
| 1. Leakage from the OAuth Client | ||
| 2. Leakage from the Authorization Server | ||
| 3. Credential Leakage via Browser History | ||
| 1. Authorization Code in Browser History | ||
| 2. Access Token in Browser History | ||
| 4. Mix-Up Attacks | ||
| 5. Authorization Code Injection | ||
| 6. Access Token Injection | ||
| 7. Cross Site Request Forgery | ||
| 8. Access Token Leakage at the Resource Server | ||
| 1. Access Token Phishing by Counterfeit Resource Server | ||
| 2. Compromised Resource Server | ||
| 9. Open Redirection | ||
| 1. Client as Open Redirector | ||
| 2. Authorization Server as Open Redirector | ||
| 10. 307 Redirect | ||
| 11. TLS Terminating Reverse Proxies | ||
| 12. Refresh Token Protection | ||
| 13. Client Impersonating Resource Owner | ||
| 14. Clickjacking | ||
|
|
||
| ## Security Measures | ||
|
|
||
| ```php | ||
| header('Access-Control-Allow-Origin: https://server;'); | ||
| header('Content-Security-Policy: block-all-mixed-content;'); | ||
| header("Content-Security-Policy: form-action 'self';"); | ||
| header("Content-Security-Policy: frame-ancestors 'self';"); // Or 'none' | ||
| header('Content-Security-Policy: require-sri-for script style;'); | ||
| header('Cross-Origin-Embedder-Policy: require-corp;'); | ||
| header('Cross-Origin-Opener-Policy: same-origin-allow-popups'); | ||
| header('Cross-Origin-Resource-Policy: 'same-origin';'); | ||
| header('X-Frame-Options: SAMEORIGIN;'); // Or "DENY" | ||
| ``` | ||
|
|
||
| Or in the `<head>`: | ||
| ```html | ||
| <meta http-equiv="Content-Security-Policy" content="form-action 'self'"> | ||
| <meta http-equiv="Content-Security-Policy" content="block-all-mixed-content"> | ||
| ``` |