From 3fb1d15575ef72f8394e9ca2de737b9f394ae59e Mon Sep 17 00:00:00 2001 From: jamie-anderson-sonarsource Date: Wed, 13 Nov 2024 18:35:19 +0000 Subject: [PATCH 1/3] Create rule S7164 --- rules/S7164/metadata.json | 2 ++ rules/S7164/secrets/metadata.json | 56 +++++++++++++++++++++++++++++++ rules/S7164/secrets/rule.adoc | 50 +++++++++++++++++++++++++++ 3 files changed, 108 insertions(+) create mode 100644 rules/S7164/metadata.json create mode 100644 rules/S7164/secrets/metadata.json create mode 100644 rules/S7164/secrets/rule.adoc 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..bff098387fe --- /dev/null +++ b/rules/S7164/secrets/metadata.json @@ -0,0 +1,56 @@ +{ + "title": "SECRET_TYPE 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..28f3a64def8 --- /dev/null +++ b/rules/S7164/secrets/rule.adoc @@ -0,0 +1,50 @@ + +include::../../../shared_content/secrets/description.adoc[] + +== Why is this an issue? + +include::../../../shared_content/secrets/rationale.adoc[] + +=== What is the potential impact? + +// Optional: Give a general description of the secret and what it's used for. + +Below are some real-world scenarios that illustrate some impacts of an attacker +exploiting the secret. + +// 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: secret + +// 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/some_impact.adoc[] + +== How to fix it + +include::../../../shared_content/secrets/fix/revoke.adoc[] + +include::../../../shared_content/secrets/fix/vault.adoc[] + +=== Code examples + +:example_secret: example_secret_value +:example_name: java-property-name +:example_env: ENV_VAR_NAME + +include::../../../shared_content/secrets/examples.adoc[] + +//=== How does this work? + +//=== Pitfalls + +//=== Going the extra mile + +== Resources + +include::../../../shared_content/secrets/resources/standards.adoc[] + +//=== Benchmarks From 4fbec469097298320b2dc37102653e6d7ae914fa Mon Sep 17 00:00:00 2001 From: Jamie Anderson <127742609+jamie-anderson-sonarsource@users.noreply.github.com> Date: Thu, 14 Nov 2024 11:27:24 +0000 Subject: [PATCH 2/3] Initial content --- rules/S7164/secrets/metadata.json | 2 +- rules/S7164/secrets/rule.adoc | 38 ++++++++++++++++--- shared_content/secrets/fix/oauth_pkce.adoc | 6 +++ .../impact/oauth_token_compromise.adoc | 10 +++++ 4 files changed, 49 insertions(+), 7 deletions(-) create mode 100644 shared_content/secrets/fix/oauth_pkce.adoc create mode 100644 shared_content/secrets/impact/oauth_token_compromise.adoc diff --git a/rules/S7164/secrets/metadata.json b/rules/S7164/secrets/metadata.json index bff098387fe..f157715be21 100644 --- a/rules/S7164/secrets/metadata.json +++ b/rules/S7164/secrets/metadata.json @@ -1,5 +1,5 @@ { - "title": "SECRET_TYPE should not be disclosed", + "title": "Dropbox app credentials should not be disclosed", "type": "VULNERABILITY", "code": { "impacts": { diff --git a/rules/S7164/secrets/rule.adoc b/rules/S7164/secrets/rule.adoc index 28f3a64def8..857d482b6cb 100644 --- a/rules/S7164/secrets/rule.adoc +++ b/rules/S7164/secrets/rule.adoc @@ -14,14 +14,14 @@ exploiting the secret. // 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: secret +: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/some_impact.adoc[] +include::../../../shared_content/secrets/impact/oauth_token_compromise.adoc[] == How to fix it @@ -29,13 +29,33 @@ 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 -:example_secret: example_secret_value -:example_name: java-property-name -:example_env: ENV_VAR_NAME +==== 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 +---- -include::../../../shared_content/secrets/examples.adoc[] +==== 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? @@ -45,6 +65,12 @@ include::../../../shared_content/secrets/examples.adoc[] == 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..a086d5a2574 --- /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. From bbee1af01f99e5a26dd2ce63e7f5e23abb2fd775 Mon Sep 17 00:00:00 2001 From: Jamie Anderson <127742609+jamie-anderson-sonarsource@users.noreply.github.com> Date: Thu, 14 Nov 2024 11:46:16 +0000 Subject: [PATCH 3/3] Additional content --- rules/S7164/secrets/rule.adoc | 17 +++++++++++------ .../secrets/impact/oauth_token_compromise.adoc | 2 +- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/rules/S7164/secrets/rule.adoc b/rules/S7164/secrets/rule.adoc index 857d482b6cb..728d81c8ca2 100644 --- a/rules/S7164/secrets/rule.adoc +++ b/rules/S7164/secrets/rule.adoc @@ -7,11 +7,6 @@ include::../../../shared_content/secrets/rationale.adoc[] === What is the potential impact? -// Optional: Give a general description of the secret and what it's used for. - -Below are some real-world scenarios that illustrate some impacts of an attacker -exploiting the secret. - // 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 @@ -23,6 +18,16 @@ exploiting the secret. 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[] @@ -31,7 +36,7 @@ include::../../../shared_content/secrets/fix/vault.adoc[] include::../../../shared_content/secrets/fix/oauth_pkce.adoc[] -**Disable the Implicit Grant Flow** +**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 diff --git a/shared_content/secrets/impact/oauth_token_compromise.adoc b/shared_content/secrets/impact/oauth_token_compromise.adoc index a086d5a2574..7c772663005 100644 --- a/shared_content/secrets/impact/oauth_token_compromise.adoc +++ b/shared_content/secrets/impact/oauth_token_compromise.adoc @@ -1,4 +1,4 @@ -=== OAuth Token Compromise +=== 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