diff --git a/application-error-message.md b/application-error-message.md index 9e30ad5..2469cfb 100644 --- a/application-error-message.md +++ b/application-error-message.md @@ -5,6 +5,7 @@ cvss-score: 5.3 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N cwe-id: CWE-550 cwe-name: Server-generated Error Message Containing Sensitive Information +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.4, A.8.9, A.8.12, A.8.25 diff --git a/aspnet-debugging-enabled.md b/aspnet-debugging-enabled.md index 1455fae..f750a07 100644 --- a/aspnet-debugging-enabled.md +++ b/aspnet-debugging-enabled.md @@ -5,6 +5,7 @@ cvss-score: 5.3 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N cwe-id: CWE-489 cwe-name: Active Debug Code +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(a)(1), 164.312(d) ISO 27001: A.5.33, A.5.34, A.8.4, A.8.9, A.8.12, A.8.15, A.8.25 @@ -14,28 +15,28 @@ compliance: --- -The ASP.NET debug feature is useful for debugging ASP.NET web applications, and even be used for remote debugging. This feature can reveal sensitive information about the internals of the application, such as code snippets, environment variables, security keys, etc. All of this can be used by an attacker to increase the likelihood of an successful attack. - +The ASP.NET debug feature is useful for debugging ASP.NET web applications, and even be used for remote debugging. This feature can reveal sensitive information about the internals of the application, such as code snippets, environment variables, security keys, etc. All of this can be used by an attacker to increase the likelihood of an successful attack. + This debug feature should not be enabled in a production environment. ## How to fix {% tabs aspnet-debugging-enabled %} {% tab aspnet-debugging-enabled generic %} -ASP.NET debugging is a feature of the ASP.NET framework, configured in the `web.config` file. To disable it, you need to edit the `web.config` file and change the `debug` flag within your `compilation` directive to `false`: - -``` - - - - ... - - - - +ASP.NET debugging is a feature of the ASP.NET framework, configured in the `web.config` file. To disable it, you need to edit the `web.config` file and change the `debug` flag within your `compilation` directive to `false`: + +``` + + + + ... + + + + ``` {% endtab %} diff --git a/certificate-with-insufficient-key-size-or-usage-or-insecure-signature-algorithm.md b/certificate-with-insufficient-key-size-or-usage-or-insecure-signature-algorithm.md index 298707f..7b2d64b 100644 --- a/certificate-with-insufficient-key-size-or-usage-or-insecure-signature-algorithm.md +++ b/certificate-with-insufficient-key-size-or-usage-or-insecure-signature-algorithm.md @@ -5,6 +5,7 @@ cvss-score: 4.2 cvss-vector: CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N cwe-id: CWE-310 cwe-name: Cryptographic Issues +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1) ISO 27001: A.5.14, A.8.9, A.8.24 @@ -14,24 +15,24 @@ compliance: --- -We identified one or more issues with your X509 server certificate, which are detailed further below. - -This finding usually means that the certificate was emitted with insecure attributes. Common examples include: - - * Using 1024-bit RSA keys; - * Using the MD5 hashing algorithm for digital signatures; +We identified one or more issues with your X509 server certificate, which are detailed further below. + +This finding usually means that the certificate was emitted with insecure attributes. Common examples include: + + * Using 1024-bit RSA keys; + * Using the MD5 hashing algorithm for digital signatures; * Having an invalid `keyUsage` attribute. For example, using a certificate whose purpose does not allow it to be used for Digital Signature or Key Agreement. ## How to fix {% tabs certificate-with-insufficient-key-size-or-usage-or-insecure-signature-algorithm %} {% tab certificate-with-insufficient-key-size-or-usage-or-insecure-signature-algorithm generic %} -Please replace your X509 certificate as soon as possible. Use a certificate from a Certification Authority trusted by modern browsers, which should guarantee it fulfills all security requirements. If you are unsure about choosing a Certificate Authority, we recommend [Let's Encrypt](https://letsencrypt.org/). Let's Encrypt provides modern X509 certificates at no cost. - -If you are using an internal Certificate Authority, or are using self-signed certificates, please ensure that the following requirements are met: - - * Use RSA certificates with, at least, 2048-bit key size, or EC certificates with, at least, 256-bit key size; - * Ensure that a strong hash function is used in the certificate digital signature, such as SHA-256; +Please replace your X509 certificate as soon as possible. Use a certificate from a Certification Authority trusted by modern browsers, which should guarantee it fulfills all security requirements. If you are unsure about choosing a Certificate Authority, we recommend [Let's Encrypt](https://letsencrypt.org/). Let's Encrypt provides modern X509 certificates at no cost. + +If you are using an internal Certificate Authority, or are using self-signed certificates, please ensure that the following requirements are met: + + * Use RSA certificates with, at least, 2048-bit key size, or EC certificates with, at least, 256-bit key size; + * Ensure that a strong hash function is used in the certificate digital signature, such as SHA-256; * Ensure that the `keyUsage` attribute has the required flags: Digital Signature and Key Agreement. {% endtab %} diff --git a/cookie-without-httponly-flag.md b/cookie-without-httponly-flag.md index d4091d6..1480006 100644 --- a/cookie-without-httponly-flag.md +++ b/cookie-without-httponly-flag.md @@ -5,6 +5,7 @@ cvss-score: 3.1 cvss-vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N cwe-id: CWE-16 cwe-name: Configuration +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.25 @@ -14,18 +15,18 @@ compliance: --- -Not having the HttpOnly flag means that the cookie can be accessed by client side scripts, such as JavaScript. This vulnerability by itself is not useful to an attacker since he has no control over client side scripts. However, if a Cross Site Scripting (XSS) vulnerability is present, he might be able to introduce a malicious script in the application, and without the HttpOnly flag, he could read the vulnerable cookie's value. - -The most interesting cookie for an attacker is usually the session cookie as it allows him to steal the user's session. Other cookies might be interesting also, depending on the application and the cookie's purposes, so a good rule-of-thumb is to set HttpOnly flag to all cookies. - +Not having the HttpOnly flag means that the cookie can be accessed by client side scripts, such as JavaScript. This vulnerability by itself is not useful to an attacker since he has no control over client side scripts. However, if a Cross Site Scripting (XSS) vulnerability is present, he might be able to introduce a malicious script in the application, and without the HttpOnly flag, he could read the vulnerable cookie's value. + +The most interesting cookie for an attacker is usually the session cookie as it allows him to steal the user's session. Other cookies might be interesting also, depending on the application and the cookie's purposes, so a good rule-of-thumb is to set HttpOnly flag to all cookies. + Mitigating this kind of vulnerability greatly reduces the impact of other possible vulnerabilities, such as XSS, which are very common in most sites. ## How to fix {% tabs cookie-without-httponly-flag %} {% tab cookie-without-httponly-flag generic %} -To fix a vulnerability of this type, you just need to set the HttpOnly flag on the vulnerable cookie, effectively preventing it from being read by client side scripts. - +To fix a vulnerability of this type, you just need to set the HttpOnly flag on the vulnerable cookie, effectively preventing it from being read by client side scripts. + Depending on the language and technologies you are using, setting the HttpOnly flag could mean to enable it or setting it to true, either on the code of the application itself or in a configuration file of the webserver or Content Management System (CMS) you are using. {% endtab %} diff --git a/crlf-injection.md b/crlf-injection.md index fd8c5be..adb59b7 100644 --- a/crlf-injection.md +++ b/crlf-injection.md @@ -5,6 +5,7 @@ cvss-score: 3.7 cvss-vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N cwe-id: CWE-93 cwe-name: Improper Neutralization of CRLF Sequences ('CRLF Injection') +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.12 @@ -14,19 +15,19 @@ compliance: --- -A CRLF injection vulnerability allows an attacker to inject a CR (Carriage Return: ASCII 13, \r) and a LF (Line Feed: ASCII 10, \n) in user inputs, which are then inserted in the response to terminate lines and divide the header from the body in HTTP responses, in an unexpected manner. - +A CRLF injection vulnerability allows an attacker to inject a CR (Carriage Return: ASCII 13, \r) and a LF (Line Feed: ASCII 10, \n) in user inputs, which are then inserted in the response to terminate lines and divide the header from the body in HTTP responses, in an unexpected manner. + With a CRLF injection, an attacker takes control of the response body to perpetrate the attack. For example, the CRLF might allow the attacker to do an XSS (cross-site scripting) attack by removing the CSP (content security policy) protection and injecting malicious JavaScript into the body. ## How to fix {% tabs crlf-injection %} {% tab crlf-injection generic %} -To prevent a CRLF injection vulnerability, you should: - - * Not insert user input in the response headers. - * Use a library method that properly encodes header values. - +To prevent a CRLF injection vulnerability, you should: + + * Not insert user input in the response headers. + * Use a library method that properly encodes header values. + If your application needs to allow user input in a header, ensure the input only contains characters from a limited list, for instance, only alpha-numeric ones. {% endtab %} diff --git a/deprecated-tls-protocol-version-10-supported.md b/deprecated-tls-protocol-version-10-supported.md index 73f5cf0..f17e5b5 100644 --- a/deprecated-tls-protocol-version-10-supported.md +++ b/deprecated-tls-protocol-version-10-supported.md @@ -5,6 +5,7 @@ cvss-score: 4.2 cvss-vector: CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N cwe-id: CWE-327 cwe-name: Use of a Broken or Risky Cryptographic Algorithm +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1) ISO 27001: A.5.14, A.8.9, A.8.24 @@ -14,87 +15,87 @@ compliance: --- -TLS protocol version 1.0 is deprecated and is now considered insecure by security researchers and standards organizations alike. For example, the PCI (Payment Card Industry) Security Standards Council requires that TLS 1.0 is disabled starting from mid-2018. - -This version has a design flaw in the way encryption Initialization Vectors (IVs) are handled, and security researchers devised an attack called BEAST that may allow an attacker to eavesdrop on connections using TLS 1.0. -However, note that TLS 1.0 is not immediately insecure, especially because BEAST is primarily a client-side attack, so if browsers are up-to-date, the connections should be safe. - -In any case, the attacker needs to be able to eavesdrop and intercept the connection before being able to deliver the attack. This may be fairly common considering the frequency that clients establish connections over open Wi-Fi. - +TLS protocol version 1.0 is deprecated and is now considered insecure by security researchers and standards organizations alike. For example, the PCI (Payment Card Industry) Security Standards Council requires that TLS 1.0 is disabled starting from mid-2018. + +This version has a design flaw in the way encryption Initialization Vectors (IVs) are handled, and security researchers devised an attack called BEAST that may allow an attacker to eavesdrop on connections using TLS 1.0. +However, note that TLS 1.0 is not immediately insecure, especially because BEAST is primarily a client-side attack, so if browsers are up-to-date, the connections should be safe. + +In any case, the attacker needs to be able to eavesdrop and intercept the connection before being able to deliver the attack. This may be fairly common considering the frequency that clients establish connections over open Wi-Fi. + If you'd like to know more about secure TLS deployments, we have written an extensive article about it [here](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454). ## How to fix {% tabs deprecated-tls-protocol-version-10-supported %} {% tab deprecated-tls-protocol-version-10-supported generic %} -To fix this issue, you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above. - -For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that. - -If you are using Nginx, you may use the following snippet as a guideline: - -``` -server { - listen 443 ssl; - ... - ssl_protocols TLSv1.2 TLSv1.3; - ... -} -``` - -If using an Apache server, please refer to the following example: - -``` - - ... - SSLProtocol -all +TLSv1.2 +TLSv1.3 - ... - -``` - -Note that we are enabling TLS 1.2 and above, reflecting our ideal scenario. - +To fix this issue, you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above. + +For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that. + +If you are using Nginx, you may use the following snippet as a guideline: + +``` +server { + listen 443 ssl; + ... + ssl_protocols TLSv1.2 TLSv1.3; + ... +} +``` + +If using an Apache server, please refer to the following example: + +``` + + ... + SSLProtocol -all +TLSv1.2 +TLSv1.3 + ... + +``` + +Note that we are enabling TLS 1.2 and above, reflecting our ideal scenario. + If you need to cater to clients with very old TLS support, such as ancient mobile devices, and know what you are doing, you can keep TLS 1.0 enabled, despite the known weaknesses. These issues are not as serious as the SSL protocol weaknesses, but you should weigh the need to support older clients with the risk of exposing private data. Moreover, keep in mind that TLS 1.2 support is well over [95%](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454). {% endtab %} {% tab deprecated-tls-protocol-version-10-supported nginx %} -To fix this issue you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above. - -For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that. - -For Nginx, you may use the following snippet as a guideline: - -``` -server { - listen 443 ssl; - ... - ssl_protocols TLSv1.2 TLSv1.3; - ... -} -``` - -Note that we are enabling TLS 1.2 and above, reflecting our ideal scenario. - +To fix this issue you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above. + +For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that. + +For Nginx, you may use the following snippet as a guideline: + +``` +server { + listen 443 ssl; + ... + ssl_protocols TLSv1.2 TLSv1.3; + ... +} +``` + +Note that we are enabling TLS 1.2 and above, reflecting our ideal scenario. + If you need to cater to clients with very old TLS support, such as ancient mobile devices, and know what you are doing, you can keep TLS 1.0 enabled, despite the known weaknesses. These issues are not as serious as the SSL protocol weaknesses, but you should weight the need to support older clients with the risk of exposing private data. Moreover, keep in mind that TLS 1.2 support is well over [95%](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454). {% endtab %} {% tab deprecated-tls-protocol-version-10-supported apache %} -To fix this issue you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above. - -For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that. - -If using an Apache server, please refer to the following example: - -``` - - ... - SSLProtocol -all +TLSv1.2 +TLSv1.3 - ... - -``` - -Note that we are enabling TLS 1.2 and TLS 1.3, reflecting our ideal scenario. - +To fix this issue you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above. + +For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that. + +If using an Apache server, please refer to the following example: + +``` + + ... + SSLProtocol -all +TLSv1.2 +TLSv1.3 + ... + +``` + +Note that we are enabling TLS 1.2 and TLS 1.3, reflecting our ideal scenario. + If you need to cater to clients with very old TLS support, such as ancient mobile devices, and know what you are doing, you can keep TLS 1.0 enabled, despite the known weaknesses. These issues are not as serious as the SSL protocol weaknesses, but you should weight the need to support older clients with the risk of exposing private data. Moreover, keep in mind that TLS 1.2 support is well over [95%](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454). {% endtab %} diff --git a/deprecated-tls-protocol-version-11-supported.md b/deprecated-tls-protocol-version-11-supported.md index e82f885..dd16f60 100644 --- a/deprecated-tls-protocol-version-11-supported.md +++ b/deprecated-tls-protocol-version-11-supported.md @@ -5,6 +5,7 @@ cvss-score: 4.2 cvss-vector: CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N cwe-id: CWE-327 cwe-name: Use of a Broken or Risky Cryptographic Algorithm +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1) ISO 27001: A.5.14, A.8.9, A.8.24 @@ -14,43 +15,43 @@ compliance: --- -TLS protocol version 1.1 is outdated and deprecated by security standards such as NIST, PCI-DSS, and alike. - -This version has various design flaws that can undermine the security of your communications. The attacker still needs to be able to eavesdrop and intercept the connection before being able to deliver the attack, but given the widespread availability of open Wi-Fi hotspots, the risk cannot be ignored. - +TLS protocol version 1.1 is outdated and deprecated by security standards such as NIST, PCI-DSS, and alike. + +This version has various design flaws that can undermine the security of your communications. The attacker still needs to be able to eavesdrop and intercept the connection before being able to deliver the attack, but given the widespread availability of open Wi-Fi hotspots, the risk cannot be ignored. + If you'd like to know more about secure TLS deployments, we have written an extensive article about it [here](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454). ## How to fix {% tabs deprecated-tls-protocol-version-11-supported %} {% tab deprecated-tls-protocol-version-11-supported generic %} -To fix this issue, you need to disable TLS 1.1. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above. - -For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that. - -If you are using Nginx, you may use the following snippet as a guideline: - -``` -server { - listen 443 ssl; - ... - ssl_protocols TLSv1.2 TLSv1.3; - ... -} -``` - -If using an Apache server, please refer to the following example: - -``` - - ... - SSLProtocol -all +TLSv1.2 +TLSv1.3 - ... - -``` - -Note that we are enabling TLS 1.2 and above, reflecting our ideal scenario. - +To fix this issue, you need to disable TLS 1.1. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above. + +For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that. + +If you are using Nginx, you may use the following snippet as a guideline: + +``` +server { + listen 443 ssl; + ... + ssl_protocols TLSv1.2 TLSv1.3; + ... +} +``` + +If using an Apache server, please refer to the following example: + +``` + + ... + SSLProtocol -all +TLSv1.2 +TLSv1.3 + ... + +``` + +Note that we are enabling TLS 1.2 and above, reflecting our ideal scenario. + If you need to cater to clients with very old TLS support, such as ancient mobile devices, and know what you are doing, you can keep TLS 1.1 enabled, despite the known weaknesses. These issues are not as serious as the SSL protocol weaknesses, but you should weigh the need to support older clients with the risk of exposing private data. Moreover, keep in mind that TLS 1.2 support is well over [95%](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454). {% endtab %} diff --git a/directory-listing.md b/directory-listing.md index f039689..504596e 100644 --- a/directory-listing.md +++ b/directory-listing.md @@ -5,6 +5,7 @@ cvss-score: 5.3 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N cwe-id: CWE-548 cwe-name: Exposure of Information Through Directory Listing +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(a)(1), 164.312(d) ISO 27001: A.8.4, A.8.9 diff --git a/full-path-disclosure.md b/full-path-disclosure.md index b92ab71..956de5e 100644 --- a/full-path-disclosure.md +++ b/full-path-disclosure.md @@ -5,6 +5,7 @@ cvss-score: 5.3 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N cwe-id: CWE-200 cwe-name: Exposure of Sensitive Information to an Unauthorized Actor +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.4, A.8.9 @@ -13,48 +14,48 @@ compliance: --- -Full Path Disclosure vulnerabilities give the attacker information about the application internals, namely the path to a file hosted by the application server. Knowing the full path of files within the server can help the attacker explore other vulnerabilities, such as Path Traversal, Local File Include, and even SQL Injections. - +Full Path Disclosure vulnerabilities give the attacker information about the application internals, namely the path to a file hosted by the application server. Knowing the full path of files within the server can help the attacker explore other vulnerabilities, such as Path Traversal, Local File Include, and even SQL Injections. + By itself, this vulnerability does not pose an immediate risk to the application, since it is only giving away the location of a given file in the server. However, the name of the file and the enclosing folder name might reveal information that could be considered sensitive, if it gives advantage to a competitor. ## How to fix {% tabs full-path-disclosure %} {% tab full-path-disclosure generic %} -To fix this vulnerability you need to prevent the full path from being displayed in the application. Depending on how the message is being generated you might need to change its contents or even disable verbose errors to the client altogether. - +To fix this vulnerability you need to prevent the full path from being displayed in the application. Depending on how the message is being generated you might need to change its contents or even disable verbose errors to the client altogether. + Disabling verbose errors is the best approach, since it prevents current and future errors from being displayed, without the need to change individual errors and logging. {% endtab %} {% tab full-path-disclosure suspected-wordpress %} -By default, Wordpress installations expose some PHP files that when directly accessed through a browser will show an error that includes a full path from the application server, if you allow the application to display errors to clients. - -The root problem, in this case, is that your application shows these errors to whoever visits that URL. -Errors should be handled properly in the application, without being echoed to the client. Careful programming can handle most errors in a way they are caught and logged internally but not to the client. If errors need to be displayed to the client, they should be masked and displayed with friendly texts without any internal information. - -Wordpress uses PHP, so you need to set the PHP `display_errors` directive to off to prevent clients from viewing those error messages. -Depending on the technology used in the application, this can be configured at the framework level by enabling or disabling a setting, normally related to the displaying of errors. - - -For instance, if you use php-fpm you need to change the php-fpm configuration file. Most of the times it will be one of these: - -`/etc/php-fpm.d/.conf` (per virtual host configuration) - -`/etc/php-fpm.conf` (if you have a single php-fpm configuration) - - -
-In any case, add or uncomment the following line: - -``` - php_flag[display_errors] = off -``` - - -For other PHP installations, where the application reads a PHP ini file, use the following syntax: - -``` - display_errors = Off +By default, Wordpress installations expose some PHP files that when directly accessed through a browser will show an error that includes a full path from the application server, if you allow the application to display errors to clients. + +The root problem, in this case, is that your application shows these errors to whoever visits that URL. +Errors should be handled properly in the application, without being echoed to the client. Careful programming can handle most errors in a way they are caught and logged internally but not to the client. If errors need to be displayed to the client, they should be masked and displayed with friendly texts without any internal information. + +Wordpress uses PHP, so you need to set the PHP `display_errors` directive to off to prevent clients from viewing those error messages. +Depending on the technology used in the application, this can be configured at the framework level by enabling or disabling a setting, normally related to the displaying of errors. + + +For instance, if you use php-fpm you need to change the php-fpm configuration file. Most of the times it will be one of these: + +`/etc/php-fpm.d/.conf` (per virtual host configuration) + +`/etc/php-fpm.conf` (if you have a single php-fpm configuration) + + +
+In any case, add or uncomment the following line: + +``` + php_flag[display_errors] = off +``` + + +For other PHP installations, where the application reads a PHP ini file, use the following syntax: + +``` + display_errors = Off ``` {% endtab %} diff --git a/graphql-introspection-enabled.md b/graphql-introspection-enabled.md index 620ff2a..6f256ab 100644 --- a/graphql-introspection-enabled.md +++ b/graphql-introspection-enabled.md @@ -5,6 +5,7 @@ cvss-score: 5.3 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N cwe-id: CWE-200 cwe-name: Information Exposure +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.9 @@ -13,15 +14,15 @@ compliance: --- -GraphQL is an alternative to REST APIs, providing a query and manipulation language to the application dataset. -GraphQL Introspection is a feature that allows querying all the details of the supported API schema. An attacker can use it to obtain all the API's queries, types, fields, and directives, which in turn, can be abused to retrieve potentially sensitive information or to deliver injection attacks on the API endpoints. +GraphQL is an alternative to REST APIs, providing a query and manipulation language to the application dataset. +GraphQL Introspection is a feature that allows querying all the details of the supported API schema. An attacker can use it to obtain all the API's queries, types, fields, and directives, which in turn, can be abused to retrieve potentially sensitive information or to deliver injection attacks on the API endpoints. The more attack surface an attacker has access to, the more likely it is to find a vulnerability. ## How to fix {% tabs graphql-introspection-enabled %} {% tab graphql-introspection-enabled generic %} -The safest solution is to disable GraphQL Introspection. However, you can also leave Introspection enabled based on context information such as the environment or the requesting user or role. +The safest solution is to disable GraphQL Introspection. However, you can also leave Introspection enabled based on context information such as the environment or the requesting user or role. Please consult your GraphQL framework documentation for the correct way to disable it, or restrict access. {% endtab %} diff --git a/graphql-misconfiguration.md b/graphql-misconfiguration.md index cd5fa73..c79c270 100644 --- a/graphql-misconfiguration.md +++ b/graphql-misconfiguration.md @@ -5,6 +5,7 @@ cvss-score: 5.3 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N cwe-id: CWE-200 cwe-name: Information Exposure +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.9 @@ -13,11 +14,11 @@ compliance: --- -The application server is leaking information about its schema or system internals. - -Attackers can exploit this weakness by submitting invalid queries to the GraphQL application, which, if misconfigured, will provide suggestions for potential query fixes. This unintentional behavior leaks valuable schema information. - - +The application server is leaking information about its schema or system internals. + +Attackers can exploit this weakness by submitting invalid queries to the GraphQL application, which, if misconfigured, will provide suggestions for potential query fixes. This unintentional behavior leaks valuable schema information. + + Additionally, if the application returns a stack trace when an error occurs it can leak information about the code and the server. ## How to fix diff --git a/insecure-crossdomainxml-policy.md b/insecure-crossdomainxml-policy.md index 96858f5..c4eac70 100644 --- a/insecure-crossdomainxml-policy.md +++ b/insecure-crossdomainxml-policy.md @@ -5,6 +5,7 @@ cvss-score: 8.2 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N cwe-id: CWE-942 cwe-name: Permissive Cross-domain Policy with Untrusted Domains +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.2, A.8.3, A.8.9, A.8.25 @@ -13,31 +14,31 @@ compliance: --- -The Flash cross-domain policy file defines how flash applications from other domains can interact with the domain hosting this policy file. - -An `` directive in your crossdomain.xml file means that your application allows an arbitrary flash application (.swf files) running on an arbitrary domain to make requests to your domain and read its response. If a user is logged in your application and visits a site hosting a malicious flash application, that application can make authenticated requests on behalf of the user to your application, by sending the cookies your site sets. With this, it can potentially take control of the victim's account. - +The Flash cross-domain policy file defines how flash applications from other domains can interact with the domain hosting this policy file. + +An `` directive in your crossdomain.xml file means that your application allows an arbitrary flash application (.swf files) running on an arbitrary domain to make requests to your domain and read its response. If a user is logged in your application and visits a site hosting a malicious flash application, that application can make authenticated requests on behalf of the user to your application, by sending the cookies your site sets. With this, it can potentially take control of the victim's account. + If this vulnerability was reported as low severity, it means that Probely does not have the required context to determine the impact of this issue. You are allowing any arbitrary flash application running on any subdomain of your domain to make requests to your site and read its response. If you do not host any user-content on the subdomain specified in your policy then it is safe to ignore this vulnerability. ## How to fix {% tabs insecure-crossdomainxml-policy %} {% tab insecure-crossdomainxml-policy generic %} -To fix this vulnerability you should consider if your application needs to be accessed by flash applications (.swf files). Few applications have this requirement. - -If you don't have this requirement, you can safely delete the file, thus fixing the vulnerability. - -If you need the file, and you know which domains hosting flash files need to contact your application, you can whitelist those domains by listing each one in the file: - -``` - - - - - -``` -Only flash applications from these domains will be able to interact both-ways with your domain. - +To fix this vulnerability you should consider if your application needs to be accessed by flash applications (.swf files). Few applications have this requirement. + +If you don't have this requirement, you can safely delete the file, thus fixing the vulnerability. + +If you need the file, and you know which domains hosting flash files need to contact your application, you can whitelist those domains by listing each one in the file: + +``` + + + + + +``` +Only flash applications from these domains will be able to interact both-ways with your domain. + If you need arbitrary domains interacting with yours, you should consider hosting the endpoints that will be accessed in a isolated domain, different from the main one. Do not use a subdomain for this. With this isolation, you will be sure that requests from flash applications will not carry your main domain session cookies, and will not be able to access the account of the user. {% endtab %} diff --git a/insecure-php-object-deserialization.md b/insecure-php-object-deserialization.md index 968691c..d053798 100644 --- a/insecure-php-object-deserialization.md +++ b/insecure-php-object-deserialization.md @@ -5,6 +5,7 @@ cvss-score: 7.3 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L cwe-id: CWE-502 cwe-name: Deserialization of Untrusted Data +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1) ISO 27001: A.8.25 @@ -13,18 +14,18 @@ compliance: --- -An Insecure PHP Object deserialization vulnerability potentially allows an attacker to execute arbitrary code in the application, which can result in a total compromise of the application security. -These vulnerabilities occur when the attacker is able to input strings with serialized PHP objects, which are then read by a vulnerable unserialize function call. - +An Insecure PHP Object deserialization vulnerability potentially allows an attacker to execute arbitrary code in the application, which can result in a total compromise of the application security. +These vulnerabilities occur when the attacker is able to input strings with serialized PHP objects, which are then read by a vulnerable unserialize function call. + These attacks are not frequently seen as they are target specific, which makes mass exploitation difficult. A complete compromise of the application is hard to achieve because there are multiple conditions to be met. However, damage to the application might still be possible even if not all the requirements are met. ## How to fix {% tabs insecure-php-object-deserialization %} {% tab insecure-php-object-deserialization generic %} -The safest approach is to stop accepting serialized objects that can be tainted by the user. -If you need to use PHP object serialization, we strongly recommend you to use an HMAC, generated and validated server-side, on all serialized objects. This will ensure that serialized objects are not modified by the user in any way. - +The safest approach is to stop accepting serialized objects that can be tainted by the user. +If you need to use PHP object serialization, we strongly recommend you to use an HMAC, generated and validated server-side, on all serialized objects. This will ensure that serialized objects are not modified by the user in any way. + Alternatively, consider replacing the existing serialization format with a safe, standard data interchange format such as JSON. {% endtab %} diff --git a/insecure-ssl-protocol-version-2-supported.md b/insecure-ssl-protocol-version-2-supported.md index 8c2ca64..cf4dcf6 100644 --- a/insecure-ssl-protocol-version-2-supported.md +++ b/insecure-ssl-protocol-version-2-supported.md @@ -5,6 +5,7 @@ cvss-score: 5.9 cvss-vector: CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N cwe-id: CWE-327 cwe-name: Use of a Broken or Risky Cryptographic Algorithm +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1) ISO 27001: A.5.14, A.8.9, A.8.24 @@ -14,20 +15,20 @@ compliance: --- -SSL protocol version 2 is outdated and insecure. This version has multiple design flaws that may allow an attacker to eavesdrop on SSL-enabled communications. - -SSL version 2 is particularly insecure since multiple practical vulnerabilities have been shown, making it easy to intercept any communication where SSL version 2 is used. - +SSL protocol version 2 is outdated and insecure. This version has multiple design flaws that may allow an attacker to eavesdrop on SSL-enabled communications. + +SSL version 2 is particularly insecure since multiple practical vulnerabilities have been shown, making it easy to intercept any communication where SSL version 2 is used. + In any case, the attacker needs to be positioned between any endpoint participating in the connection, so it can eavesdrop and intercept the communications. This is fairly common, considering the frequency people establish connections over open Wi-Fi. ## How to fix {% tabs insecure-ssl-protocol-version-2-supported %} {% tab insecure-ssl-protocol-version-2-supported generic %} -To fix this vulnerability, you need to disable SSL version 2, and enable TLS 1.2 and TLS 1.3, if they are not enabled already. - -You should disable SSL 2, and enable TLS 1.2 and above. If you are keeping SSL and older TLS versions (i.e. TLS <= 1.1) enabled to support "older devices", do note that as of 2018, TLS 1.2 is at 94%+ adoption. So there is a strong argument to keep only TLS 1.2 and above enabled. - +To fix this vulnerability, you need to disable SSL version 2, and enable TLS 1.2 and TLS 1.3, if they are not enabled already. + +You should disable SSL 2, and enable TLS 1.2 and above. If you are keeping SSL and older TLS versions (i.e. TLS <= 1.1) enabled to support "older devices", do note that as of 2018, TLS 1.2 is at 94%+ adoption. So there is a strong argument to keep only TLS 1.2 and above enabled. + You must change the web server configuration to enable or disable the protocols, so this will depend on your particular web server configuration procedures. {% endtab %} diff --git a/insecure-ssl-protocol-version-3-supported.md b/insecure-ssl-protocol-version-3-supported.md index e54995a..ab77958 100644 --- a/insecure-ssl-protocol-version-3-supported.md +++ b/insecure-ssl-protocol-version-3-supported.md @@ -5,6 +5,7 @@ cvss-score: 6.8 cvss-vector: CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N cwe-id: CWE-327 cwe-name: Use of a Broken or Risky Cryptographic Algorithm +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1) ISO 27001: A.5.14, A.8.9, A.8.24 @@ -14,20 +15,20 @@ compliance: --- -SSL protocol version 3 is outdated and insecure. This version has multiple design flaws that may allow an attacker to eavesdrop on SSL-enabled communications. - -SSL version 3 is not immediately broken but has various weaknesses that undermine the trust in the protocol. - +SSL protocol version 3 is outdated and insecure. This version has multiple design flaws that may allow an attacker to eavesdrop on SSL-enabled communications. + +SSL version 3 is not immediately broken but has various weaknesses that undermine the trust in the protocol. + In any case, the attacker needs to be positioned between any endpoint participating in the connection, so it can eavesdrop and intercept the communications. This is fairly common considering the frequency people establish connections over open Wi-Fi. ## How to fix {% tabs insecure-ssl-protocol-version-3-supported %} {% tab insecure-ssl-protocol-version-3-supported generic %} -To fix this vulnerability, you need to disable SSL version 3, and enable TLS 1.2 and TLS 1.3, if they are not enabled already. - -You should disable SSL 3, and enable TLS 1.2 and above. If you are keeping SSL and older TLS versions (i.e. TLS <= 1.1) enabled to support "older devices", do note that as of 2018, TLS 1.2 is at 94%+ adoption. So there is a strong argument to keep only TLS 1.2 and above enabled. - +To fix this vulnerability, you need to disable SSL version 3, and enable TLS 1.2 and TLS 1.3, if they are not enabled already. + +You should disable SSL 3, and enable TLS 1.2 and above. If you are keeping SSL and older TLS versions (i.e. TLS <= 1.1) enabled to support "older devices", do note that as of 2018, TLS 1.2 is at 94%+ adoption. So there is a strong argument to keep only TLS 1.2 and above enabled. + You must change the web server configuration to enable or disable the protocols, so this will depend on your particular web server configuration procedures. {% endtab %} diff --git a/jquery-library-with-known-vulnerabilities.md b/jquery-library-with-known-vulnerabilities.md index a03552f..60d375d 100644 --- a/jquery-library-with-known-vulnerabilities.md +++ b/jquery-library-with-known-vulnerabilities.md @@ -5,6 +5,7 @@ cvss-score: 4.8 cvss-vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N cwe-id: CWE-1035 cwe-name: OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.9 @@ -20,8 +21,8 @@ The application uses an outdated version of the JQuery library, which has known {% tabs jquery-library-with-known-vulnerabilities %} {% tab jquery-library-with-known-vulnerabilities generic %} -To fix this issue, please update JQuery to the latest available version on its official website. - +To fix this issue, please update JQuery to the latest available version on its official website. + Do not forget to update all the JQuery files you have on the server. {% endtab %} diff --git a/jquery-migrate-library-with-known-vulnerabilities.md b/jquery-migrate-library-with-known-vulnerabilities.md index c2000b8..f1780ea 100644 --- a/jquery-migrate-library-with-known-vulnerabilities.md +++ b/jquery-migrate-library-with-known-vulnerabilities.md @@ -5,6 +5,7 @@ cvss-score: 4.8 cvss-vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N cwe-id: CWE-1035 cwe-name: OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.9 @@ -20,8 +21,8 @@ The application uses an outdated version of the JQuery Migrate library, which ha {% tabs jquery-migrate-library-with-known-vulnerabilities %} {% tab jquery-migrate-library-with-known-vulnerabilities generic %} -To fix this issue, please update JQuery Migrate to the latest available version on its official website. - +To fix this issue, please update JQuery Migrate to the latest available version on its official website. + Do not forget to update all the JQuery Migrate files you have on the server. {% endtab %} diff --git a/jquery-mobile-library-with-known-vulnerabilities.md b/jquery-mobile-library-with-known-vulnerabilities.md index bdccb5b..5670e15 100644 --- a/jquery-mobile-library-with-known-vulnerabilities.md +++ b/jquery-mobile-library-with-known-vulnerabilities.md @@ -5,6 +5,7 @@ cvss-score: 4.8 cvss-vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N cwe-id: CWE-1035 cwe-name: OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.9 @@ -20,8 +21,8 @@ The application uses an outdated version of the JQuery Mobile library, which has {% tabs jquery-mobile-library-with-known-vulnerabilities %} {% tab jquery-mobile-library-with-known-vulnerabilities generic %} -To fix this issue, please update JQuery Mobile to the latest available version on its official website. - +To fix this issue, please update JQuery Mobile to the latest available version on its official website. + Do not forget to update all the JQuery Mobile files you have on the server. {% endtab %} diff --git a/jquery-ui-library-with-known-vulnerabilities.md b/jquery-ui-library-with-known-vulnerabilities.md index ef925dc..77e45e5 100644 --- a/jquery-ui-library-with-known-vulnerabilities.md +++ b/jquery-ui-library-with-known-vulnerabilities.md @@ -5,6 +5,7 @@ cvss-score: 4.8 cvss-vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N cwe-id: CWE-1035 cwe-name: OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.9 @@ -20,8 +21,8 @@ The application uses an outdated version of the jQuery UI library, which has kno {% tabs jquery-ui-library-with-known-vulnerabilities %} {% tab jquery-ui-library-with-known-vulnerabilities generic %} -To fix this issue, please update JQuery UI to the latest available version on its official website. - +To fix this issue, please update JQuery UI to the latest available version on its official website. + Do not forget to update all the jQuery UI files you have on the server. {% endtab %} diff --git a/jwt-accepting-none-algorithm.md b/jwt-accepting-none-algorithm.md index e12b379..01c38ed 100644 --- a/jwt-accepting-none-algorithm.md +++ b/jwt-accepting-none-algorithm.md @@ -5,6 +5,7 @@ cvss-score: 7.5 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N cwe-id: CWE-345 cwe-name: Insufficient Verification of Data Authenticity +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1) ISO 27001: A.8.2, A.8.3, A.8.5, A.8.24, A.8.25 diff --git a/jwt-algorithm-confusion.md b/jwt-algorithm-confusion.md index 52d6284..5e6172c 100644 --- a/jwt-algorithm-confusion.md +++ b/jwt-algorithm-confusion.md @@ -5,6 +5,7 @@ cvss-score: 7.5 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N cwe-id: CWE-345 cwe-name: Insufficient Verification of Data Authenticity +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1) ISO 27001: A.8.2, A.8.3, A.8.5, A.8.24, A.8.25 diff --git a/jwt-signature-is-not-being-verified.md b/jwt-signature-is-not-being-verified.md index d14f4ca..28e99d8 100644 --- a/jwt-signature-is-not-being-verified.md +++ b/jwt-signature-is-not-being-verified.md @@ -5,6 +5,7 @@ cvss-score: 7.5 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N cwe-id: CWE-345 cwe-name: Insufficient Verification of Data Authenticity +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1) ISO 27001: A.8.2, A.8.3, A.8.5, A.8.24, A.8.25 diff --git a/log-file-disclosure.md b/log-file-disclosure.md index 3d732d5..f343402 100644 --- a/log-file-disclosure.md +++ b/log-file-disclosure.md @@ -5,6 +5,7 @@ cvss-score: 5.3 cvss-vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N cwe-id: CWE-200 cwe-name: Exposure of Sensitive Information to an Unauthorized Actor +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.9, A.8.15 @@ -13,8 +14,8 @@ compliance: --- -A log file was found in the application document root, meaning it is available for viewing to anyone browsing through the application. - +A log file was found in the application document root, meaning it is available for viewing to anyone browsing through the application. + Since the location of the log file is easy to guess or it is a well-known path used for logs, it is very easy for an attacker to find it and take advantage of sensitive data that it may contain. Depending on the information present in the log, access to it may increase the probability of exploitation of other vulnerabilities, or even facilitate the take over of user accounts. ## How to fix diff --git a/missing-cross-site-request-forgery-protection.md b/missing-cross-site-request-forgery-protection.md index dd1716f..c451f8b 100644 --- a/missing-cross-site-request-forgery-protection.md +++ b/missing-cross-site-request-forgery-protection.md @@ -5,6 +5,7 @@ cvss-score: 6.5 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N cwe-id: CWE-352 cwe-name: Cross-Site Request Forgery (CSRF) +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.2, A.8.3, A.8.25 @@ -42,40 +43,40 @@ If you are using a framework to build your application, it is likely that it has {% endtab %} {% tab missing-cross-site-request-forgery-protection php %} -To prevent a CSRF you need to add a secret token to the vulnerable form (or the URL, if the vulnerable action is a GET). You generate a per-session token and add it to the user session: - -``` - if (isLoginValid($username, $password)) { - session_regenerate_id(); - $_SESSION["csrf_token"] = bin2hex(openssl_random_pseudo_bytes(32)); - // if you are using PHP 7 you can use the line below instead - // $_SESSION["csrf_token"] = bin2hex(random_bytes(32)); - } - else { - echo "invalid username or password"; - return; - } -``` - -Then, every time you generate a form, add the token to a hidden field: - -``` -
- "
- New email:
- -
-``` - -Finally, you need to check if the token is right when receiving the form. If its right, the form submission is legit. If not you just prevented an CSRF attack. - -``` - if (array_key_exists("csrf_token", $_POST) && $_POST["csrf_token"] === $_SESSION["csrf_token"]) { - // form is valid, proceed - } - else { - // form is invalid, do not proceed - } +To prevent a CSRF you need to add a secret token to the vulnerable form (or the URL, if the vulnerable action is a GET). You generate a per-session token and add it to the user session: + +``` + if (isLoginValid($username, $password)) { + session_regenerate_id(); + $_SESSION["csrf_token"] = bin2hex(openssl_random_pseudo_bytes(32)); + // if you are using PHP 7 you can use the line below instead + // $_SESSION["csrf_token"] = bin2hex(random_bytes(32)); + } + else { + echo "invalid username or password"; + return; + } +``` + +Then, every time you generate a form, add the token to a hidden field: + +``` +
+ "
+ New email:
+ +
+``` + +Finally, you need to check if the token is right when receiving the form. If its right, the form submission is legit. If not you just prevented an CSRF attack. + +``` + if (array_key_exists("csrf_token", $_POST) && $_POST["csrf_token"] === $_SESSION["csrf_token"]) { + // form is valid, proceed + } + else { + // form is invalid, do not proceed + } ``` {% endtab %} diff --git a/mongodb-injection.md b/mongodb-injection.md index 624eef7..55d9cbd 100644 --- a/mongodb-injection.md +++ b/mongodb-injection.md @@ -5,6 +5,7 @@ cvss-score: 7.5 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N cwe-id: CWE-943 cwe-name: Improper Neutralization of Special Elements in Data Query Logic +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.12, A.8.25 @@ -14,16 +15,16 @@ compliance: --- -By abusing a poorly sanitized input, an attacker is able to exploit the application and inject arbitrary code into MongoDB. This vulnerability allows an attacker to tamper with existing MongoDB queries performed by the web application. Depending on the queries, the attacker might be able to access, modify or even destroy data from the database. - +By abusing a poorly sanitized input, an attacker is able to exploit the application and inject arbitrary code into MongoDB. This vulnerability allows an attacker to tamper with existing MongoDB queries performed by the web application. Depending on the queries, the attacker might be able to access, modify or even destroy data from the database. + Since databases are commonly used to store private data, such as authentication information, personal user data, and site content, if an attacker gains access to it, the consequences are typically very severe, ranging from defacement of the web application to users data leakage or loss, or even full control of the web application or database server. ## How to fix {% tabs mongodb-injection %} {% tab mongodb-injection generic %} -Generating queries by hand is considered a bad practice and should be replaced by the most suitable application driver, as the MongoDB documentation recommends. In addition, sanitize all input, restricting it to only acceptable values. For instance, if the expected input is a number, ensure it matches a number, rejecting everything else. - +Generating queries by hand is considered a bad practice and should be replaced by the most suitable application driver, as the MongoDB documentation recommends. In addition, sanitize all input, restricting it to only acceptable values. For instance, if the expected input is a number, ensure it matches a number, rejecting everything else. + Keep in mind that if the attacker can also target the parameter name itself (example: "password[$ne]=2"), making it is necessary to be careful with both the name and the value of the parameter. {% endtab %} diff --git a/open-redirection.md b/open-redirection.md index 60563db..d627f65 100644 --- a/open-redirection.md +++ b/open-redirection.md @@ -5,6 +5,7 @@ cvss-score: 8.2 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:H/A:N cwe-id: CWE-601 cwe-name: URL Redirection to Untrusted Site ('Open Redirect') +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.25 diff --git a/os-command-injection.md b/os-command-injection.md index 4efc7f9..296bdc1 100644 --- a/os-command-injection.md +++ b/os-command-injection.md @@ -5,6 +5,7 @@ cvss-score: 9.8 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H cwe-id: CWE-77 cwe-name: Command Injection +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.12, A.8.25 diff --git a/path-traversal.md b/path-traversal.md index 4717601..5d805b8 100644 --- a/path-traversal.md +++ b/path-traversal.md @@ -5,6 +5,7 @@ cvss-score: 7.5 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N cwe-id: CWE-22 cwe-name: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(a)(1), 164.312(d) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.4, A.8.12, A.8.25 @@ -14,22 +15,22 @@ compliance: --- -A path traversal vulnerability occurs when the application places user input in filesystem operations without proper care. The attacker explores this vulnerability, typically, with various sequences of dot-dot-slash (../) characters that change the file being read or written to one of his choice, possibly even outside of the root folder of the application. Other possibility is for the attacker to use absolute paths. - -Typically, the successful exploration of these vulnerabilities has a very high impact since the attacker is able to access sensitive files from the application, either configuration files or source-code files. Depending on the vulnerability, the attacker may be able to read most files on the server. - +A path traversal vulnerability occurs when the application places user input in filesystem operations without proper care. The attacker explores this vulnerability, typically, with various sequences of dot-dot-slash (../) characters that change the file being read or written to one of his choice, possibly even outside of the root folder of the application. Other possibility is for the attacker to use absolute paths. + +Typically, the successful exploration of these vulnerabilities has a very high impact since the attacker is able to access sensitive files from the application, either configuration files or source-code files. Depending on the vulnerability, the attacker may be able to read most files on the server. + This attack is also frequently referred to as Directory Traversal. ## How to fix {% tabs path-traversal %} {% tab path-traversal generic %} -The most secure way of fixing a path traversal vulnerability is to prevent any user input from controlling which files are read by the application. This is only achievable if the application replaces the references to files being read with an indirect reference, such as index number than is then converted to a file name in the server. Something like `example.com?file=example.css` would become `example.com?file=1`. - -A simpler solution would be to ensure the files being read are all contained in a base directory and it is not possible to read files outside that directory. To ensure that you need two steps: -* canonicalize the file that you want to read, which means converting it to its absolute and simplest representation -* then, extract the filename from the canonicalized path and concatenate it with your base directory. - +The most secure way of fixing a path traversal vulnerability is to prevent any user input from controlling which files are read by the application. This is only achievable if the application replaces the references to files being read with an indirect reference, such as index number than is then converted to a file name in the server. Something like `example.com?file=example.css` would become `example.com?file=1`. + +A simpler solution would be to ensure the files being read are all contained in a base directory and it is not possible to read files outside that directory. To ensure that you need two steps: +* canonicalize the file that you want to read, which means converting it to its absolute and simplest representation +* then, extract the filename from the canonicalized path and concatenate it with your base directory. + All programming languages have functions that implement thise, such as `realpath()` and `basename()`. The resulting path will definitely point to a file within your base directory, thus limiting reading to the expected files. {% endtab %} diff --git a/php-code-injection.md b/php-code-injection.md index cae26b2..9d9b0ef 100644 --- a/php-code-injection.md +++ b/php-code-injection.md @@ -5,6 +5,7 @@ cvss-score: 9.8 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H cwe-id: CWE-94 cwe-name: Improper Control of Generation of Code ('Code Injection') +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.12, A.8.25 @@ -14,18 +15,18 @@ compliance: --- -A PHP code injection vulnerability allows the attacker to execute arbitrary PHP code into the application. In the worst-case scenario, the attacker will be able to fully administrate the server, which will enable him to extract sensitive data, modify the application contents or delete data. - +A PHP code injection vulnerability allows the attacker to execute arbitrary PHP code into the application. In the worst-case scenario, the attacker will be able to fully administrate the server, which will enable him to extract sensitive data, modify the application contents or delete data. + These attacks happen when user-supplied data (forms, cookies, HTTP headers, etc.) is passed into a function that interprets it as PHP code. This programming pattern is well known bad practice because it is hard to ensure the function inputs are free from malicious code. ## How to fix {% tabs php-code-injection %} {% tab php-code-injection generic %} -The best way to fix and prevent this vulnerability is to avoid functions that interpret the input as PHP code. The functions `eval` and `include` are the most commonly used for this purpose. - -If you use those functions and its input is dynamic, and it can contain user input in any way, replace them with deterministic code that does not pass the user input to those functions. - +The best way to fix and prevent this vulnerability is to avoid functions that interpret the input as PHP code. The functions `eval` and `include` are the most commonly used for this purpose. + +If you use those functions and its input is dynamic, and it can contain user input in any way, replace them with deterministic code that does not pass the user input to those functions. + It is strongly recommended not to rely on a list of accepted or rejected inputs, as those might be incomplete or have bypasses that can lead to code injection with a different payload. {% endtab %} diff --git a/private-ip-addresses-disclosed.md b/private-ip-addresses-disclosed.md index d5ce0aa..22b2b1a 100644 --- a/private-ip-addresses-disclosed.md +++ b/private-ip-addresses-disclosed.md @@ -5,6 +5,7 @@ cvss-score: 5.3 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N cwe-id: CWE-200 cwe-name: Exposure of Sensitive Information to an Unauthorized Actor +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(a)(1), 164.312(d) ISO 27001: A.5.33, A.8.4, A.8.9, A.8.12 diff --git a/python-code-injection.md b/python-code-injection.md index d098a3a..1dbc3f5 100644 --- a/python-code-injection.md +++ b/python-code-injection.md @@ -5,6 +5,7 @@ cvss-score: 9.8 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H cwe-id: CWE-94 cwe-name: Improper Control of Generation of Code ('Code Injection') +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.12, A.8.25 @@ -14,18 +15,18 @@ compliance: --- -A Python code injection vulnerability allows the attacker to execute arbitrary Python code into the application. In the worst-case scenario, the attacker will be able to fully administrate the server, which will enable him to extract sensitive data, modify the application contents or delete data. - +A Python code injection vulnerability allows the attacker to execute arbitrary Python code into the application. In the worst-case scenario, the attacker will be able to fully administrate the server, which will enable him to extract sensitive data, modify the application contents or delete data. + These attacks happen when user-supplied data (forms, cookies, HTTP headers, etc.) is passed into a function that interprets it as python code. This programming pattern is well known bad practice because it is hard to ensure the function inputs are free from malicious code. ## How to fix {% tabs python-code-injection %} {% tab python-code-injection generic %} -The best way to fix and prevent this vulnerability is to avoid functions that interpret the input as python code. The functions `eval`, `exec`, `execfile`, `input` and `compile` are the most commonly used for this purpose. - -If you use those functions and its input is dynamic, and it can contain user input in any way, replace them with deterministic code that does not pass the user input to those functions. - +The best way to fix and prevent this vulnerability is to avoid functions that interpret the input as python code. The functions `eval`, `exec`, `execfile`, `input` and `compile` are the most commonly used for this purpose. + +If you use those functions and its input is dynamic, and it can contain user input in any way, replace them with deterministic code that does not pass the user input to those functions. + It is strongly recommended not to rely on a list of accepted or rejected inputs, as those might be incomplete or have bypasses that can lead to code injection with a different payload. {% endtab %} diff --git a/reflected-cross-site-scripting.md b/reflected-cross-site-scripting.md index b3413fa..a82868b 100644 --- a/reflected-cross-site-scripting.md +++ b/reflected-cross-site-scripting.md @@ -6,6 +6,7 @@ cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N cwe-id: CWE-79 cwe-name: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.25 @@ -15,90 +16,90 @@ compliance: --- -A reflected cross-site scripting (XSS) vulnerability allows the attacker to temporarily inject malicious scripts in the application page. The typical attack is to send a link to the victim with some JavaScript in it, which will be executed in the victim's browser, inside the vulnerable page. This malicious JavaScript can, for instance, read the session cookie and send it to the attacker, change the login form and point it to a page controlled by the attacker (and thus stealing the credentials) or even add a non-existent form asking for sensitive data. - -Depending on the type of XSS and the nature of the vulnerable application, the impact of this vulnerability can range from temporarily modifying the contents of the website (during the victim's visit) to total control of the victim's session or even of the browser. Given its prevalence and ease of exploitation, it's often considered a serious risk for any application that contains an area that requires authentication. - +A reflected cross-site scripting (XSS) vulnerability allows the attacker to temporarily inject malicious scripts in the application page. The typical attack is to send a link to the victim with some JavaScript in it, which will be executed in the victim's browser, inside the vulnerable page. This malicious JavaScript can, for instance, read the session cookie and send it to the attacker, change the login form and point it to a page controlled by the attacker (and thus stealing the credentials) or even add a non-existent form asking for sensitive data. + +Depending on the type of XSS and the nature of the vulnerable application, the impact of this vulnerability can range from temporarily modifying the contents of the website (during the victim's visit) to total control of the victim's session or even of the browser. Given its prevalence and ease of exploitation, it's often considered a serious risk for any application that contains an area that requires authentication. + This type of vulnerability is quite widespread on the Internet and happens when the application takes user input and prints (outputs) it without properly encode or validate that input. The name _reflected_ comes from the malicious code that is sent to the server and reflected back to the victim's browser, in the source code of the page. ## How to fix {% tabs reflected-cross-site-scripting %} {% tab reflected-cross-site-scripting generic %} -The correct prevention method is to escape the user input data before including it in the response, however there are some rules you must follow to ensure proper escaping is applied. - -If you are using a template system to define the look and layout of your application, it is likely that it has support for auto-escaping data, without much hassle. Depending on the system, you either enable it globally when loading the template system or you have to enable it everything time you echo some code or variable in the page. - -Using a template system to generate your pages will probably save you some time and it easier to ensure that is XSS-free, since most of them auto-escape by design, such as the template system used in the Python framework Django. - -If you have to do it by hand you must be aware that there isn't one-size-fits-all solution: the way you escape the input depends on the context of the page where it is being placed. There are four contexts where it is common to place user input. These are: - -1. HTML body and HTML element attributes -1. JavaScript -1. CSS and style attributes -1. URI's - -#### HTML Body and Element Attributes Context - -This rule applies to data inserted into HTML body elements, such as `div`, `p`, `b`, `td`, etc. and also to simple attribute values like `width`, `name`, `value`, `id`, etc. It must not be used in attributes like `href`, `src`, `style`, or any event handler like `onmouseover`. - -You should use an HTML encoding function, available in the most common programming languages, to encode all characters that have a special meaning in HTML, such as `<` , `>`, `&` , `"` and `'` to their corresponding entities representation `<`, `>`, `&`, `"` and `'`. - -#### Javascript Context - -This rules applies to input placed directly inside JavaScript code - both script blocks and event-handler attributes, such as `onmouseover`. - -In this case you should escape any input by converting it to its unicode representation. For instance, `;` should become `\u003b`. If you don't have access to a function that does this conversion, you have the option to convert to the `\xHH` format, where `HH` its the character hex representation. - -#### CSS and Style tag Context - -To escape user data within CSS or within a style tag you should use the `\HHHHHH` format, where `HHHHHH` is hex representation of the character, padded with the necessary zeros. - -#### URL GET Parameters Context - -This context is for URL based attributes, such as `href` and `src`. Input within these should be passed through an URL encoding function. All languages have functions to perform such conversion, for instance, in Python you would use `urllib.urlencode`. - - -#### Alternative solution +The correct prevention method is to escape the user input data before including it in the response, however there are some rules you must follow to ensure proper escaping is applied. + +If you are using a template system to define the look and layout of your application, it is likely that it has support for auto-escaping data, without much hassle. Depending on the system, you either enable it globally when loading the template system or you have to enable it everything time you echo some code or variable in the page. + +Using a template system to generate your pages will probably save you some time and it easier to ensure that is XSS-free, since most of them auto-escape by design, such as the template system used in the Python framework Django. + +If you have to do it by hand you must be aware that there isn't one-size-fits-all solution: the way you escape the input depends on the context of the page where it is being placed. There are four contexts where it is common to place user input. These are: + +1. HTML body and HTML element attributes +1. JavaScript +1. CSS and style attributes +1. URI's + +#### HTML Body and Element Attributes Context + +This rule applies to data inserted into HTML body elements, such as `div`, `p`, `b`, `td`, etc. and also to simple attribute values like `width`, `name`, `value`, `id`, etc. It must not be used in attributes like `href`, `src`, `style`, or any event handler like `onmouseover`. + +You should use an HTML encoding function, available in the most common programming languages, to encode all characters that have a special meaning in HTML, such as `<` , `>`, `&` , `"` and `'` to their corresponding entities representation `<`, `>`, `&`, `"` and `'`. + +#### Javascript Context + +This rules applies to input placed directly inside JavaScript code - both script blocks and event-handler attributes, such as `onmouseover`. + +In this case you should escape any input by converting it to its unicode representation. For instance, `;` should become `\u003b`. If you don't have access to a function that does this conversion, you have the option to convert to the `\xHH` format, where `HH` its the character hex representation. + +#### CSS and Style tag Context + +To escape user data within CSS or within a style tag you should use the `\HHHHHH` format, where `HHHHHH` is hex representation of the character, padded with the necessary zeros. + +#### URL GET Parameters Context + +This context is for URL based attributes, such as `href` and `src`. Input within these should be passed through an URL encoding function. All languages have functions to perform such conversion, for instance, in Python you would use `urllib.urlencode`. + + +#### Alternative solution Additionally you could validate the input, _i.e._, implement whitelist of characters that you allow in each field and only accept those values at the server if they are in the whitelist. If you only allow alphanumeric characters you will be safe, but if you add others you may be at risk, so always implement escaping. Validating the input is just an extra-measure but you should not rely on it. {% endtab %} {% tab reflected-cross-site-scripting php %} -The correct prevention method is to escape the user input data before including it in the response, however there are some rules you must follow to ensure proper escaping is applied. - -If you are using a template system to define the look and layout of your application, it is likely that it has support for auto-escaping data, without much hassle. Depending on the system, you either enable it globally when loading the template system or you have to enable it everything time you echo some code or variable in the page. - -Using a template system to generate your pages will probably save you some time and it easier to ensure that is XSS-free, since most of them auto-escape by design, such as the template system used in the Python framework Django. - -If you have to do it by hand you must be aware that there isn't one-size-fits-all solution: the way you escape the input depends on the context of the page where it is being placed. There are four contexts where it is common to place user input. These are: - -1. HTML body and HTML element attributes -1. JavaScript -1. CSS and style attributes -1. URI's - -#### HTML Body and Element Attributes Context - -This rule applies to data inserted into HTML body elements, such as `div`, `p`, `b`, `td`, etc. and also to simple attribute values like `width`, `name`, `value`, `id`, etc. It must not be used in attributes like `href`, `src`, `style`, or any event handler like `onmouseover`. - -You should use `htmlspecialchars` in PHP, like this: - -``` -echo htmlspecialchars($string, ENT_QUOTES, 'UTF-8'); -``` - -#### Javascript Context - -This rules applies to input placed directly inside JavaScript code - both script blocks and event-handler attributes, such as `onmouseover`. - -In this case you should escape any input by converting it to its unicode representation. For instance, `;` should become `\u003b`. If you don't have access to a function that does this conversion, you have the option to convert to the `\xHH` format, where `HH` its the character hex representation. - -#### CSS and Style tag Context - -To escape user data within CSS or within a style tag you should use the `\HHHHHH` format, where `HHHHHH` is hex representation of the character, padded with the necessary zeros. - -#### URL GET Parameters Context - +The correct prevention method is to escape the user input data before including it in the response, however there are some rules you must follow to ensure proper escaping is applied. + +If you are using a template system to define the look and layout of your application, it is likely that it has support for auto-escaping data, without much hassle. Depending on the system, you either enable it globally when loading the template system or you have to enable it everything time you echo some code or variable in the page. + +Using a template system to generate your pages will probably save you some time and it easier to ensure that is XSS-free, since most of them auto-escape by design, such as the template system used in the Python framework Django. + +If you have to do it by hand you must be aware that there isn't one-size-fits-all solution: the way you escape the input depends on the context of the page where it is being placed. There are four contexts where it is common to place user input. These are: + +1. HTML body and HTML element attributes +1. JavaScript +1. CSS and style attributes +1. URI's + +#### HTML Body and Element Attributes Context + +This rule applies to data inserted into HTML body elements, such as `div`, `p`, `b`, `td`, etc. and also to simple attribute values like `width`, `name`, `value`, `id`, etc. It must not be used in attributes like `href`, `src`, `style`, or any event handler like `onmouseover`. + +You should use `htmlspecialchars` in PHP, like this: + +``` +echo htmlspecialchars($string, ENT_QUOTES, 'UTF-8'); +``` + +#### Javascript Context + +This rules applies to input placed directly inside JavaScript code - both script blocks and event-handler attributes, such as `onmouseover`. + +In this case you should escape any input by converting it to its unicode representation. For instance, `;` should become `\u003b`. If you don't have access to a function that does this conversion, you have the option to convert to the `\xHH` format, where `HH` its the character hex representation. + +#### CSS and Style tag Context + +To escape user data within CSS or within a style tag you should use the `\HHHHHH` format, where `HHHHHH` is hex representation of the character, padded with the necessary zeros. + +#### URL GET Parameters Context + This context is for URL based attributes, such as `href` and `src`. Input within these should be passed through an URL encoding function. All languages have functions to perform such conversion, for instance, in Python you would use `urllib.urlencode`. {% endtab %} diff --git a/remote-file-inclusion.md b/remote-file-inclusion.md index c8045d2..0c664bc 100644 --- a/remote-file-inclusion.md +++ b/remote-file-inclusion.md @@ -5,6 +5,7 @@ cvss-score: 7.5 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N cwe-id: CWE-98 cwe-name: Improper Control of Filename for Include/Require Statement in PHP Program +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.4, A.8.12, A.8.25 @@ -13,18 +14,18 @@ compliance: --- -A remote file inclusion (RFI) vulnerability exists when an attacker can force the web application to load remote content. Depending on how the remote content is included it may lead to remote code execution (RCE). If the attacker is able to execute code on the server, he is very likely to access arbitrary content and take full control of the server. - -RFI attacks usually occur when the application receives a path or URL as an input, uses that input to fetch some content, and then uses that same content to generate the response. +A remote file inclusion (RFI) vulnerability exists when an attacker can force the web application to load remote content. Depending on how the remote content is included it may lead to remote code execution (RCE). If the attacker is able to execute code on the server, he is very likely to access arbitrary content and take full control of the server. + +RFI attacks usually occur when the application receives a path or URL as an input, uses that input to fetch some content, and then uses that same content to generate the response. One example that can lead to RCE is when the fetched content is loaded by the PHP `include` function. Similarly, if the fetched content is placed inside a template string, it can lead to a server-side template injection. ## How to fix {% tabs remote-file-inclusion %} {% tab remote-file-inclusion generic %} -To fix an RFI vulnerability, ensure only trusted input is included in the application. Depending on how your application is built, you have various options (that can, and should, be combined): -- Do not pass user input to include functions -- Whitelist the domains or files that can be passed as input to the include function and ensure nothing else goes through +To fix an RFI vulnerability, ensure only trusted input is included in the application. Depending on how your application is built, you have various options (that can, and should, be combined): +- Do not pass user input to include functions +- Whitelist the domains or files that can be passed as input to the include function and ensure nothing else goes through - Validate the format of the input: if you don’t expect paths or URLs, reject inputs that have anything else other than alphanumeric characters. {% endtab %} diff --git a/ruby-code-injection.md b/ruby-code-injection.md index a062d2e..241d1aa 100644 --- a/ruby-code-injection.md +++ b/ruby-code-injection.md @@ -5,6 +5,7 @@ cvss-score: 9.8 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H cwe-id: CWE-94 cwe-name: Improper Control of Generation of Code ('Code Injection') +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.12, A.8.25 @@ -14,18 +15,18 @@ compliance: --- -A Ruby code injection vulnerability allows the attacker to execute arbitrary Ruby code into the application. In the worst-case scenario, the attacker will be able to fully administrate the server, which will enable him to extract sensitive data, modify the application contents or delete data. - +A Ruby code injection vulnerability allows the attacker to execute arbitrary Ruby code into the application. In the worst-case scenario, the attacker will be able to fully administrate the server, which will enable him to extract sensitive data, modify the application contents or delete data. + These attacks happen when user-supplied data (forms, cookies, HTTP headers, etc.) is passed into a function that interprets it as Ruby code. This programming pattern is well known bad practice because it is hard to ensure the function inputs are free from malicious code. ## How to fix {% tabs ruby-code-injection %} {% tab ruby-code-injection generic %} -The best way to fix and prevent this vulnerability is to avoid functions that interpret the input as Ruby code. The function `eval` is the most commonly used for this purpose. - -If you use `eval` and its input is dynamic, and it can contain user input in any way, replace it with deterministic code that does not pass the user input to that function. - +The best way to fix and prevent this vulnerability is to avoid functions that interpret the input as Ruby code. The function `eval` is the most commonly used for this purpose. + +If you use `eval` and its input is dynamic, and it can contain user input in any way, replace it with deterministic code that does not pass the user input to that function. + It is strongly recommended not to rely on a list of accepted or rejected inputs, as those might be incomplete or have bypasses that can lead to code injection with a different payload. {% endtab %} diff --git a/secure-tls-protocol-version-12-not-supported.md b/secure-tls-protocol-version-12-not-supported.md index 9886c3e..e8e20a0 100644 --- a/secure-tls-protocol-version-12-not-supported.md +++ b/secure-tls-protocol-version-12-not-supported.md @@ -5,6 +5,7 @@ cvss-score: 4.2 cvss-vector: CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N cwe-id: CWE-326 cwe-name: Inadequate Encryption Strength +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1) ISO 27001: A.5.14, A.8.9, A.8.24 @@ -14,99 +15,99 @@ compliance: --- -TLS protocol version 1.2 is not enabled on your server. We strongly recommend that TLS 1.2 is enabled, as it is both safer and faster than previous versions and protocols. - -One of the most important features of TLS 1.2 is that it supports AEAD ciphers (Authenticated Encryption with Associated Data). Some non-AEAD ciphers are vulnerable to a class of attacks called padding-oracles, which led to the publication of attacks such as Lucky Thirteen and POODLE, amongst others. Moreover, as of 2018, TLS 1.2 adoption is above 94%. -By supporting AEAD ciphers, TLS 1.2 is much more robust against padding-oracle attacks. - +TLS protocol version 1.2 is not enabled on your server. We strongly recommend that TLS 1.2 is enabled, as it is both safer and faster than previous versions and protocols. + +One of the most important features of TLS 1.2 is that it supports AEAD ciphers (Authenticated Encryption with Associated Data). Some non-AEAD ciphers are vulnerable to a class of attacks called padding-oracles, which led to the publication of attacks such as Lucky Thirteen and POODLE, amongst others. Moreover, as of 2018, TLS 1.2 adoption is above 94%. +By supporting AEAD ciphers, TLS 1.2 is much more robust against padding-oracle attacks. + Additionally, depending on CPU support, some AEAD ciphers are actually faster to execute than their older counterparts. ## How to fix {% tabs secure-tls-protocol-version-12-not-supported %} {% tab secure-tls-protocol-version-12-not-supported generic %} -To fix this issue, you need to enable TLS 1.2+ in your webserver configuration. - -The following guidelines should help you enable TLS 1.2+ with a strong cipher suite. - -For the Apache server configuration, use this snippet as a guideline: - - -``` - - ... - - SSLProtocol -all +TLSv1.2 +TLSv1.3 - SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 - SSLHonorCipherOrder on - SSLCompression off - - ... - -``` - - -For the Nginx server configuration, the following snippet may be used as a guideline: - - -``` -server { - listen 443 ssl; - - ... - - ssl_protocols TLSv1.2 TLSv1.3; - ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; - ssl_prefer_server_ciphers on; - - .... -} -``` - +To fix this issue, you need to enable TLS 1.2+ in your webserver configuration. + +The following guidelines should help you enable TLS 1.2+ with a strong cipher suite. + +For the Apache server configuration, use this snippet as a guideline: + + +``` + + ... + + SSLProtocol -all +TLSv1.2 +TLSv1.3 + SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 + SSLHonorCipherOrder on + SSLCompression off + + ... + +``` + + +For the Nginx server configuration, the following snippet may be used as a guideline: + + +``` +server { + listen 443 ssl; + + ... + + ssl_protocols TLSv1.2 TLSv1.3; + ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; + ssl_prefer_server_ciphers on; + + .... +} +``` + We have written an in-depth article with more details [here](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454). {% endtab %} {% tab secure-tls-protocol-version-12-not-supported nginx %} -To fix this issue, you need to enable TLS 1.2+ in your webserver configuration. - -The following guidelines should help you enabling TLS 1.2+ with a strong cipher suite. - -For the Nginx server configuration use this snippet as guideline: - -``` -server { - listen 443 ssl; - ... - ssl_protocols TLSv1.2 TLSv1.3; - ... -} -``` - +To fix this issue, you need to enable TLS 1.2+ in your webserver configuration. + +The following guidelines should help you enabling TLS 1.2+ with a strong cipher suite. + +For the Nginx server configuration use this snippet as guideline: + +``` +server { + listen 443 ssl; + ... + ssl_protocols TLSv1.2 TLSv1.3; + ... +} +``` + We have written an in-depth article about modern TLS deployments [here](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454). {% endtab %} {% tab secure-tls-protocol-version-12-not-supported apache %} -To fix this issue, you need to enable TLS 1.2+ in your webserver configuration. - -The following guidelines should help you enabling TLS 1.2+ with a strong cipher suite. - -For the Apache server configuration use this snippet as guideline: - - -``` - - ... - - SSLProtocol -all +TLSv1.2 +TLSv1.3 - SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 - SSLHonorCipherOrder on - SSLCompression off - - ... - - -``` - +To fix this issue, you need to enable TLS 1.2+ in your webserver configuration. + +The following guidelines should help you enabling TLS 1.2+ with a strong cipher suite. + +For the Apache server configuration use this snippet as guideline: + + +``` + + ... + + SSLProtocol -all +TLSv1.2 +TLSv1.3 + SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 + SSLHonorCipherOrder on + SSLCompression off + + ... + + +``` + We have written a in-depth article about modern TLS deployments [here](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454). {% endtab %} diff --git a/server-side-javascript-injection.md b/server-side-javascript-injection.md index 6a46125..2d937d0 100644 --- a/server-side-javascript-injection.md +++ b/server-side-javascript-injection.md @@ -5,6 +5,7 @@ cvss-score: 9.8 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H cwe-id: CWE-94 cwe-name: Improper Control of Generation of Code ('Code Injection') +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.12, A.8.25 @@ -14,19 +15,19 @@ compliance: --- -A Server-side JavaScript injection vulnerability allows the attacker to run arbitrary JavaScript code on the server. Web Applications that pass user input to functions like `eval()`, `setTimeout()` and `setInterval()` are potentially vulnerable. - +A Server-side JavaScript injection vulnerability allows the attacker to run arbitrary JavaScript code on the server. Web Applications that pass user input to functions like `eval()`, `setTimeout()` and `setInterval()` are potentially vulnerable. + The impact of this vulnerability ranges from an effective denial-of-service attack to File System access on the server. ## How to fix {% tabs server-side-javascript-injection %} {% tab server-side-javascript-injection generic %} -To prevent a Server-side JavaScript injection vulnerability, you should validate all user input on the server-side before processing. - -You should also consider the following: -* Do not use the `eval()` function to parse user inputs. -* If you need to parse JSON input, use a safer alternative such as `JSON.parse()`. +To prevent a Server-side JavaScript injection vulnerability, you should validate all user input on the server-side before processing. + +You should also consider the following: +* Do not use the `eval()` function to parse user inputs. +* If you need to parse JSON input, use a safer alternative such as `JSON.parse()`. * Include ```"use strict";``` at the beginning of a function. {% endtab %} diff --git a/server-side-request-forgery.md b/server-side-request-forgery.md index 618cf76..09a46f9 100644 --- a/server-side-request-forgery.md +++ b/server-side-request-forgery.md @@ -5,6 +5,7 @@ cvss-score: 4.8 cvss-vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L cwe-id: CWE-918 cwe-name: Server-Side Request Forgery (SSRF) +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.4, A.8.12, A.8.25 diff --git a/spring-cloud-spel-code-injection-cve-2022-22963.md b/spring-cloud-spel-code-injection-cve-2022-22963.md index 5e0f511..24e7545 100644 --- a/spring-cloud-spel-code-injection-cve-2022-22963.md +++ b/spring-cloud-spel-code-injection-cve-2022-22963.md @@ -5,6 +5,7 @@ cvss-score: 9.0 cvss-vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H cwe-id: CWE-94 cwe-name: Improper Control of Generation of Code ('Code Injection') +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.9, A.8.12 @@ -12,8 +13,8 @@ compliance: --- -A remote code execution vulnerability (RCE) allows the attacker to execute arbitrary code and operating system commands on the server. In the worst-case scenario, the attacker will be able to fully compromise the server, extract sensitive data, modify the application contents or delete data. - +A remote code execution vulnerability (RCE) allows the attacker to execute arbitrary code and operating system commands on the server. In the worst-case scenario, the attacker will be able to fully compromise the server, extract sensitive data, modify the application contents or delete data. + The Spring Cloud versions 3.1.6 and 3.2.2, or below, if using the routing functionality, are vulnerable to RCE, identified as CVE-2022-22963. The vulnerability can be exploited with a specially crafted SpEL (short for Spring Expression Language) that results in remote code execution and access to local resources. ## How to fix diff --git a/sql-injection.md b/sql-injection.md index e126d0a..0b6f458 100644 --- a/sql-injection.md +++ b/sql-injection.md @@ -5,6 +5,7 @@ cvss-score: 9.3 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N cwe-id: CWE-89 cwe-name: SQL Injection +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.5.33, A.5.34, A.8.3, A.8.12, A.8.25 diff --git a/ssl-cookie-without-secure-flag.md b/ssl-cookie-without-secure-flag.md index 1d9acee..ec391e1 100644 --- a/ssl-cookie-without-secure-flag.md +++ b/ssl-cookie-without-secure-flag.md @@ -5,6 +5,7 @@ cvss-score: 5.3 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N cwe-id: CWE-614 cwe-name: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.25 @@ -14,18 +15,18 @@ compliance: --- -The cookie secure flag is intended to prevent browsers from submitting the cookie in any HTTP requests that use an unencrypted connection, thus an attacker that is eavesdropping the connection will not be able to get that cookie. - -A flag without the secure flag set will always be sent on every HTTP request that matches the scope of cookie, i.e. the domain for which it is set. What this means is that if your application inadvertently makes an HTTP request (without encryption), this request will carry the cookie and any attacker that can eavesdrop the victim traffic will be able to read that cookie. - +The cookie secure flag is intended to prevent browsers from submitting the cookie in any HTTP requests that use an unencrypted connection, thus an attacker that is eavesdropping the connection will not be able to get that cookie. + +A flag without the secure flag set will always be sent on every HTTP request that matches the scope of cookie, i.e. the domain for which it is set. What this means is that if your application inadvertently makes an HTTP request (without encryption), this request will carry the cookie and any attacker that can eavesdrop the victim traffic will be able to read that cookie. + If the cookie in question is the session cookie, the attacker will be able to hijack the victim account. ## How to fix {% tabs ssl-cookie-without-secure-flag %} {% tab ssl-cookie-without-secure-flag generic %} -To fix a vulnerability of this type, you just need to set the Secure flag on the vulnerable cookie, effectively preventing it from being transmitted in unencrypted connections, i.e. over HTTP. - +To fix a vulnerability of this type, you just need to set the Secure flag on the vulnerable cookie, effectively preventing it from being transmitted in unencrypted connections, i.e. over HTTP. + Depending on the language and technologies you are using, setting the Secure flag could mean to enable it or setting it to true, either on the code of the application itself or in a configuration file of the webserver or Content Management System (CMS) you are using. {% endtab %} diff --git a/stored-cross-site-scripting.md b/stored-cross-site-scripting.md index 57cc1cb..6dc9f44 100644 --- a/stored-cross-site-scripting.md +++ b/stored-cross-site-scripting.md @@ -6,6 +6,7 @@ cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N cwe-id: CWE-79 cwe-name: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.25 diff --git a/tls-downgrade-attack-prevention-not-supported.md b/tls-downgrade-attack-prevention-not-supported.md index 98ac198..0b664e4 100644 --- a/tls-downgrade-attack-prevention-not-supported.md +++ b/tls-downgrade-attack-prevention-not-supported.md @@ -5,6 +5,7 @@ cvss-score: 4.2 cvss-vector: CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N cwe-id: CWE-757 cwe-name: Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade') +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1) ISO 27001: A.5.14, A.8.9, A.8.24 @@ -14,12 +15,12 @@ compliance: --- -The server does not prevent SSL/TLS protocol downgrade attacks, which may cause insecure connections to be established, despite being made over SSL/TLS. An attacker that can interfere with the connection can force the client to negotiate a weaker protocol and cipher suite with the server, and then take advantage of that cipher suite weakness to read or modify client-server connections. - -For instance, even though a client may support the secure TLS 1.2 protocol, the attacker may force it to connect to the server using SSL 3.0, which is insecure, possibly allowing the attacker to decrypt and extract session cookies and other secrets. - -TLS_FALLBACK_SCSV is sent by the client to inform the server that the connection is being retried with a lower version protocol. If the server sees TLS_FALLBACK_SCSV and it supports a higher protocol than the one advertised by the client, it will know there is no good reason for the client to be trying a lower protocol, and will prevent the connection, thus mitigating the attack. - +The server does not prevent SSL/TLS protocol downgrade attacks, which may cause insecure connections to be established, despite being made over SSL/TLS. An attacker that can interfere with the connection can force the client to negotiate a weaker protocol and cipher suite with the server, and then take advantage of that cipher suite weakness to read or modify client-server connections. + +For instance, even though a client may support the secure TLS 1.2 protocol, the attacker may force it to connect to the server using SSL 3.0, which is insecure, possibly allowing the attacker to decrypt and extract session cookies and other secrets. + +TLS_FALLBACK_SCSV is sent by the client to inform the server that the connection is being retried with a lower version protocol. If the server sees TLS_FALLBACK_SCSV and it supports a higher protocol than the one advertised by the client, it will know there is no good reason for the client to be trying a lower protocol, and will prevent the connection, thus mitigating the attack. + For this attack to succeed, the attacker must be able to tamper with the connection between the client and the server, which is fairly easy if both the attacker and the client are in the same network, this is more likely if the client is using a wireless connection. ## How to fix diff --git a/unencrypted-communications.md b/unencrypted-communications.md index a5aaf14..268cb70 100644 --- a/unencrypted-communications.md +++ b/unencrypted-communications.md @@ -5,6 +5,7 @@ cvss-score: 5.9 cvss-vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N cwe-id: CWE-319 cwe-name: Cleartext Transmission of Sensitive Information +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1) ISO 27001: A.5.14, A.8.9, A.8.24 @@ -14,18 +15,18 @@ compliance: --- -The application allows clients to connect to it through an unencrypted connection, meaning that an attacker that is strategically positioned between the victim's and the applications's traffic is able to eavesdrop all communications between them, accessing any information that is being transmitted, such as the victim's credentials. In addition, the attacker can modify the communications to deliver more powerful attacks, for instance, to ask the victim for more sensitive information that hasn't been asked in the original application page. - -Such attacks are more likely to occur when the victim is using an insecure Wi-Fi connection, a typical scenario in the public Wi-Fi services. - +The application allows clients to connect to it through an unencrypted connection, meaning that an attacker that is strategically positioned between the victim's and the applications's traffic is able to eavesdrop all communications between them, accessing any information that is being transmitted, such as the victim's credentials. In addition, the attacker can modify the communications to deliver more powerful attacks, for instance, to ask the victim for more sensitive information that hasn't been asked in the original application page. + +Such attacks are more likely to occur when the victim is using an insecure Wi-Fi connection, a typical scenario in the public Wi-Fi services. + Unencrypted connections may also trigger browser warnings about the insecurity of the connection, following the trend of raising awareness about privacy. ## How to fix {% tabs unencrypted-communications %} {% tab unencrypted-communications generic %} -The application should be configured to use encryption in all communications. This normally means to configure the web server to use TLS with a suitable choice of ciphers, forcing all incoming requests in plaintext (without encryption) to be redirected to TLS endpoint of the application. - +The application should be configured to use encryption in all communications. This normally means to configure the web server to use TLS with a suitable choice of ciphers, forcing all incoming requests in plaintext (without encryption) to be redirected to TLS endpoint of the application. + In HTTP this is achieved with a 301 Moved Permanently directive. It can be complemented with an HTTP Strict Transport Security header (HSTS) to force the browsers to make all requests in HTTPS even if the end user forgets to write HTTPS in the request. {% endtab %} diff --git a/untrusted-tls-certificate.md b/untrusted-tls-certificate.md index c054a45..ea28fdd 100644 --- a/untrusted-tls-certificate.md +++ b/untrusted-tls-certificate.md @@ -5,6 +5,7 @@ cvss-score: 5.3 cvss-vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N cwe-id: CWE-16 cwe-name: Configuration +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1) ISO 27001: A.5.14, A.8.9, A.8.24 @@ -14,13 +15,13 @@ compliance: --- -The certificate sent by the server is not trusted. - -This may be due to one of the following reasons: - * The requested hostname does not match the CN or SAN attribute of the TLS Certificate; - * The issuer of this certificate is not trusted. This can happen if the certificate is self-signed, or the certificate issuer is not a recognized Certificate Authority; - * The server did not send the complete certificate chain. This usually means that the server did not send a required intermediate CA certificate. - +The certificate sent by the server is not trusted. + +This may be due to one of the following reasons: + * The requested hostname does not match the CN or SAN attribute of the TLS Certificate; + * The issuer of this certificate is not trusted. This can happen if the certificate is self-signed, or the certificate issuer is not a recognized Certificate Authority; + * The server did not send the complete certificate chain. This usually means that the server did not send a required intermediate CA certificate. + If this problem is intermittent, it might be because your site is behind a load balancer, and one of the servers is misconfigured or is sending an incorrect certificate. ## How to fix diff --git a/using-jwk-parameter-to-verify-jwts.md b/using-jwk-parameter-to-verify-jwts.md index 7b05c38..6c03ee3 100644 --- a/using-jwk-parameter-to-verify-jwts.md +++ b/using-jwk-parameter-to-verify-jwts.md @@ -5,6 +5,7 @@ cvss-score: 7.5 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N cwe-id: CWE-345 cwe-name: Insufficient Verification of Data Authenticity +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1) ISO 27001: A.8.2, A.8.3, A.8.5, A.8.24, A.8.25 diff --git a/weak-cipher-suites-enabled.md b/weak-cipher-suites-enabled.md index 0d0da00..e3b199c 100644 --- a/weak-cipher-suites-enabled.md +++ b/weak-cipher-suites-enabled.md @@ -5,6 +5,7 @@ cvss-score: 4.2 cvss-vector: CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N cwe-id: CWE-326 cwe-name: Inadequate Encryption Strength +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1) ISO 27001: A.5.14, A.8.9, A.8.24 @@ -14,76 +15,76 @@ compliance: --- -The server supports weak cipher suites for SSL/TLS connections. These cipher suites are currently considered broken and, depending on the specific cipher suite, offer poor or no security at all. Thus defeating the purpose of using a secure communication channel in the first place. - -Any connection to the server using a weak cipher suite is at risk of being eavesdropped and tampered with by an attacker that can intercept connections. This is more likely to occur to Wi-Fi clients. - +The server supports weak cipher suites for SSL/TLS connections. These cipher suites are currently considered broken and, depending on the specific cipher suite, offer poor or no security at all. Thus defeating the purpose of using a secure communication channel in the first place. + +Any connection to the server using a weak cipher suite is at risk of being eavesdropped and tampered with by an attacker that can intercept connections. This is more likely to occur to Wi-Fi clients. + Depending on the cipher suites used, a connection may be at an immediate risk of being intercepted. ## How to fix {% tabs weak-cipher-suites-enabled %} {% tab weak-cipher-suites-enabled generic %} -To stop using weak cipher suites, you must configure your web server cipher suite list accordingly. - -Ideally, as a general guideline, you should remove any cipher suite containing references to NULL, anonymous, export, DES, 3DES, RC4, and MD5 algorithms. Additionally, remove any cipher suite containing ciphers with less than 128 bit security. You should also remove any CBC ciphers, as CBC ciphers may be vulnerable to padding oracle attacks. - -You should enable ECDHE and GCM cipher suites to ensure proper security. Please note that these modern ciphers are available in newer versions of TLS only. You will need to enable TLSv1.2 and above (for GCM cipher suites). - -To achieve this, we propose a modern cipher suite, based on these [recommendations](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454): - -`TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256` - +To stop using weak cipher suites, you must configure your web server cipher suite list accordingly. + +Ideally, as a general guideline, you should remove any cipher suite containing references to NULL, anonymous, export, DES, 3DES, RC4, and MD5 algorithms. Additionally, remove any cipher suite containing ciphers with less than 128 bit security. You should also remove any CBC ciphers, as CBC ciphers may be vulnerable to padding oracle attacks. + +You should enable ECDHE and GCM cipher suites to ensure proper security. Please note that these modern ciphers are available in newer versions of TLS only. You will need to enable TLSv1.2 and above (for GCM cipher suites). + +To achieve this, we propose a modern cipher suite, based on these [recommendations](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454): + +`TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256` + For most systems, changing TLS cipher suites, requires a change on the web server configuration file. Please refer to your web server documentation on how to do so. {% endtab %} {% tab weak-cipher-suites-enabled nginx %} -To stop using weak cipher suites, you must configure your web server cipher suite list accordingly. - -Ideally, as a general guideline, you should remove any cipher suite containing references to NULL, anonymous, export, DES, 3DES, RC4, and MD5 algorithms. Additionally, remove any cipher suite containing ciphers with less than 128 bit security. You should also remove any CBC ciphers, as CBC ciphers may be vulnerable to padding oracle attacks. - -You should enable ECDHE and GCM cipher suites to ensure proper security. Please note that these modern ciphers are available in newer versions of TLS only. You will need to enable TLSv1.2 and above (for GCM cipher suites). - -To achieve this, we propose a modern cipher suite, based on these [recommendations](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454): - -`TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256` - -For NGINX, you can use the following snippet to enable the modern compatibility cipher suite. This will support TLS 1.2 and above only. - -``` -server { - listen 443 ssl; - ... - ssl_protocols TLSv1.2 TLSv1.3; - ssl_ciphers 'TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; - ... -} +To stop using weak cipher suites, you must configure your web server cipher suite list accordingly. + +Ideally, as a general guideline, you should remove any cipher suite containing references to NULL, anonymous, export, DES, 3DES, RC4, and MD5 algorithms. Additionally, remove any cipher suite containing ciphers with less than 128 bit security. You should also remove any CBC ciphers, as CBC ciphers may be vulnerable to padding oracle attacks. + +You should enable ECDHE and GCM cipher suites to ensure proper security. Please note that these modern ciphers are available in newer versions of TLS only. You will need to enable TLSv1.2 and above (for GCM cipher suites). + +To achieve this, we propose a modern cipher suite, based on these [recommendations](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454): + +`TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256` + +For NGINX, you can use the following snippet to enable the modern compatibility cipher suite. This will support TLS 1.2 and above only. + +``` +server { + listen 443 ssl; + ... + ssl_protocols TLSv1.2 TLSv1.3; + ssl_ciphers 'TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; + ... +} ``` {% endtab %} {% tab weak-cipher-suites-enabled apache %} -To stop using weak cipher suites, you must configure your web server cipher suite list accordingly. - -Ideally, as a general guideline, you should remove any cipher suite containing references to NULL, anonymous, export, DES, 3DES, RC4, and MD5 algorithms. Additionally, remove any cipher suite containing ciphers with less than 128 bit security. You should also remove any CBC ciphers, as CBC ciphers may be vulnerable to padding oracle attacks. - -You should enable ECDHE and GCM cipher suites to ensure proper security. Please note that these modern ciphers are available in newer versions of TLS only. You will need to enable TLSv1.2 and above (for GCM cipher suites). - -To achieve this, we propose a modern cipher suite, based on these [recommendations](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454): - -`TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256` - -For the Apache server, the following snippet may be used to enable TLS 1.2+ and strong ciphers. - -``` - - ... - SSLEngine on - SSLProtocol -all +TLS1.2 +TLS1.3 - SSLCipherSuite TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 - SSLHonorCipherOrder on - SSLCompression off - ... - +To stop using weak cipher suites, you must configure your web server cipher suite list accordingly. + +Ideally, as a general guideline, you should remove any cipher suite containing references to NULL, anonymous, export, DES, 3DES, RC4, and MD5 algorithms. Additionally, remove any cipher suite containing ciphers with less than 128 bit security. You should also remove any CBC ciphers, as CBC ciphers may be vulnerable to padding oracle attacks. + +You should enable ECDHE and GCM cipher suites to ensure proper security. Please note that these modern ciphers are available in newer versions of TLS only. You will need to enable TLSv1.2 and above (for GCM cipher suites). + +To achieve this, we propose a modern cipher suite, based on these [recommendations](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454): + +`TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256` + +For the Apache server, the following snippet may be used to enable TLS 1.2+ and strong ciphers. + +``` + + ... + SSLEngine on + SSLProtocol -all +TLS1.2 +TLS1.3 + SSLCipherSuite TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 + SSLHonorCipherOrder on + SSLCompression off + ... + ``` {% endtab %} diff --git a/weak-jwt-hmac-secret.md b/weak-jwt-hmac-secret.md index ef66cb0..38c6fec 100644 --- a/weak-jwt-hmac-secret.md +++ b/weak-jwt-hmac-secret.md @@ -5,6 +5,7 @@ cvss-score: 7.5 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N cwe-id: CWE-345 cwe-name: Insufficient Verification of Data Authenticity +correlatable: SAST compliance: HIPAA: 164.306(a), 164.312(c)(1) ISO 27001: A.8.2, A.8.3, A.8.5, A.8.24, A.8.25 diff --git a/xml-external-entity-injection.md b/xml-external-entity-injection.md index 27fca88..1319ec6 100644 --- a/xml-external-entity-injection.md +++ b/xml-external-entity-injection.md @@ -5,6 +5,7 @@ cvss-score: 7.5 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N cwe-id: CWE-611 cwe-name: Improper Restriction of XML External Entity Reference +correlatable: SAST compliance: HIPAA: 164.306(a) ISO 27001: A.8.9, A.8.25