Skip to content

Commit c957e33

Browse files
author
Jeremi Do Dinh
authored
Update rule metadata. (#1643)
1 parent 3c7b6b1 commit c957e33

File tree

6 files changed

+319
-291
lines changed

6 files changed

+319
-291
lines changed

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

Lines changed: 33 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,8 @@ <h2>Ask Yourself Whether</h2>
1010
<h2>Recommended Secure Coding Practices</h2>
1111
<p>Do not enable debugging features on production servers or applications distributed to end users.</p>
1212
<h2>Sensitive Code Example</h2>
13-
<pre>
13+
<p>Django application startup:</p>
14+
<pre data-diff-id="1" data-diff-type="noncompliant">
1415
from django.conf import settings
1516

1617
settings.configure(DEBUG=True) # Sensitive when set to True
@@ -19,14 +20,40 @@ <h2>Sensitive Code Example</h2>
1920
def custom_config(config):
2021
settings.configure(default_settings=config, DEBUG=True) # Sensitive
2122
</pre>
22-
<p>Django’s "settings.py" or "global_settings.py" configuration file:</p>
23-
<pre>
24-
# NOTE: The following code raises issues only if the file is named "settings.py" or "global_settings.py". This is the default
25-
# name of Django configuration file
26-
23+
<p>Inside <code>settings.py</code> or <code>global_settings.py</code>, which are the default configuration files for a Django application:</p>
24+
<pre data-diff-id="2" data-diff-type="noncompliant">
2725
DEBUG = True # Sensitive
2826
DEBUG_PROPAGATE_EXCEPTIONS = True # Sensitive
2927
</pre>
28+
<p>Flask application startup:</p>
29+
<pre data-diff-id="3" data-diff-type="noncompliant">
30+
from flask import Flask
31+
32+
app = Flask()
33+
app.debug = True # Sensitive
34+
app.run(debug=True) # Sensitive
35+
</pre>
36+
<h2>Compliant Solution</h2>
37+
<pre data-diff-id="1" data-diff-type="compliant">
38+
from django.conf import settings
39+
40+
settings.configure(DEBUG=False)
41+
settings.configure(DEBUG_PROPAGATE_EXCEPTIONS=False)
42+
43+
def custom_config(config):
44+
settings.configure(default_settings=config, DEBUG=False)
45+
</pre>
46+
<pre data-diff-id="2" data-diff-type="compliant">
47+
DEBUG = False
48+
DEBUG_PROPAGATE_EXCEPTIONS = False
49+
</pre>
50+
<pre data-diff-id="3" data-diff-type="compliant">
51+
from flask import Flask
52+
53+
app = Flask()
54+
app.debug = False
55+
app.run(debug=False)
56+
</pre>
3057
<h2>See</h2>
3158
<ul>
3259
<li> <a href="https://owasp.org/Top10/A05_2021-Security_Misconfiguration/">OWASP Top 10 2021 Category A5</a> - Security Misconfiguration </li>

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

Lines changed: 0 additions & 61 deletions
Original file line numberDiff line numberDiff line change
@@ -113,67 +113,6 @@ <h4>Using trusted certificates</h4>
113113
<h4>Working with self-signed certificates or non-standard CAs</h4>
114114
<p>In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted
115115
roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.</p>
116-
<h2>How to fix it in HTTPX</h2>
117-
<h3>Code examples</h3>
118-
<p>The following code contains examples of disabled certificate validation.</p>
119-
<p>The certificate validation gets disabled by setting <code>verify</code> to <code>False</code>. To enable validation set the value to
120-
<code>True</code> or do not set <code>verify</code> at all to use the secure default value.</p>
121-
<h4>Noncompliant code example</h4>
122-
<pre data-diff-id="31" data-diff-type="noncompliant">
123-
import httpx
124-
125-
httpx.get('https://example.com', verify=False) # Noncompliant
126-
</pre>
127-
<h4>Compliant solution</h4>
128-
<pre data-diff-id="31" data-diff-type="compliant">
129-
import httpx
130-
131-
# By default, certificate validation is enabled
132-
httpx.get('https://example.com')
133-
</pre>
134-
<h3>How does this work?</h3>
135-
<p>Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.</p>
136-
<p>To avoid running into problems with invalid certificates, consider the following sections.</p>
137-
<h4>Using trusted certificates</h4>
138-
<p>If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list
139-
of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no
140-
additional code or configuration.</p>
141-
<h4>Working with self-signed certificates or non-standard CAs</h4>
142-
<p>In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted
143-
roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.</p>
144-
<h2>How to fix it in aiohttp</h2>
145-
<h3>Code examples</h3>
146-
<p>The following code contains examples of disabled certificate validation.</p>
147-
<p>The certificate validation gets disabled by setting <code>verify_ssl</code> to <code>False</code>. To enable validation set the value to
148-
<code>True</code> or do not set <code>verify_ssl</code> at all to use the secure default value.</p>
149-
<h4>Noncompliant code example</h4>
150-
<pre data-diff-id="41" data-diff-type="noncompliant">
151-
import aiohttp
152-
153-
async def example():
154-
async with aiohttp.ClientSession() as session:
155-
session.get("https://example.com", verify_ssl=False) # Noncompliant
156-
</pre>
157-
<h4>Compliant solution</h4>
158-
<pre data-diff-id="41" data-diff-type="compliant">
159-
import aiohttp
160-
161-
# By default, certificate validation is enabled
162-
163-
async def example():
164-
async with aiohttp.ClientSession() as session:
165-
session.get("https://example.com")
166-
</pre>
167-
<h3>How does this work?</h3>
168-
<p>Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.</p>
169-
<p>To avoid running into problems with invalid certificates, consider the following sections.</p>
170-
<h4>Using trusted certificates</h4>
171-
<p>If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list
172-
of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no
173-
additional code or configuration.</p>
174-
<h4>Working with self-signed certificates or non-standard CAs</h4>
175-
<p>In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted
176-
roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.</p>
177116
<h2>Resources</h2>
178117
<h3>Standards</h3>
179118
<ul>

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

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -111,6 +111,25 @@ <h4>Use a secure algorithm</h4>
111111
<p>It is highly recommended to use an algorithm that is currently considered secure by the cryptographic community. A common choice for such an
112112
algorithm is the Advanced Encryption Standard (AES).</p>
113113
<p>For block ciphers, it is not recommended to use algorithms with a block size that is smaller than 128 bits.</p>
114+
<h2>How to fix it in ssl</h2>
115+
<h3>Code examples</h3>
116+
<p>The following code contains examples of algorithms that are not considered highly resistant to cryptanalysis and thus should be avoided.</p>
117+
<h4>Noncompliant code example</h4>
118+
<pre data-diff-id="41" data-diff-type="noncompliant">
119+
import ssl
120+
121+
ciphers = 'RC4-SHA:RC4-MD5'
122+
ctx = ssl.create_default_context()
123+
ctx.set_ciphers(ciphers) # Noncompliant
124+
</pre>
125+
<h4>Compliant solution</h4>
126+
<pre data-diff-id="41" data-diff-type="compliant">
127+
import ssl
128+
129+
ctx = ssl.create_default_context()
130+
</pre>
131+
<h3>How does this work?</h3>
132+
<p>It is recommended to not override the ciphers but instead, use the secure default ciphers of the module, as they might change over time.</p>
114133
<h2>Resources</h2>
115134
<h3>Standards</h3>
116135
<ul>

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

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -101,6 +101,49 @@ <h4>Rotate your secret keys</h4>
101101
<p>Even with the strongest cipher algorithms, there is a risk that your secret keys may be compromised. Therefore, it is a good practice to
102102
periodically rotate your secret keys. By doing so, you limit the amount of time that an attacker can misuse a stolen key. When you rotate keys, be
103103
sure to allow a grace period where tokens signed with the old key are still accepted to prevent service disruptions.</p>
104+
<h2>How to fix it in python-jose</h2>
105+
<h3>Code examples</h3>
106+
<p>The following code contains an example of JWT decoding without verification of the signature.</p>
107+
<h4>Noncompliant code example</h4>
108+
<pre data-diff-id="111" data-diff-type="noncompliant">
109+
from jose import jwt
110+
111+
jwt.decode(token, None, options={"verify_signature": False}) # Noncompliant
112+
</pre>
113+
<h4>Compliant solution</h4>
114+
<p>By default, verification is enabled for the methods <code>decode</code> and <code>verify</code>.</p>
115+
<pre data-diff-id="111" data-diff-type="compliant">
116+
from jose import jwt
117+
118+
jwt.decode(token, key, algorithms=["HS256"])
119+
</pre>
120+
<h3>How does this work?</h3>
121+
<h4>Verify the signature of your tokens</h4>
122+
<p>Resolving a vulnerability concerning the validation of JWT token signatures is mainly about incorporating a critical step into your process:
123+
validating the signature every time a token is decoded. Just having a signed token using a secure algorithm is not enough. If you are not validating
124+
signatures, they are not serving their purpose.</p>
125+
<p>Every time your application receives a JWT, it needs to decode the token to extract the information contained within. It is during this decoding
126+
process that the signature of the JWT should also be checked.</p>
127+
<p>To resolve the issue follow these instructions:</p>
128+
<ol>
129+
<li> Use framework-specific functions for signature verification: Most programming frameworks that support JWTs provide specific functions to not
130+
only decode a token but also validate its signature simultaneously. Make sure to use these functions when handling incoming tokens. </li>
131+
<li> Handle invalid signatures appropriately: If a JWT’s signature does not validate correctly, it means the token is not trustworthy, indicating
132+
potential tampering. The action to take on encountering an invalid token should be denying the request carrying it and logging the event for further
133+
investigation. </li>
134+
<li> Incorporate signature validation in your tests: When you are writing tests for your application, include tests that check the signature
135+
validation functionality. This can help you catch any instances where signature verification might be unintentionally skipped or bypassed. </li>
136+
</ol>
137+
<p>By following these practices, you can ensure the security of your application’s JWT handling process, making it resistant to attacks that rely on
138+
tampering with tokens. Validation of the signature needs to be an integral and non-negotiable part of your token handling process.</p>
139+
<h3>Going the extra mile</h3>
140+
<h4>Securely store your secret keys</h4>
141+
<p>Ensure that your secret keys are stored securely. They should not be hard-coded into your application code or checked into your version control
142+
system. Instead, consider using environment variables, secure key management systems, or vault services.</p>
143+
<h4>Rotate your secret keys</h4>
144+
<p>Even with the strongest cipher algorithms, there is a risk that your secret keys may be compromised. Therefore, it is a good practice to
145+
periodically rotate your secret keys. By doing so, you limit the amount of time that an attacker can misuse a stolen key. When you rotate keys, be
146+
sure to allow a grace period where tokens signed with the old key are still accepted to prevent service disruptions.</p>
104147
<h2>Resources</h2>
105148
<h3>Standards</h3>
106149
<ul>

0 commit comments

Comments
 (0)