Skip to content

Commit 65112e8

Browse files
anton-haubner-sonarsourceanton-haubner-sonarsource
authored
Update rule metadata in preparation for release 4.6 (#1529)
1 parent c92dbda commit 65112e8

File tree

10 files changed

+142
-84
lines changed

10 files changed

+142
-84
lines changed

‎python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S104.html

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,5 @@
11
<h2>Why is this an issue?</h2>
2-
<p>A source file that grows too much tends to aggregate too many responsibilities and inevitably becomes harder to understand and, therefore, to
3-
maintain.</p>
2+
<p>When a source file grows too much, it can accumulate numerous responsibilities and become challenging to understand and maintain.</p>
43
<p>Above a specific threshold, refactor the file into smaller files whose code focuses on well-defined tasks. Those smaller files will be easier to
5-
understand and easier to test.</p>
4+
understand and test.</p>
65

‎python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S2053.html

Lines changed: 39 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -1,48 +1,52 @@
1+
<p>This vulnerability increases the likelihood that attackers are able to compute the cleartext of password hashes.</p>
12
<h2>Why is this an issue?</h2>
2-
<p>In cryptography, a "salt" is an extra piece of data which is included when hashing a password. This makes <code>rainbow-table attacks</code> more
3-
difficult. Using a cryptographic hash function without an unpredictable salt increases the likelihood that an attacker could successfully find the
4-
hash value in databases of precomputed hashes (called <code>rainbow-tables</code>).</p>
5-
<p>This rule raises an issue when a hashing function which has been specifically designed for hashing passwords, such as <code>PBKDF2</code>, is used
6-
with a non-random, reused or too short salt value. It does not raise an issue on base hashing algorithms such as <code>sha1</code> or <code>md5</code>
7-
as they should not be used to hash passwords.</p>
8-
<h2>Recommended Secure Coding Practices</h2>
9-
<ul>
10-
<li> Use hashing functions generating their own secure salt or generate a secure random value of at least 16 bytes. </li>
11-
<li> The salt should be unique by user password. </li>
12-
</ul>
13-
<h3>Noncompliant code example</h3>
14-
<p>hashlib</p>
15-
<pre>
3+
<p>During the process of password hashing, an additional component, known as a "salt," is often integrated to bolster the overall security. This salt,
4+
acting as a defensive measure, primarily wards off certain types of attacks that leverage pre-computed tables to crack passwords.</p>
5+
<p>However, potential risks emerge when the salt is deemed insecure. This can occur when the salt is consistently the same across all users or when it
6+
is too short or predictable. In scenarios where users share the same password and salt, their password hashes will inevitably mirror each other.
7+
Similarly, a short salt heightens the probability of multiple users unintentionally having identical salts, which can potentially lead to identical
8+
password hashes. These identical hashes streamline the process for potential attackers to recover clear-text passwords. Thus, the emphasis on
9+
implementing secure, unique, and sufficiently lengthy salts in password-hashing functions is vital.</p>
10+
<h3>What is the potential impact?</h3>
11+
<p>Despite best efforts, even well-guarded systems might have vulnerabilities that could allow an attacker to gain access to the hashed passwords.
12+
This could be due to software vulnerabilities, insider threats, or even successful phishing attempts that give attackers the access they need.</p>
13+
<p>Once the attacker has these hashes, they will likely attempt to crack them using a couple of methods. One is brute force, which entails trying
14+
every possible combination until the correct password is found. While this can be time-consuming, having the same salt for all users or a short salt
15+
can make the task significantly easier and faster.</p>
16+
<p>If multiple users have the same password and the same salt, their password hashes would be identical. This means that if an attacker successfully
17+
cracks one hash, they have effectively cracked all identical ones, granting them access to multiple accounts at once.</p>
18+
<p>A short salt, while less critical than a shared one, still increases the odds of different users having the same salt. This might create clusters
19+
of password hashes with identical salt that can then be attacked as explained before.</p>
20+
<p>With short salts, the probability of a collision between two users' passwords and salts couple might be low depending on the salt size. The shorter
21+
the salt, the higher the collision probability. In any case, using longer, cryptographically secure salt should be preferred.</p>
22+
<h2>How to fix it in Python Standard Library</h2>
23+
<h3>Code examples</h3>
24+
<p>The following code contains examples of hard-coded salts.</p>
25+
<h4>Noncompliant code example</h4>
26+
<pre data-diff-id="1" data-diff-type="noncompliant">
1627
import crypt
17-
from hashlib import pbkdf2_hmac
1828

19-
hash = pbkdf2_hmac('sha256', password, b'D8VxSmTZt2E2YV454mkqAY5e', 100000) # Noncompliant: salt is hardcoded
29+
hash = crypt.crypt(password) # Noncompliant
2030
</pre>
21-
<p>crypt</p>
22-
<pre>
23-
hash = crypt.crypt(password) # Noncompliant: salt is not provided
24-
</pre>
25-
<h3>Compliant solution</h3>
26-
<p>hashlib</p>
27-
<pre>
31+
<h4>Compliant solution</h4>
32+
<pre data-diff-id="1" data-diff-type="compliant">
2833
import crypt
29-
from hashlib import pbkdf2_hmac
3034

31-
salt = os.urandom(32)
32-
hash = pbkdf2_hmac('sha256', password, salt, 100000) # Compliant
33-
</pre>
34-
<p>crypt</p>
35-
<pre>
3635
salt = crypt.mksalt(crypt.METHOD_SHA256)
37-
hash = crypt.crypt(password, salt) # Compliant
36+
hash = crypt.crypt(password, salt)
3837
</pre>
38+
<h3>How does this work?</h3>
39+
<p>This code ensures that each user’s password has a unique salt value associated with it. It generates a salt randomly and with a length that
40+
provides the required security level. It uses a salt length of at least 16 bytes (128 bits), as recommended by industry standards.</p>
41+
<p>Here, the compliant code example ensures the salt is random and has a sufficient length by calling the <code>crypt.mksalt</code> function. This one
42+
internally uses a cryptographically secure pseudo random number generator.</p>
3943
<h2>Resources</h2>
44+
<h3>Standards</h3>
4045
<ul>
41-
<li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
42-
<li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
46+
<li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP</a> Top 10:2021 A02:2021 - Cryptographic Failures </li>
47+
<li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP</a> - Top 10 2017 - A03:2017 - Sensitive Data
4348
Exposure </li>
44-
<li> <a href="https://cwe.mitre.org/data/definitions/759">MITRE, CWE-759</a> - Use of a One-Way Hash without a Salt </li>
45-
<li> <a href="https://cwe.mitre.org/data/definitions/760">MITRE, CWE-760</a> - Use of a One-Way Hash with a Predictable Salt </li>
46-
<li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
49+
<li> <a href="https://cwe.mitre.org/data/definitions/759">CWE</a> - CWE-759: Use of a One-Way Hash without a Salt </li>
50+
<li> <a href="https://cwe.mitre.org/data/definitions/760">CWE</a> - CWE-760: Use of a One-Way Hash with a Predictable Salt </li>
4751
</ul>
4852

‎python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S4143.html

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
<h2>Why is this an issue?</h2>
22
<p>Storing a value inside a collection at a given key or index and then unconditionally overwriting it without reading the initial value is a case of
3-
"dead store".</p>
3+
a "dead store".</p>
44
<pre>
55
def swap(mylist, index1, index2):
66
tmp = mylist[index2]
@@ -15,5 +15,6 @@ <h2>Why is this an issue?</h2>
1515
mymap['a']['b'] = 42
1616
mymap['a']['b'] = 42 # Noncompliant
1717
</pre>
18-
<p>At best it is redundant and will confuse the reader, most often it is an error and not what the developer intended to do.</p>
18+
<p>This practice is redundant and will cause confusion for the reader. More importantly, it is often an error and not what the developer intended to
19+
do.</p>
1920

‎python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S5445.html

Lines changed: 64 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -1,36 +1,79 @@
1+
<p>Temporary files are considered insecurely created when the file existence check is performed separately from the actual file creation. Such a
2+
situation can occur when creating temporary files using normal file handling functions or when using dedicated temporary file handling functions that
3+
are not atomic.</p>
14
<h2>Why is this an issue?</h2>
2-
<p>Creating temporary files using insecure methods exposes the application to race conditions on filenames: a malicious user can try to create a file
3-
with a predictable name before the application does. A successful attack can result in other files being accessed, modified, corrupted or deleted.
4-
This risk is even higher if the application run with elevated permissions.</p>
5-
<p>In the past, it has led to the following vulnerabilities:</p>
6-
<ul>
7-
<li> <a href="https://nvd.nist.gov/vuln/detail/CVE-2014-1858">CVE-2014-1858</a> </li>
8-
<li> <a href="https://nvd.nist.gov/vuln/detail/CVE-2014-1932">CVE-2014-1932</a> </li>
9-
</ul>
10-
<h3>Noncompliant code example</h3>
11-
<pre>
5+
<p>Creating temporary files in a non-atomic way introduces race condition issues in the application’s behavior. Indeed, a third party can create a
6+
given file between when the application chooses its name and when it creates it.</p>
7+
<p>In such a situation, the application might use a temporary file that it does not entirely control. In particular, this file’s permissions might be
8+
different than expected. This can lead to trust boundary issues.</p>
9+
<h3>What is the potential impact?</h3>
10+
<p>Attackers with control over a temporary file used by a vulnerable application will be able to modify it in a way that will affect the application’s
11+
logic. By changing this file’s Access Control List or other operating system-level properties, they could prevent the file from being deleted or
12+
emptied. They may also alter the file’s content before or while the application uses it.</p>
13+
<p>Depending on why and how the affected temporary files are used, the exploitation of a race condition in an application can have various
14+
consequences. They can range from sensitive information disclosure to more serious application or hosting infrastructure compromise.</p>
15+
<h4>Information disclosure</h4>
16+
<p>Because attackers can control the permissions set on temporary files and prevent their removal, they can read what the application stores in them.
17+
This might be especially critical if this information is sensitive.</p>
18+
<p>For example, an application might use temporary files to store users' session-related information. In such a case, attackers controlling those
19+
files can access session-stored information. This might allow them to take over authenticated users' identities and entitlements.</p>
20+
<h4>Attack surface extension</h4>
21+
<p>An application might use temporary files to store technical data for further reuse or as a communication channel between multiple components. In
22+
that case, it might consider those files part of the trust boundaries and use their content without additional security validation or sanitation. In
23+
such a case, an attacker controlling the file content might use it as an attack vector for further compromise.</p>
24+
<p>For example, an application might store serialized data in temporary files for later use. In such a case, attackers controlling those files'
25+
content can change it in a way that will lead to an insecure deserialization exploitation. It might allow them to execute arbitrary code on the
26+
application hosting server and take it over.</p>
27+
<h2>How to fix it</h2>
28+
<h3>Code examples</h3>
29+
<p>The following code example is vulnerable to a race condition attack because it creates a temporary file using an unsafe API function.</p>
30+
<h4>Noncompliant code example</h4>
31+
<pre data-diff-id="1" data-diff-type="noncompliant">
1232
import tempfile
1333

1434
filename = tempfile.mktemp() # Noncompliant
1535
tmp_file = open(filename, "w+")
1636
</pre>
17-
<h3>Compliant solution</h3>
18-
<pre>
37+
<h4>Compliant solution</h4>
38+
<pre data-diff-id="1" data-diff-type="compliant">
1939
import tempfile
2040

21-
tmp_file1 = tempfile.NamedTemporaryFile(delete=False) # Compliant; Easy replacement to tempfile.mktemp()
22-
tmp_file2 = tempfile.NamedTemporaryFile() # Compliant; Created file will be automatically deleted
41+
tmp_file1 = tempfile.NamedTemporaryFile(delete=False)
42+
tmp_file2 = tempfile.NamedTemporaryFile()
2343
</pre>
44+
<h3>How does this work?</h3>
45+
<p>Applications should create temporary files so that no third party can read or modify their content. It requires that the files' name, location, and
46+
permissions are carefully chosen and set. This can be achieved in multiple ways depending on the applications' technology stacks.</p>
47+
<h4>Use a secure API function</h4>
48+
<p>Temporary files handling APIs generally provide secure functions to create temporary files. In most cases, they operate in an atomical way,
49+
creating and opening a file with a unique and unpredictable name in a single call. Those functions can often be used to replace less secure
50+
alternatives without requiring important development efforts.</p>
51+
<p>Here, the example compliant code uses the more secure <code>tempfile.NamedTemporaryFile</code> function to handle the temporary file creation.</p>
52+
<h4>Strong security controls</h4>
53+
<p>Temporary files can be created using unsafe functions and API as long as strong security controls are applied. Non-temporary file-handling
54+
functions and APIs can also be used for that purpose.</p>
55+
<p>In general, applications should ensure that attackers can not create a file before them. This turns into the following requirements when creating
56+
the files:</p>
57+
<ul>
58+
<li> Files should be created in a non-public directory. </li>
59+
<li> File names should be unique. </li>
60+
<li> File names should be unpredictable. They should be generated using a cryptographically secure random generator. </li>
61+
<li> File creation should fail if a target file already exists. </li>
62+
</ul>
63+
<p>Moreover, when possible, it is recommended that applications destroy temporary files after they have finished using them.</p>
2464
<h2>Resources</h2>
65+
<h3>Documentation</h3>
66+
<ul>
67+
<li> <a href="https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File">OWASP</a> - Insecure Temporary File </li>
68+
<li> <a href="https://docs.python.org/3/library/tempfile.html#deprecated-functions-and-variables">Python documentation</a> - tempfile </li>
69+
</ul>
70+
<h3>Standards</h3>
2571
<ul>
26-
<li> <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">OWASP Top 10 2021 Category A1</a> - Broken Access Control </li>
27-
<li> <a href="https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities">OWASP Top 10 2017 Category A9</a> -
72+
<li> <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">OWASP</a> - Top 10 2021 - A01:2021 - Broken Access Control </li>
73+
<li> <a href="https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities">OWASP</a> - Top 10 2017 - A9:2017 -
2874
Using Components with Known Vulnerabilities </li>
29-
<li> <a href="https://cwe.mitre.org/data/definitions/377">MITRE, CWE-377</a> - Insecure Temporary File </li>
30-
<li> <a href="https://cwe.mitre.org/data/definitions/379">MITRE, CWE-379</a> - Creation of Temporary File in Directory with Incorrect Permissions
75+
<li> <a href="https://cwe.mitre.org/data/definitions/377">MITRE</a> - CWE-377: Insecure Temporary File </li>
76+
<li> <a href="https://cwe.mitre.org/data/definitions/379">MITRE</a> - CWE-379: Creation of Temporary File in Directory with Incorrect Permissions
3177
</li>
32-
<li> <a href="https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File">OWASP, Insecure Temporary File</a> </li>
33-
<li> <a href="https://docs.python.org/3/library/tempfile.html#deprecated-functions-and-variables">Python tempfile module</a> </li>
34-
<li> <a href="https://docs.python.org/2.7/library/os.html">Python 2.7 os module</a> </li>
3578
</ul>
3679

‎python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6303.html

Lines changed: 10 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,15 @@
1-
<p>Using unencrypted RDS DB resources exposes data to unauthorized access to the underlying storage.<br> This includes database data, logs, automatic
2-
backups, read replicas, snapshots, and cluster metadata.</p>
1+
<p>Using unencrypted RDS DB resources exposes data to unauthorized access.<br> This includes database data, logs, automatic backups, read replicas,
2+
snapshots, and cluster metadata.</p>
33
<p>This situation can occur in a variety of scenarios, such as:</p>
44
<ul>
5-
<li> a malicious insider working at the cloud provider gains physical access to the storage device and exfiltrates data. </li>
6-
<li> unknown attackers penetrate the cloud provider’s logical infrastructure and systems for extortion. </li>
5+
<li> A malicious insider working at the cloud provider gains physical access to the storage device. </li>
6+
<li> Unknown attackers penetrate the cloud provider’s logical infrastructure and systems. </li>
7+
</ul>
8+
<p>After a successful intrusion, the underlying applications are exposed to:</p>
9+
<ul>
10+
<li> theft of intellectual property and/or personal data </li>
11+
<li> extortion </li>
12+
<li> denial of services and security bypasses via data corruption or deletion </li>
713
</ul>
814
<p>AWS-managed encryption at rest reduces this risk with a simple switch.</p>
915
<h2>Ask Yourself Whether</h2>

‎python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6333.html

Lines changed: 13 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,19 @@
1-
<p>A public API, which can be requested by any authenticated or unauthenticated identities, can lead to unauthorized actions and information
2-
disclosures.</p>
1+
<p>Creating APIs without authentication unnecessarily increases the attack surface on the target infrastructure.</p>
2+
<p>Unless another authentication method is used, attackers have the opportunity to attempt attacks against the underlying API.<br> This means attacks
3+
both on the functionality provided by the API and its infrastructure.</p>
34
<h2>Ask Yourself Whether</h2>
4-
<p>The public API:</p>
55
<ul>
6-
<li> exposes sensitive data like personal information. </li>
7-
<li> can be used to perform sensitive operations. </li>
6+
<li> The underlying API exposes all of its contents to any anonymous Internet user. </li>
87
</ul>
9-
<p>There is a risk if you answered yes to any of those questions.</p>
8+
<p>There is a risk if you answered yes to this question.</p>
109
<h2>Recommended Secure Coding Practices</h2>
11-
<p>It’s recommended to restrict API access to authorized entities, unless the API offers a non-sensitive service designed to be public.</p>
10+
<p>In general, prefer limiting API access to a specific set of people or entities.</p>
11+
<p>AWS provides multiple methods to do so:</p>
12+
<ul>
13+
<li> <code>AWS_IAM</code>, to use standard AWS IAM roles and policies. </li>
14+
<li> <code>COGNITO_USER_POOLS</code>, to use customizable OpenID Connect (OIDC) identity providers (IdP). </li>
15+
<li> <code>CUSTOM</code>, to use an AWS-independant OIDC provider, glued to the infrastructure with a Lambda authorizer. </li>
16+
</ul>
1217
<h2>Sensitive Code Example</h2>
1318
<p>For <a href="https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk.aws_apigateway/Resource.html">aws_cdk.aws_apigateway.Resource</a>:</p>
1419
<pre>
@@ -74,9 +79,9 @@ <h2>Compliant Solution</h2>
7479
</pre>
7580
<h2>See</h2>
7681
<ul>
77-
<li> <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">OWASP Top 10 2021 Category A1</a> - Broken Access Control </li>
7882
<li> <a href="https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html">AWS Documentation</a> -
7983
Controlling and managing access to a REST API in API Gateway </li>
84+
<li> <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">OWASP Top 10 2021 Category A1</a> - Broken Access Control </li>
8085
<li> <a href="https://cwe.mitre.org/data/definitions/284">MITRE, CWE-284</a> - Improper Access Control </li>
8186
<li> <a href="https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control
8287
</li>

‎python-checks/src/main/resources/org/sonar/l10n/py/rules/python/S6333.json

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44
"status": "ready",
55
"remediation": {
66
"func": "Constant\/Issue",
7-
"constantCost": "5min"
7+
"constantCost": "15min"
88
},
99
"tags": [
1010
"aws",

0 commit comments

Comments
 (0)