From afdd6f158f60ff8491906e1b5158874b4647e587 Mon Sep 17 00:00:00 2001 From: Jonas Wielage Date: Thu, 17 Aug 2023 10:03:05 +0200 Subject: [PATCH] run rules-api update --- .../l10n/secrets/rules/secrets/S6338.html | 66 +++++++++++++------ .../org/sonar/l10n/text/rules/text/S6389.json | 6 ++ sonarpedia-secrets/sonarpedia.json | 2 +- sonarpedia-text/sonarpedia.json | 2 +- 4 files changed, 54 insertions(+), 22 deletions(-) diff --git a/sonar-text-plugin/src/main/resources/org/sonar/l10n/secrets/rules/secrets/S6338.html b/sonar-text-plugin/src/main/resources/org/sonar/l10n/secrets/rules/secrets/S6338.html index b50a68a1d..dc57fc07e 100644 --- a/sonar-text-plugin/src/main/resources/org/sonar/l10n/secrets/rules/secrets/S6338.html +++ b/sonar-text-plugin/src/main/resources/org/sonar/l10n/secrets/rules/secrets/S6338.html @@ -1,25 +1,51 @@ +

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.

Why is this an issue?

-

Azure Storage Account Keys are similar to the root password, allowing full access to Azure Storage Accounts.

-

If the application interacts with Azure Cloud Storage services, access keys should be secured and not be disclosed.

-

Recommended Secure Coding Practices

-

Only administrators should have access to storage account keys. To authorize an application to access an Azure Storage, it’s recommended to create -a service principal and assign it the required privileges only. Azure -Identity SDK provides several options such as DefaultAzureCredential that can be used to retrieve secrets from, for instance, environment -variables.

-

Storage account keys should not be stored with the application code or saved anywhere in plain text accessible to others. Consider using an Azure Key Vault to store and manage keys.

-

When credentials are disclosed in the application code, consider them as compromised and rotate them immediately.

+

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.

+

What is the potential impact?

+

Azure Storage Account Keys are used to authenticate and authorize access to Azure Storage resources, such as blobs, queues, tables, and files. +These keys are used to authenticate requests made against the storage account.

+

If an Azure Storage Account Key is leaked to an unintended audience, it can pose a significant security risk to your Azure Storage account.

+

An attacker with access to your storage account key can potentially access and modify all the data stored in your storage account. They can also +create new resources, delete existing ones, and perform other actions that can compromise the integrity and confidentiality of your data.

+

In addition, an attacker with access to your storage account key can also incur charges on your account by creating and using resources, which can +result in unexpected billing charges.

+

How to fix it

+

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.

+

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 prevent any further unexpected +disclosure.

+

Depending on the development platform and the leaked secret type, multiple solutions are currently available.

+

Code examples

+

Noncompliant code example

+
+props.set("storage_key", "4dVw+l0W8My+FwuZ08dWXn+gHxcmBtS7esLAQSrm6/Om3jeyUKKGMkfAh38kWZlItThQYsg31v23A0w/uVP4pg==")
+
+

Compliant solution

+
+props.set("storage_key", System.getenv("STORAGE_KEY"))
+

Resources

+

Standards

+

Documentation

+ diff --git a/sonar-text-plugin/src/main/resources/org/sonar/l10n/text/rules/text/S6389.json b/sonar-text-plugin/src/main/resources/org/sonar/l10n/text/rules/text/S6389.json index dc0826db8..dbedb7e0c 100644 --- a/sonar-text-plugin/src/main/resources/org/sonar/l10n/text/rules/text/S6389.json +++ b/sonar-text-plugin/src/main/resources/org/sonar/l10n/text/rules/text/S6389.json @@ -1,6 +1,12 @@ { "title": "Using bidirectional characters is security-sensitive", "type": "SECURITY_HOTSPOT", + "code": { + "impacts": { + "SECURITY": "MEDIUM" + }, + "attribute": "CLEAR" + }, "status": "ready", "remediation": { "func": "Constant\/Issue", diff --git a/sonarpedia-secrets/sonarpedia.json b/sonarpedia-secrets/sonarpedia.json index 7b15b3375..06d5622db 100644 --- a/sonarpedia-secrets/sonarpedia.json +++ b/sonarpedia-secrets/sonarpedia.json @@ -3,7 +3,7 @@ "languages": [ "SECRETS" ], - "latest-update": "2023-08-07T09:33:29.463115100Z", + "latest-update": "2023-08-17T08:01:09.848962100Z", "options": { "no-language-in-filenames": true, "preserve-filenames": true diff --git a/sonarpedia-text/sonarpedia.json b/sonarpedia-text/sonarpedia.json index 2506f3509..c85781808 100644 --- a/sonarpedia-text/sonarpedia.json +++ b/sonarpedia-text/sonarpedia.json @@ -3,7 +3,7 @@ "languages": [ "TEXT" ], - "latest-update": "2023-05-12T06:10:47.094097868Z", + "latest-update": "2023-08-17T08:01:43.309196300Z", "options": { "no-language-in-filenames": true, "preserve-filenames": true