Modify S6290(secrets): Validation (#3079)

## Review

A dedicated reviewer checked the rule description successfully for:

- [ ] logical errors and incorrect information
- [ ] information gaps and missing content
- [ ] text style and tone
- [ ] PR summary and labels follow [the
guidelines](https://github.com/SonarSource/rspec/#to-modify-an-existing-rule)

---------

Co-authored-by: daniel-teuchert-sonarsource <141642369+daniel-teuchert-sonarsource@users.noreply.github.com>
This commit is contained in:
Loris S 2023-09-14 17:10:18 +02:00 committed by GitHub
parent 89c4343dd1
commit 80179dd99b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 44 additions and 36 deletions

View File

@ -1,49 +1,51 @@
include::../../../shared_content/secrets/description.adoc[]
== Why is this an issue?
AWS credentials are designed to authenticate and authorize requests to AWS.
include::../../../shared_content/secrets/rationale.adoc[]
If your application interacts with AWS then it requires AWS credentials to access all the resources it needs to function properly. Resources that can be accessed depend on the permission granted to the AWS account. These credentials may authenticate to the AWS account root user who has unrestricted access to all resources in your AWS account, including billing information.
This rule detects the following leaks:
This rule flags instances of:
* AWS Secret Access Keys
* AWS Access IDs
* AWS Session Tokens
* AWS Secret Access Key
* AWS Access ID
* AWS Session Token
=== What is the potential impact?
Below are some real-world scenarios that illustrate some impacts of an attacker
exploiting the secret.
== Recommended Secure Coding Practices
:secret_type: secret
Only administrators should have access to the AWS credentials used by your application.
include::../../../shared_content/secrets/impact/phishing.adoc[]
As a consequence, AWS credentials should not be stored along with the application code as they would grant special privilege to anyone who has access to the application source code.
include::../../../shared_content/secrets/impact/malware_distribution.adoc[]
Credentials should be stored outside of the code in a file that is never committed to your application code repository.
include::../../../shared_content/secrets/impact/financial_loss.adoc[]
If possible, a better alternative is to use your cloud provider's service for managing secrets. On AWS this service is called https://aws.amazon.com/fr/secrets-manager/[Secrets Manager].
== How to fix it
When credentials are disclosed in the application code, consider them as compromised and revoke them immediately.
include::../../../shared_content/secrets/fix/revoke.adoc[]
include::../../../shared_content/secrets/fix/vault.adoc[]
=== Code examples
:example_secret: kHeUAwnSUizTWpSbyGAz4f+As5LshPIjvtpswqGb
:example_name: aws-secret-access-key
:example_env: AWS_SECRET_ACCESS_KEY
include::../../../shared_content/secrets/examples.adoc[]
//=== How does this work?
//=== Pitfalls
//=== Going the extra mile
== Resources
* https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[OWASP Top 10 2021 Category A7] - Identification and Authentication Failures
* https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[OWASP Top 10 2017 Category A3] - Sensitive Data Exposure
* 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] - Porous Defenses
include::../../../shared_content/secrets/resources/standards.adoc[]
ifdef::env-github,rspecator-view[]
'''
== Implementation Specification
(visible only on this page)
=== Message
"xxxxx" detected here. Remove this cedential from your code.
- AWS Secret Access Key
- AWS Access Key ID
- AWS Session Token
endif::env-github,rspecator-view[]
//=== Benchmarks

View File

@ -1,6 +1,12 @@
==== Malware distribution
In addition, malware can be stored and distributed, both to users of the
service and other potential targets. +
It is important to note that this leak can lead to full system compromises in
the worst-case scenario.
Due to this vulnerability, malware can be stored and spread, both to users of
the service and to other potential targets. +
A malware depends on the attacker's intentions, as the following examples show:
* Cryptojacking malware, whose goal is to "mine" cryptocurrencies on the affected computers or servers.
* Spyware that spies out sensitive information from victims.
In the worst case, malware can cause the target systems to be completely
compromised and allow attackers to infiltrate the systems.