Modify rule S6652: Move content to shared directory (#2810)

rules/S6652/secrets/metadata.json

@@ -1,6 +1,12 @@
 {
   "title": "Sensitive secrets should not be disclosed",
   "type": "VULNERABILITY",
+  "code": {
+    "impacts": {
+      "SECURITY": "HIGH"
+    },
+    "attribute": "TRUSTWORTHY"
+  },
   "status": "ready",
   "remediation": {
     "func": "Constant\/Issue",

rules/S6652/secrets/rule.adoc

@@ -1,97 +1,33 @@
-Secret leaks often occur when a sensitive piece of authentication data is
-stored with the source code of an application. Considering the source code is
-intended to be deployed across multiple assets, including source code
-repositories or application hosting servers, the secrets might get exposed to an
-unintended audience.
+include::../../../shared_content/secrets/description.adoc[]
 
 == Why is this an issue?
 
-In most cases, trust boundaries are violated when a secret is exposed in a
-source code repository or an uncontrolled deployment environment.
-Unintended people who don't need to know the secret might get access to it. They
-might then be able to use it to gain unwanted access to associated services or
-resources.
-
-The trust issue can be more or less severe depending on the people's role and
-entitlement.
+include::../../../shared_content/secrets/rationale.adoc[]
 
 === What is the potential impact?
 
 The consequences vary greatly depending on the situation and the secret-exposed
 audience. Still, two main scenarios should be considered.
 
-==== Financial loss
+include::../../../shared_content/secrets/impact/financial_loss.adoc[]
 
-Financial losses can occur when a secret is used to access a paid
-third-party-provided service and is disclosed as part of the source code of
-client applications. Having the secret, each user of the application will be
-able to use it without limit to use the third party service to their own need,
-including in a way that was not expected.
-
-This additional use of the secret will lead to added costs with the service
-provider.
-
-Moreover, when rate or volume limiting is set up on the provider side, this
-additional use can prevent the regular operation of the affected application.
-This might result in a partial denial of service for all the application's
-users.
-
-==== Application's security downgrade
-
-A downgrade can happen when the disclosed secret is used to protect
-security-sensitive assets or features of the application. Depending on the
-affected asset or feature, the practical impact can range from a sensitive
-information leak to a complete takeover of the application, its hosting server
-or another linked component.
-
-For example, an application that would disclose a secret used to sign user
-authentication tokens would be at risk of user identity impersonation. An
-attacker accessing the leaked secret could sign session tokens for arbitrary
-users and take over their privileges and entitlements.
+include::../../../shared_content/secrets/impact/security_downgrade.adoc[]
 
 == How to fix it
 
-**Revoke the secret**
+include::../../../shared_content/secrets/fix/revoke.adoc[]
 
-Revoke any leaked secrets and remove them from the application source code.
+include::../../../shared_content/secrets/fix/recent_use.adoc[]
 
-
-Before revoking the secret, ensure that no other applications or processes is
-using it. Other usages of the secret will also be impacted when the secret is
-revoked.
-
-**Analyze recent secret use**
-
-When available, analyze authentication logs to identify any unintended or
-malicious use of the secret since its disclosure date. Doing this will allow
-determining if an attacker took advantage of the leaked secret and to what
-extent.
-
-This operation should be part of a global incident response process.
-
-**Use a secret vault**
-
-A secret vault should be used to generate and store the new secret. This
-will ensure the secret's security and any further unexpected disclosure.
-
-Depending on the development platform and the leaked secret type, multiple
-solutions are currently available.
+include::../../../shared_content/secrets/fix/vault.adoc[]
 
 === Code examples
 
-==== Noncompliant code example
+:example_secret: ghp_xd8KRQmqM8eGCdegBLeO5AJ4oS0VN3yWXWcw
+:example_name: client_secret
+:example_env: CLIENT_SECRET
 
-[source,java,diff-id=1,diff-type=noncompliant]
-----
-props.set("client_secret", "ghp_xd8KRQmqM8eGCdegBLeO5AJ4oS0VN3yWXWcw")
-----
-
-==== Compliant solution
-
-[source,java,diff-id=1,diff-type=compliant]
-----
-props.set("client_secret", System.getenv("CLIENT_SECRET"))
-----
+include::../../../shared_content/secrets/examples.adoc[]
 
 //=== How does this work?
 
@@ -99,15 +35,6 @@ props.set("client_secret", System.getenv("CLIENT_SECRET"))
 
 //=== Going the extra mile
 
-
-== Resources
-//=== Documentation
-//=== Articles & blog posts
-//=== Conference presentations
-=== Standards
-
-* https://cwe.mitre.org/data/definitions/798[MITRE] - CWE-798 - Use of Hard-coded Credentials
-* https://cwe.mitre.org/data/definitions/259[MITRE] - CWE-259 - Use of Hard-coded Password
-* https://www.sans.org/top25-software-errors/#cat3[SANS] - TOP 25 Most Dangerous Software Errors
+include::../../../shared_content/secrets/resources.adoc[]
 
 //=== Benchmarks

shared_content/secrets/description.adoc

@@ -0,0 +1,5 @@
+Secret leaks often occur when a sensitive piece of authentication data is
+stored with the source code of an application. Considering the source code is
+intended to be deployed across multiple assets, including source code
+repositories or application hosting servers, the secrets might get exposed to an
+unintended audience.

shared_content/secrets/examples.adoc

@@ -0,0 +1,13 @@
+==== Noncompliant code example
+
+[source,java,diff-id=1,diff-type=noncompliant,subs="attributes"]
+----
+props.set("{example_name}", "{example_secret}")
+----
+
+==== Compliant solution
+
+[source,java,diff-id=1,diff-type=compliant,subs="attributes"]
+----
+props.set("{example_name}", System.getenv("{example_env}"))
+----

shared_content/secrets/fix/recent_use.adoc

@@ -0,0 +1,8 @@
+**Analyze recent secret use**
+
+When available, analyze authentication logs to identify any unintended or
+malicious use of the secret since its disclosure date. Doing this will allow
+determining if an attacker took advantage of the leaked secret and to what
+extent.
+
+This operation should be part of a global incident response process.

shared_content/secrets/fix/revoke.adoc

@@ -0,0 +1,8 @@
+**Revoke the secret**
+
+Revoke any leaked secrets and remove them from the application source code.
+
+
+Before revoking the secret, ensure that no other applications or processes is
+using it. Other usages of the secret will also be impacted when the secret is
+revoked.

shared_content/secrets/fix/vault.adoc

@@ -0,0 +1,7 @@
+**Use a secret vault**
+
+A secret vault should be used to generate and store the new secret. This
+will ensure the secret's security and any further unexpected disclosure.
+
+Depending on the development platform and the leaked secret type, multiple
+solutions are currently available.

shared_content/secrets/impact/financial_loss.adoc

@@ -0,0 +1,15 @@
+==== Financial loss
+
+Financial losses can occur when a secret is used to access a paid
+third-party-provided service and is disclosed as part of the source code of
+client applications. Having the secret, each user of the application will be
+able to use it without limit to use the third party service to their own need,
+including in a way that was not expected.
+
+This additional use of the secret will lead to added costs with the service
+provider.
+
+Moreover, when rate or volume limiting is set up on the provider side, this
+additional use can prevent the regular operation of the affected application.
+This might result in a partial denial of service for all the application's
+users.

shared_content/secrets/impact/security_downgrade.adoc

@@ -0,0 +1,12 @@
+==== Application's security downgrade
+
+A downgrade can happen when the disclosed secret is used to protect
+security-sensitive assets or features of the application. Depending on the
+affected asset or feature, the practical impact can range from a sensitive
+information leak to a complete takeover of the application, its hosting server
+or another linked component.
+
+For example, an application that would disclose a secret used to sign user
+authentication tokens would be at risk of user identity impersonation. An
+attacker accessing the leaked secret could sign session tokens for arbitrary
+users and take over their privileges and entitlements.

shared_content/secrets/rationale.adoc

@@ -0,0 +1,8 @@
+In most cases, trust boundaries are violated when a secret is exposed in a
+source code repository or an uncontrolled deployment environment.
+Unintended people who don't need to know the secret might get access to it. They
+might then be able to use it to gain unwanted access to associated services or
+resources.
+
+The trust issue can be more or less severe depending on the people's role and
+entitlement.

shared_content/secrets/resources.adoc

@@ -0,0 +1,7 @@
+== Resources
+
+=== Standards
+
+* https://cwe.mitre.org/data/definitions/798[MITRE] - CWE-798 - Use of Hard-coded Credentials
+* https://cwe.mitre.org/data/definitions/259[MITRE] - CWE-259 - Use of Hard-coded Password
+* https://www.sans.org/top25-software-errors/#cat3[SANS] - TOP 25 Most Dangerous Software Errors