diff --git a/rules/S7164/metadata.json b/rules/S7164/metadata.json new file mode 100644 index 00000000000..2c63c085104 --- /dev/null +++ b/rules/S7164/metadata.json @@ -0,0 +1,2 @@ +{ +} diff --git a/rules/S7164/secrets/metadata.json b/rules/S7164/secrets/metadata.json new file mode 100644 index 00000000000..f157715be21 --- /dev/null +++ b/rules/S7164/secrets/metadata.json @@ -0,0 +1,56 @@ +{ + "title": "Dropbox app credentials should not be disclosed", + "type": "VULNERABILITY", + "code": { + "impacts": { + "SECURITY": "HIGH" + }, + "attribute": "TRUSTWORTHY" + }, + "status": "ready", + "remediation": { + "func": "Constant\/Issue", + "constantCost": "30min" + }, + "tags": [ + "cwe", + "cert" + ], + "defaultSeverity": "Blocker", + "ruleSpecification": "RSPEC-7164", + "sqKey": "S7164", + "scope": "All", + "securityStandards": { + "CWE": [ + 798, + 259 + ], + "OWASP": [ + "A3" + ], + "CERT": [ + "MSC03-J." + ], + "OWASP Top 10 2021": [ + "A7" + ], + "PCI DSS 3.2": [ + "6.5.10" + ], + "PCI DSS 4.0": [ + "6.2.4" + ], + "ASVS 4.0": [ + "2.10.4", + "3.5.2", + "6.4.1" + ], + "STIG ASD_V5R3": [ + "V-222642" + ] + }, + "defaultQualityProfiles": [ + "Sonar way" + ], + "quickfix": "unknown" +} diff --git a/rules/S7164/secrets/rule.adoc b/rules/S7164/secrets/rule.adoc new file mode 100644 index 00000000000..728d81c8ca2 --- /dev/null +++ b/rules/S7164/secrets/rule.adoc @@ -0,0 +1,81 @@ + +include::../../../shared_content/secrets/description.adoc[] + +== Why is this an issue? + +include::../../../shared_content/secrets/rationale.adoc[] + +=== What is the potential impact? + +// Set value that can be used to refer to the type of secret in, for example: +// "An attacker can use this {secret_type} to ..." +:secret_type: credentials + +// Where possible, use predefined content for common impacts. This content can +// be found in the folder "shared_content/secrets/impact". +// When using predefined content, search for any required variables to be set and include them in this file. +// Not adding them will not trigger warnings. + +include::../../../shared_content/secrets/impact/oauth_token_compromise.adoc[] + +=== Secret storage best practice + +It is best practice to avoid hard-coding secrets into an application. This is +true even in situations where the secret cannot be kept completely safe, such as +where is must be distributed as part of a client application. + +Storing the secret outside of the application code makes it easier to manage +which secret is being used. For example, it can help to ensure that a production +secret is not accidentally used during development. + +== How to fix it + +include::../../../shared_content/secrets/fix/revoke.adoc[] + +include::../../../shared_content/secrets/fix/vault.adoc[] + +include::../../../shared_content/secrets/fix/oauth_pkce.adoc[] + +**Disable the implicit grant flow** + +Prior to the introduction of PKCE, the implicit grant flow was the recommended +solution for applications which cannot secure a `client_secret`. Dropbox allows +the implicit flow to be used for legacy compatibility purposes but PKCE should +be used for all new applications. The ability to use the implicit grant flow can +be disabled in the Dropbox App Console. + +=== Code examples + +==== Noncompliant code example + +[source,java,diff-id=1,diff-type=noncompliant,subs="attributes"] +---- +props.set("dropbox.app_key", "vqg7x6qd2pviu4r") +props.set("dropbox.app_secret", "d5r2k2le2ixosna") // Noncompliant +---- + +==== Compliant solution + +[source,java,diff-id=1,diff-type=compliant,subs="attributes"] +---- +props.set("dropbox.app_key", System.getenv("DROPBOX_APP_KEY")) +props.set("dropbox.app_secret", System.getenv("DROPBOX_APP_SECRET")) +---- + +//=== How does this work? + +//=== Pitfalls + +//=== Going the extra mile + +== Resources + +=== Documentation + +* Dropbox - https://www.dropbox.com/lp/developers/reference/oauth-guide[OAuth Guide] +* IETF Datatracker - https://datatracker.ietf.org/doc/html/rfc7636[RFC 7636: Proof Key for Code Exchange] +* IETF Datatracker - https://datatracker.ietf.org/doc/html/rfc6749#section-4.2[RFC 6749: The OAuth 2.0 Authorization Framework] - Implicit Grant + +include::../../../shared_content/secrets/resources/standards.adoc[] + +//=== Benchmarks diff --git a/shared_content/secrets/fix/oauth_pkce.adoc b/shared_content/secrets/fix/oauth_pkce.adoc new file mode 100644 index 00000000000..59681cf21d9 --- /dev/null +++ b/shared_content/secrets/fix/oauth_pkce.adoc @@ -0,0 +1,6 @@ +**Use OAuth 2.0 PKCE** + +Proof Key for Code Exchange (PKCE, RFC 7636) is an extension to OAuth 2.0. It +helps to protect authentication tokens when the `client_secret` value cannot be +kept secure, such as mobile applications and JavaScript single page +applications. diff --git a/shared_content/secrets/impact/oauth_token_compromise.adoc b/shared_content/secrets/impact/oauth_token_compromise.adoc new file mode 100644 index 00000000000..7c772663005 --- /dev/null +++ b/shared_content/secrets/impact/oauth_token_compromise.adoc @@ -0,0 +1,10 @@ +=== OAuth token compromise + +The OAuth 2.0 authorization code grant flow is a secure method of authorizing +a web application to access a third-party service. After the user authenticates +with the third-party service and grants access, the web application is sent a +single-use code. The application must then pass this code and a `client_secret` +value to the service in order to obtain a usable authentication token. + +If the `client_secret` value is disclosed, anyone who can intercept the +single-use code can then exchange it for a valid authentication token.