Create rule S7164: Dropbox app credentials should not be disclosed

rules/S7164/metadata.json

@@ -0,0 +1,2 @@
+{
+}

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"
+}

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

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.

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.