diff --git a/application-security/policy-reference/book.yml b/application-security/policy-reference/book.yml index 871605cdc..1cb95d0e2 100644 --- a/application-security/policy-reference/book.yml +++ b/application-security/policy-reference/book.yml @@ -2530,3 +2530,379 @@ topics: file: cp-direct-poison-pipeline-exe-outside-collab.adoc - name: Public and private repositories connected to shared CI system file: cp-pub-private-repo-connect-share-ci-system.adoc +kind: chapter +name: SAST Policies +dir: /Users/taysmith/Documents/GitHub/tsmithv11/prisma-cloud-docs/application-security/policy-reference/sast-policies +topics: +- name: SAST Policies + file: sast-policies.adoc +- name: Java policies + dir: java-policies + topics: + - name: SAST Java Policy Index + file: sast-java-policy-index.adoc + - name: Improper neutralization of input during web page generation ('Cross-site + Scripting') + file: sast-policy-1.adoc + - name: Cleartext Transmission of Sensitive Information + file: sast-policy-102.adoc + - name: Collapse of data into unsafe value + file: sast-policy-103.adoc + - name: Cross-Site Request Forgery (CSRF) + file: sast-policy-104.adoc + - name: Deserialization of untrusted data + file: sast-policy-105.adoc + - name: Deserialization of Untrusted Data + file: sast-policy-106.adoc + - name: External Control of System or Configuration Setting + file: sast-policy-107.adoc + - name: External control of system or configuration setting + file: sast-policy-108.adoc + - name: Improper authentication + file: sast-policy-109.adoc + - name: Improper certificate validation + file: sast-policy-110.adoc + - name: Improper certificate validation + file: sast-policy-111.adoc + - name: Improper control of generation of code ('Code Injection') + file: sast-policy-112.adoc + - name: Improper control of generation of code ('Code Injection') + file: sast-policy-113.adoc + - name: Improper Handling of Unicode Encoding + file: sast-policy-114.adoc + - name: Improper Input Validation + file: sast-policy-115.adoc + - name: Improper Input Validation + file: sast-policy-116.adoc + - name: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') + file: sast-policy-117.adoc + - name: Improper neutralization of CRLF sequences ('CRLF Injection') + file: sast-policy-118.adoc + - name: Improper neutralization of data within XPath expressions ('XPath Injection') + file: sast-policy-119.adoc + - name: Integrity of the data during transmission is not being verified + file: sast-policy-12.adoc + - name: Improper neutralization of CRLF sequences ('CRLF Injection') + file: sast-policy-120.adoc + - name: Improper neutralization of special elements used in a command + file: sast-policy-121.adoc + - name: Improper neutralization of special elements used in an expression language + statement ('Expression Language Injection') + file: sast-policy-122.adoc + - name: Improper neutralization of special elements used in an OS command ('OS Command + Injection') + file: sast-policy-123.adoc + - name: Improper Neutralization of Special Elements used in an SQL Command ('SQL + Injection') + file: sast-policy-124.adoc + - name: Utilizing a class that isn't primitive in Java RMI could lead to a vulnerability + associated with insecure deserialization. + file: sast-policy-125.adoc + - name: Improper privilege management + file: sast-policy-126.adoc + - name: Improper restriction of XML external entity reference ('XXE') + file: sast-policy-127.adoc + - name: Improper restriction of XML external entity reference ('XXE') + file: sast-policy-128.adoc + - name: Improper validation of certificate with host mismatch + file: sast-policy-129.adoc + - name: Unsafe custom MessageDigest is implemented + file: sast-policy-13.adoc + - name: Inadequate encryption strength + file: sast-policy-130.adoc + - name: Inadequate encryption strength + file: sast-policy-131.adoc + - name: Inadequate encryption strength + file: sast-policy-132.adoc + - name: 'Incorrect behavior order: validate before canonicalize' + file: sast-policy-133.adoc + - name: Incorrect permission assignment for critical resource + file: sast-policy-134.adoc + - name: Incorrect Permission Assignment for Critical Resource + file: sast-policy-135.adoc + - name: Incorrect type conversion or cast + file: sast-policy-136.adoc + - name: Information exposure through an error message + file: sast-policy-137.adoc + - name: Information exposure through an error message + file: sast-policy-138.adoc + - name: Missing authentication for critical function (database) + file: sast-policy-139.adoc + - name: Unsafe use of Cross-Origin Resource Sharing (CORS) + file: sast-policy-14.adoc + - name: Missing authentication for critical function (LDAP) + file: sast-policy-140.adoc + - name: Permissive Cross-domain Policy with Untrusted Domains + file: sast-policy-141.adoc + - name: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute + file: sast-policy-142.adoc + - name: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute + file: sast-policy-143.adoc + - name: Sensitive cookie without 'HttpOnly' flag + file: sast-policy-144.adoc + - name: Server-Side Request Forgery (SSRF) + file: sast-policy-145.adoc + - name: URL Redirection to Untrusted Site ('Open Redirect') + file: sast-policy-147.adoc + - name: Use of a broken or risky cryptographic algorithm + file: sast-policy-148.adoc + - name: Use of a broken or risky cryptographic algorithm (SHA1/MD5) + file: sast-policy-149.adoc + - name: Unsafe use of hazelcast symmetric encryption + file: sast-policy-15.adoc + - name: Use of externally-controlled format string + file: sast-policy-150.adoc + - name: Unencrypted payload with JWT + file: sast-policy-151.adoc + - name: Use of insufficiently random values + file: sast-policy-155.adoc + - name: Use of RSA algorithm without OAEP + file: sast-policy-156.adoc + - name: Cookie created without HttpOnly flag + file: sast-policy-16.adoc + - name: Permissive cross-domain policy with untrusted domains + file: sast-policy-162.adoc + - name: Improper neutralization of special elements in output used by a downstream + component ('Injection') + file: sast-policy-163.adoc + - name: Improper Neutralization of Input During Web Page Generation ('Cross-site + Scripting') + file: sast-policy-164.adoc + - name: Improper Neutralization of Special Elements in Data Query Logic + file: sast-policy-165.adoc + - name: Unsafe DES algorithm used + file: sast-policy-17.adoc + - name: Expression injection (OGNL) + file: sast-policy-171.adoc + - name: Improper neutralization of special elements used in an LDAP query ('LDAP + Injection') + file: sast-policy-172.adoc + - name: Encryption keys with less than 128 bits + file: sast-policy-18.adoc + - name: Cookie created without Secure flag set + file: sast-policy-19.adoc + - name: Cookie stored for an extended period of time + file: sast-policy-20.adoc + - name: Cookie contains sensitive session info + file: sast-policy-21.adoc + - name: Trust Boundary is Violated + file: sast-policy-22.adoc + - name: Security of REST web service is not analyzed + file: sast-policy-23.adoc + - name: File Creation in Publicly Shared Directories + file: sast-policy-24.adoc + - name: CSRF is Disabled + file: sast-policy-25.adoc + - name: Authorization is not robust + file: sast-policy-26.adoc + - name: Pathname input not restricted + file: sast-policy-43.adoc + - name: File path not validated in file uploads + file: sast-policy-44.adoc + - name: Pathname not restricted in HTTP requests + file: sast-policy-45.adoc + - name: File path not validated for file writes + file: sast-policy-46.adoc + - name: Missing validation for paths when processing style sheets + file: sast-policy-47.adoc + - name: Unrestricted directory for pathname construction from HTTP requests + file: sast-policy-48.adoc + - name: Unrestricted pathnames from HTTP requests + file: sast-policy-49.adoc + - name: Improper neutralization of argument delimiters in a command ('Argument Injection') + file: sast-policy-7.adoc + - name: Files or directories accessible to external parties + file: sast-policy-8.adoc + - name: Improper neutralization of CRLF sequences in HTTP headers ('HTTP Response + Splitting') + file: sast-policy-9.adoc +- name: Javascript policies + dir: javascript-policies + topics: + - name: SAST JavaScript Policy Index + file: sast-javascript-policy-index.adoc + - name: Insecure SSL Server Identity Verification Disabled + file: sast-policy-101.adoc + - name: Ensure Usage of JWT Algo + file: sast-policy-146.adoc + - name: Sensitive Data Logging + file: sast-policy-153.adoc + - name: Cross-Site Request Forgery (CSRF) + file: sast-policy-157.adoc + - name: Improper restriction of operations within the bounds of a memory buffer + file: sast-policy-158.adoc + - name: Incorrect regular expression + file: sast-policy-159.adoc + - name: Information Exposure Through an Error Message + file: sast-policy-160.adoc + - name: Observable timing discrepancy + file: sast-policy-161.adoc + - name: Escape markup is removed leading to risk for XSS + file: sast-policy-27.adoc + - name: CSRF is not used before `methodOverride` + file: sast-policy-28.adoc + - name: Calls to fs functions that take a non Literal value as the filename parameter + file: sast-policy-29.adoc + - name: Bracket object notation with user input + file: sast-policy-30.adoc + - name: Insecure use of crypto.pseudoRandomBytes + file: sast-policy-31.adoc + - name: Creating temp tile done with insecure permissions + file: sast-policy-32.adoc + - name: Encryption Keys are less than 16 bytes + file: sast-policy-33.adoc + - name: Hash used without salt + file: sast-policy-34.adoc + - name: Use of RSA Algorithm without Optimal Asymmetric Encryption Padding (OAEP) + file: sast-policy-35.adoc + - name: Superuser port is set + file: sast-policy-36.adoc + - name: Insecure use of weak hashing algorithms + file: sast-policy-38.adoc + - name: Use of insecure HTTP connections + file: sast-policy-39.adoc + - name: Use of insecure HTTP Connections with Axios + file: sast-policy-40.adoc + - name: Insecure use of `eval` with non-string parameters + file: sast-policy-41.adoc + - name: Insecure use of `new Buffer()` + file: sast-policy-42.adoc + - name: Insecure communication using postMessage and event listeners + file: sast-policy-74.adoc + - name: Encryption algorithm not using secure modes and padding + file: sast-policy-75.adoc + - name: Risk of Regular Expression Denial of Service (ReDoS) + file: sast-policy-76.adoc + - name: Weak SSL/TLS protocols + file: sast-policy-77.adoc + - name: Restrict Unnecessary Powerful Browser Features + file: sast-policy-78.adoc + - name: Prevent Public Network Access to Cloud Resources + file: sast-policy-79.adoc + - name: Enforce HTTPS Access for S3 Buckets + file: sast-policy-80.adoc + - name: Prevent OS Command Argument Injections + file: sast-policy-81.adoc + - name: Complex/formatted SQL query + file: sast-policy-83.adoc + - name: AngularJS misconfiguration dangerous protocol allowed + file: sast-policy-84.adoc + - name: AngularJS Misconfiguration Strict Contextual Escaping Disabled + file: sast-policy-85.adoc + - name: Detection of XSS vulnerability + file: sast-policy-92.adoc + - name: Cookie Security Overly Permissive Samesite Attribute + file: sast-policy-95.adoc +- name: Python policies + dir: python-policies + topics: + - name: Encryption keys below 2048 bit + file: sast-policy-10.adoc + - name: Improper Check or Handling of Exceptional Conditions + file: sast-policy-100.adoc + - name: Use of module setting superuser port + file: sast-policy-11.adoc + - name: Hardcoded passwords are being used + file: sast-policy-152.adoc + - name: Unsanitized path input from an HTTP parameter is being opened + file: sast-policy-154.adoc + - name: Improper Check or Handling of Exceptional Conditions + file: sast-policy-166.adoc + - name: Use of Insufficiently Random Values + file: sast-policy-167.adoc + - name: Improper Control of Generation of Code ('Code Injection') + file: sast-policy-168.adoc + - name: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') + file: sast-policy-169.adoc + - name: Improper Neutralization of Wildcards or Matching Symbols + file: sast-policy-170.adoc + - name: Unsafe use of 'exec' command + file: sast-policy-2.adoc + - name: chmod sets a permissive mask on file + file: sast-policy-3.adoc + - name: Use of insecure IPMI-related modules + file: sast-policy-37.adoc + - name: Improper handling of checking for unusual or exceptional conditions + file: sast-policy-4.adoc + - name: Unsanitized input from data from a remote resource flows into os.system + file: sast-policy-48.adoc + - name: Publicly exposed servers + file: sast-policy-5.adoc + - name: XML Parsers exposed to XXE Vulnerabilities + file: sast-policy-50.adoc + - name: Request exposed to SQL injection + file: sast-policy-51.adoc + - name: User input not protected against NoSQL injection + file: sast-policy-52.adoc + - name: Not using HttpOnly flag when setting cookies + file: sast-policy-53.adoc + - name: JWTs are not properly verified before decoding + file: sast-policy-54.adoc + - name: Weak cryptographic algorithm used + file: sast-policy-55.adoc + - name: CSRF protections disabled + file: sast-policy-56.adoc + - name: Improper logger configuration + file: sast-policy-57.adoc + - name: Untrusted data unsafely deserialized + file: sast-policy-58.adoc + - name: Encryption algorithms used with an insecure mode or padding + file: sast-policy-59.adoc + - name: Use of hardcoded passwords in Python code + file: sast-policy-6.adoc + - name: HTML Autoescape Mechanism Should Not Be Globally Disabled + file: sast-policy-60.adoc + - name: LDAP Queries Should Not Be Vulnerable to Injection Attacks + file: sast-policy-61.adoc + - name: Logging Should Not Be Vulnerable to Injection Attacks + file: sast-policy-62.adoc + - name: Sending Emails is Security-Sensitive + file: sast-policy-63.adoc + - name: Server Hostnames Should not verified during SSL/TLS connections + file: sast-policy-64.adoc + - name: Inadequate Encryption Strength + file: sast-policy-65.adoc + - name: LDAP anonymous binds are used + file: sast-policy-66.adoc + - name: Weak SSL/TLS protocol used + file: sast-policy-67.adoc + - name: Weak SSL/TLS protocol used + file: sast-policy-68.adoc + - name: Files and directories are assigned loose permissions + file: sast-policy-69.adoc + - name: Improper Authorization in Handler for Custom URL Scheme + file: sast-policy-70.adoc + - name: Insecure use of no password or weak password when connecting to a database + file: sast-policy-71.adoc + - name: Hash functions used without an unpredictable salt + file: sast-policy-72.adoc + - name: None attributes accessed + file: sast-policy-73.adoc + - name: Writing unvalidated input into JSON + file: sast-policy-82.adoc + - name: Path injection + file: sast-policy-86.adoc + - name: Dynamic code execution (vulnerable to injection attacks) + file: sast-policy-87.adoc + - name: HTTP response headers should not be vulnerable to injection attacks + file: sast-policy-88.adoc + - name: Cross-site scripting (XSS) exposure + file: sast-policy-89.adoc + - name: Improper Restriction of XML External Entity Reference + file: sast-policy-90.adoc + - name: Uncontrolled Resource Consumption + file: sast-policy-91.adoc + - name: Cleartext Transmission of Sensitive Information + file: sast-policy-93.adoc + - name: Improper Certificate Validation + file: sast-policy-94.adoc + - name: Insecure active debug code + file: sast-policy-96.adoc + - name: Improper access control + file: sast-policy-97.adoc + - name: Key Exchange without Entity Authentication + file: sast-policy-98.adoc + - name: Insecure temporary file + file: sast-policy-99.adoc + - name: SAST Python Policy Index + file: sast-python-policy-index.adoc diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-java-policy-index.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-java-policy-index.adoc new file mode 100644 index 000000000..e7138d919 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-java-policy-index.adoc @@ -0,0 +1,338 @@ +== SAST Java Policy Index + +[width=85%] +[cols="1,1,1"] +|=== +|Policy|Checkov ID| Severity + +|xref:sast-policy-1.adoc[Improper neutralization of input during web page generation ('Cross-site Scripting')] +|CKV3_SAST_1 +|LOW + +|xref:sast-policy-7.adoc[Improper neutralization of argument delimiters in a command ('Argument Injection')] +|CKV3_SAST_7 +|HIGH + +|xref:sast-policy-8.adoc[Files or directories accessible to external parties] +|CKV3_SAST_8 +|HIGH + +|xref:sast-policy-9.adoc[Improper neutralization of CRLF sequences in HTTP headers ('HTTP Response Splitting')] +|CKV3_SAST_9 +|MEDIUM + +|xref:sast-policy-12.adoc[Integrity of the data during transmission is not being verified] +|CKV3_SAST_12 +|MEDIUM + +|xref:sast-policy-13.adoc[Unsafe custom MessageDigest is implemented] +|CKV3_SAST_13 +|MEDIUM + +|xref:sast-policy-14.adoc[Unsafe use of Cross-Origin Resource Sharing (CORS)] +|CKV3_SAST_14 +|MEDIUM + +|xref:sast-policy-15.adoc[Unsafe use of hazelcast symmetric encryption] +|CKV3_SAST_15 +|LOW + +|xref:sast-policy-16.adoc[Cookie created without HttpOnly flag] +|CKV3_SAST_16 +|LOW + +|xref:sast-policy-17.adoc[Unsafe DES algorithm used] +|CKV3_SAST_17 +|MEDIUM + +|xref:sast-policy-18.adoc[Encryption keys with less than 128 bits] +|CKV3_SAST_18 +|MEDIUM + +|xref:sast-policy-19.adoc[Cookie created without Secure flag set] +|CKV3_SAST_19 +|LOW + +|xref:sast-policy-20.adoc[Cookie stored for an extended period of time] +|CKV3_SAST_20 +|MEDIUM + +|xref:sast-policy-21.adoc[Cookie contains sensitive session info] +|CKV3_SAST_21 +|HIGH + +|xref:sast-policy-22.adoc[Trust Boundary is Violated] +|CKV3_SAST_22 +|LOW + +|xref:sast-policy-23.adoc[Security of REST web service is not analyzed] +|CKV3_SAST_23 +|MEDIUM + +|xref:sast-policy-24.adoc[File Creation in Publicly Shared Directories] +|CKV3_SAST_24 +|MEDIUM + +|xref:sast-policy-25.adoc[CSRF is Disabled] +|CKV3_SAST_25 +|MEDIUM + +|xref:sast-policy-26.adoc[Authorization is not robust] +|CKV3_SAST_26 +|MEDIUM + +|xref:sast-policy-43.adoc[Pathname input not restricted] +|CKV3_SAST_43 +|MEDIUM + +|xref:sast-policy-44.adoc[File path not validated in file uploads] +|CKV3_SAST_44 +|LOW + +|xref:sast-policy-45.adoc[Pathname not restricted in HTTP requests] +|CKV3_SAST_45 +|MEDIUM + +|xref:sast-policy-46.adoc[File path not validated for file writes] +|CKV3_SAST_46 +|MEDIUM + +|xref:sast-policy-47.adoc[Missing validation for paths when processing style sheets] +|CKV3_SAST_47 +|HIGH + +|xref:sast-policy-48.adoc[Unrestricted directory for pathname construction from HTTP requests] +|CKV3_SAST_48 +|MEDIUM + +|xref:sast-policy-49.adoc[Unrestricted pathnames from HTTP requests] +|CKV3_SAST_49 +|HIGH + +|xref:sast-policy-102.adoc[Cleartext Transmission of Sensitive Information] +|CKV3_SAST_102 +|MEDIUM + +|xref:sast-policy-103.adoc[Collapse of data into unsafe value] +|CKV3_SAST_103 +|MEDIUM + +|xref:sast-policy-104.adoc[Cross-Site Request Forgery (CSRF)] +|CKV3_SAST_104 +|MEDIUM + +|xref:sast-policy-105.adoc[Deserialization of untrusted data] +|CKV3_SAST_105 +|MEDIUM + +|xref:sast-policy-106.adoc[Deserialization of Untrusted Data] +|CKV3_SAST_106 +|MEDIUM + +|xref:sast-policy-107.adoc[External Control of System or Configuration Setting] +|CKV3_SAST_107 +|HIGH + +|xref:sast-policy-108.adoc[External control of system or configuration setting] +|CKV3_SAST_108 +|MEDIUM + +|xref:sast-policy-109.adoc[Improper authentication] +|CKV3_SAST_109 +|MEDIUM + +|xref:sast-policy-110.adoc[Improper certificate validation] +|CKV3_SAST_110 +|MEDIUM + +|xref:sast-policy-111.adoc[Improper certificate validation] +|CKV3_SAST_111 +|MEDIUM + +|xref:sast-policy-112.adoc[Improper control of generation of code ('Code Injection')] +|CKV3_SAST_112 +|HIGH + +|xref:sast-policy-113.adoc[Improper control of generation of code ('Code Injection')] +|CKV3_SAST_113 +|HIGH + +|xref:sast-policy-114.adoc[Improper Handling of Unicode Encoding] +|CKV3_SAST_114 +|HIGH + +|xref:sast-policy-115.adoc[Improper Input Validation] +|CKV3_SAST_115 +|MEDIUM + +|xref:sast-policy-116.adoc[Improper Input Validation] +|CKV3_SAST_116 +|HIGH + +|xref:sast-policy-117.adoc[Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] +|CKV3_SAST_117 +|HIGH + +|xref:sast-policy-118.adoc[Improper neutralization of CRLF sequences ('CRLF Injection')] +|CKV3_SAST_118 +|HIGH + +|xref:sast-policy-119.adoc[Improper neutralization of data within XPath expressions ('XPath Injection')] +|CKV3_SAST_119 +|HIGH + +|xref:sast-policy-120.adoc[Improper neutralization of CRLF sequences ('CRLF Injection')] +|CKV3_SAST_120 +|HIGH + +|xref:sast-policy-121.adoc[Improper neutralization of special elements used in a command] +|CKV3_SAST_121 +|HIGH + +|xref:sast-policy-122.adoc[Improper neutralization of special elements used in an expression language statement ('Expression Language Injection')] +|CKV3_SAST_122 +|HIGH + +|xref:sast-policy-123.adoc[Improper neutralization of special elements used in an OS command ('OS Command Injection')] +|CKV3_SAST_123 +|MEDIUM + +|xref:sast-policy-124.adoc[Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')] +|CKV3_SAST_124 +|HIGH + +|xref:sast-policy-125.adoc[Utilizing a class that isn't primitive in Java RMI could lead to a vulnerability associated with insecure deserialization.] +|CKV3_SAST_125 +|MEDIUM + +|xref:sast-policy-126.adoc[Improper privilege management] +|CKV3_SAST_126 +|MEDIUM + +|xref:sast-policy-127.adoc[Improper restriction of XML external entity reference ('XXE')] +|CKV3_SAST_127 +|HIGH + +|xref:sast-policy-128.adoc[Improper restriction of XML external entity reference ('XXE')] +|CKV3_SAST_128 +|HIGH + +|xref:sast-policy-129.adoc[Improper validation of certificate with host mismatch] +|CKV3_SAST_129 +|HIGH + +|xref:sast-policy-130.adoc[Inadequate encryption strength] +|CKV3_SAST_130 +|MEDIUM + +|xref:sast-policy-131.adoc[Inadequate encryption strength] +|CKV3_SAST_131 +|MEDIUM + +|xref:sast-policy-132.adoc[Inadequate encryption strength] +|CKV3_SAST_132 +|MEDIUM + +|xref:sast-policy-133.adoc[Incorrect behavior order: validate before canonicalize] +|CKV3_SAST_133 +|MEDIUM + +|xref:sast-policy-134.adoc[Incorrect permission assignment for critical resource] +|CKV3_SAST_134 +|MEDIUM + +|xref:sast-policy-135.adoc[Incorrect Permission Assignment for Critical Resource] +|CKV3_SAST_135 +|MEDIUM + +|xref:sast-policy-136.adoc[Incorrect type conversion or cast] +|CKV3_SAST_136 +|MEDIUM + +|xref:sast-policy-137.adoc[Information exposure through an error message] +|CKV3_SAST_137 +|MEDIUM + +|xref:sast-policy-138.adoc[Information exposure through an error message] +|CKV3_SAST_138 +|MEDIUM + +|xref:sast-policy-139.adoc[Missing authentication for critical function (database)] +|CKV3_SAST_139 +|MEDIUM + +|xref:sast-policy-140.adoc[Missing authentication for critical function (LDAP)] +|CKV3_SAST_140 +|MEDIUM + +|xref:sast-policy-141.adoc[Permissive Cross-domain Policy with Untrusted Domains] +|CKV3_SAST_141 +|HIGH + +|xref:sast-policy-142.adoc[Sensitive Cookie in HTTPS Session Without 'Secure' Attribute] +|CKV3_SAST_142 +|MEDIUM + +|xref:sast-policy-143.adoc[Sensitive Cookie in HTTPS Session Without 'Secure' Attribute] +|CKV3_SAST_143 +|MEDIUM + +|xref:sast-policy-144.adoc[Sensitive cookie without 'HttpOnly' flag] +|CKV3_SAST_144 +|MEDIUM + +|xref:sast-policy-145.adoc[Server-Side Request Forgery (SSRF)] +|CKV3_SAST_145 +|HIGH + +|xref:sast-policy-147.adoc[URL Redirection to Untrusted Site ('Open Redirect')] +|CKV3_SAST_147 +|HIGH + +|xref:sast-policy-148.adoc[Use of a broken or risky cryptographic algorithm] +|CKV3_SAST_148 +|HIGH + +|xref:sast-policy-149.adoc[Use of a broken or risky cryptographic algorithm (SHA1/MD5)] +|CKV3_SAST_149 +|MEDIUM + +|xref:sast-policy-150.adoc[Use of externally-controlled format string] +|CKV3_SAST_150 +|HIGH + +|xref:sast-policy-151.adoc[Unencrypted payload with JWT] +|CKV3_SAST_151 +|MEDIUM + +|xref:sast-policy-155.adoc[Use of insufficiently random values] +|CKV3_SAST_155 +|MEDIUM + +|xref:sast-policy-156.adoc[Use of RSA algorithm without OAEP] +|CKV3_SAST_156 +|MEDIUM + +|xref:sast-policy-162.adoc[Permissive cross-domain policy with untrusted domains] +|CKV3_SAST_162 +|MEDIUM + +|xref:sast-policy-163.adoc[Improper neutralization of special elements in output used by a downstream component ('Injection')] +|CKV3_SAST_163 +|MEDIUM + +|xref:sast-policy-164.adoc[Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')] +|CKV3_SAST_164 +|LOW + +|xref:sast-policy-165.adoc[Improper Neutralization of Special Elements in Data Query Logic] +|CKV3_SAST_165 +|MEDIUM + +|xref:sast-policy-171.adoc[Expression injection (OGNL)] +|CKV3_SAST_171 +|HIGH + +|xref:sast-policy-172.adoc[Improper neutralization of special elements used in an LDAP query ('LDAP Injection')] +|CKV3_SAST_172 +|HIGH diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-1.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-1.adoc new file mode 100644 index 000000000..994aafc72 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-1.adoc @@ -0,0 +1,66 @@ +== Improper neutralization of input during web page generation ('Cross-site Scripting') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_1 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/79.html[CWE-79: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)[A03:2021 - Injection] + +|=== + +=== Description + +The potential vulnerability of Cross-site Scripting (XSS) is detected. It arises when user-supplied data from an HTTP request is returned directly in an HTTP response's `sendError` method. This can be exploited by malicious actors to inject script code and might lead to several severe implications. + +For applications running on Apache Tomcat versions 9 and above, the output is automatically encoded, making them less vulnerable to this issue. However, for earlier versions or other application servers, proactive measures need to be taken. + +Cross-site Scripting can manifest in various contexts, from HTML tags, attributes, event attributes, to script blocks and URLs. Particularly in script blocks, multiple encoding methods need to be considered. + +The best practice is to avoid directly embedding user inputs into responses. If this cannot be avoided, ensure that the user inputs are correctly sanitized or encoded to neutralize potentially harmful scripts. + +To address this: + +1. Avoid using direct user input in the `sendError` message parameter. +2. Implement output encoding for user-supplied input using tools like [Apache Commons Text](https://commons.apache.org/proper/commons-text/). +3. Ensure you are aware of and have taken the required precautions depending on the context where the user input is used. + +For example: + +[source,java] +---- +// Get user input +String userInput = request.getParameter("key"); +// Encode the input using the Html4 encoder +String encoded = StringEscapeUtils.escapeHtml4(userInput); +// Respond with the error code and value +response.sendError(401, encoded); +---- + +For a comprehensive overview of XSS and its prevention techniques, refer to the OWASP guide: +- https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html + +=== Fix - Buildtime + +Ensure that all user inputs that are being reflected in HTTP responses, especially in `sendError` messages, are adequately sanitized or encoded to prevent Cross-site Scripting attacks. + +By strictly following this guideline, you can effectively safeguard your web applications from potential XSS vulnerabilities. \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-102.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-102.adoc new file mode 100644 index 000000000..1c43815f3 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-102.adoc @@ -0,0 +1,73 @@ + +== Cleartext Transmission of Sensitive Information + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_102 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/319.html[CWE:319 - Cleartext Transmission of Sensitive Information] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects the usage of HTTP (instead of HTTPS) for transmitting sensitive information, which can lead to the leakage of sensitive data. + +Vulnerable code example: + +[source,java] +---- +import java.net.HttpURLConnection; +import java.io.DataOutputStream; + +... + +HttpURLConnection connection = (HttpURLConnection) url.openConnection(); +DataOutputStream outputStream = new DataOutputStream(connection.getOutputStream()); + +// Sending sensitive data over HTTP +---- + +The above code is vulnerable because it establishes an HTTP connection (`HttpURLConnection`) and sends sensitive data over the network in plain text using `DataOutputStream`. + +=== Fix - Buildtime + +To fix the issue, you should use an HTTPS connection instead of an HTTP connection to ensure secure transmission of sensitive information. + +Secure code example: + +[source,java] +---- +import java.net.HttpsURLConnection; +import java.io.DataOutputStream; + +... + +HttpsURLConnection connection = (HttpsURLConnection) url.openConnection(); +DataOutputStream outputStream = new DataOutputStream(connection.getOutputStream()); + +// Sending sensitive data over HTTPS +---- + +In the secure code example, we have replaced `HttpURLConnection` with `HttpsURLConnection` to establish an HTTPS connection. This ensures that the sensitive data is transmitted encrypted and secure over the network. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-103.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-103.adoc new file mode 100644 index 000000000..842ffaba0 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-103.adoc @@ -0,0 +1,62 @@ + +== Collapse of data into unsafe value + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_103 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/20.html[CWE:20 - Improper Input Validation] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects the use of the replace, replaceAll, and replaceFirst methods in Java without proper input validation, which can lead to code injection vulnerabilities. + +Vulnerable code example: + +[source,java] +---- +String input = request.getParameter("input"); +String unsafeValue = "Hello, World!".replaceAll("World", input); +---- + +In the above code, the input parameter is directly passed into the replaceAll method without any validation or sanitization. An attacker can potentially manipulate the input value to execute malicious code and perform code injection attacks. + +=== Fix - Buildtime + +To fix this issue, you should properly validate and sanitize the input before using replace or its variants. One way to do this is to use input validation techniques such as input whitelisting or input encoding. + +Secure code example: + +[source,java] +---- +String input = request.getParameter("input"); +String sanitizedInput = sanitizeInput(input); +String safeValue = "Hello, World!".replaceAll("World", sanitizedInput); +---- + +In the above code, the input parameter is first sanitized using a sanitizeInput() function. This function ensures that any potentially harmful characters are removed or properly encoded. The sanitized input is then used in the replaceAll method, ensuring that only safe values are manipulated. + +By validating and sanitizing the input, we prevent the possibility of code injection attacks by ensuring that only valid and safe values are processed. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-104.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-104.adoc new file mode 100644 index 000000000..9053d5285 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-104.adoc @@ -0,0 +1,57 @@ + +== Cross-Site Request Forgery (CSRF) + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_104 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/352.html[CWE:352 - Cross-Site Request Forgery (CSRF)] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This SAST policy detects instances where Cross-Site Request Forgery (CSRF) protections are disabled or cookies are set with the SameSite attribute to values other than "Strict". These configurations can expose apps to attacks. + +Vulnerable code example: + +[source,java] +---- +CSRF.disable(); +---- + +The above code is vulnerable because it disables CSRF protections, allowing potential CSRF attacks to occur. + +=== Fix - Buildtime + +To fix the issue, you need to enable CSRF protections and set the SameSite attribute of cookies to "Strict". + +Secure code example: + +[source,java] +---- +http.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse().withSameSite(CookieSameSite.STRICT)); +---- + +The above code is no longer vulnerable because it enables CSRF protections and sets the SameSite attribute of cookies to "Strict", preventing potential CSRF attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-105.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-105.adoc new file mode 100644 index 000000000..3abb9a542 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-105.adoc @@ -0,0 +1,59 @@ + +== Deserialization of untrusted data + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_105 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/502.html[CWE-502: Deserialization of Untrusted Data] + +|OWASP Categories +|https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/[A08:2021 - Software and Data Integrity Failures] + +|=== + +=== Description + +This SAST policy detects the vulnerability of deserialization of untrusted data in Java code. This vulnerability can be exploited by malicious actors to inject code or manipulate data. The policy recommends using JSON for serialization, specifying allowed deserialization objects, and avoiding base types. + +Vulnerable code example: + +[source,java] +---- +XMLDecoder decoder = new XMLDecoder(inputStream); +Object obj = decoder.readObject(); +---- + +The above code is vulnerable because it uses an XMLDecoder to deserialize data from an inputStream. This allows for the possibility of deserializing malicious or untrusted data, leading to code injection or data manipulation. + +=== Fix - Buildtime + +To fix the issue, it is recommended to use JSON for serialization instead of XML. JSON provides a safer and more secure way of transferring and deserializing data. Additionally, it is important to specify and validate the allowed deserialization objects to prevent arbitrary code execution. + +Secure code example: + +[source,java] +---- +JsonDecoder decoder = new JsonDecoder(inputStream, AllowedClass.class); +AllowedClass obj = decoder.readObject(); +---- + +The above code is no longer vulnerable because it uses a JsonDecoder, which is a safer alternative to XMLDecoder for deserializing data. The code also specifies the allowed deserialization class (AllowedClass), ensuring that only trusted objects are deserialized. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-106.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-106.adoc new file mode 100644 index 000000000..c21da2345 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-106.adoc @@ -0,0 +1,57 @@ + +== Deserialization of Untrusted Data + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_106 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/502.html[CWE:502 - Deserialization of Untrusted Data] + +|OWASP Categories +|https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/[A08:2021 - Software and Data Integrity Failures] + +|=== + +=== Description + +This policy detects the enabling of extensions in an Apache XML RPC server or client, which can lead to a deserialization vulnerability. This vulnerability allows an attacker to execute arbitrary code. + +Vulnerable code example: + +[source,java] +---- +XmlRpcServerConfigImpl.setEnabledForExtensions(true); +---- + +Enabling extensions in the XmlRpcServerConfigImpl class can expose the application to a deserialization vulnerability, as it allows for the execution of arbitrary code. + +=== Fix - Buildtime + +To fix this issue, the enabling of extensions should be set to false. + +Secure code example: + +[source,java] +---- +XmlRpcServerConfigImpl.setEnabledForExtensions(false); +---- + +By setting the `setEnabledForExtensions` parameter to `false`, the code ensures that extensions are not enabled, thereby eliminating the deserialization vulnerability. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-107.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-107.adoc new file mode 100644 index 000000000..f887334e2 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-107.adoc @@ -0,0 +1,65 @@ + +== External Control of System or Configuration Setting + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_107 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/15.html[CWE:15 - External Control of System or Configuration Setting] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +This policy detects potential vulnerabilities where external inputs, such as request parameters or headers, are used to control system or configuration settings. This can lead to security misconfigurations and allow attackers to manipulate the system behavior. + +Vulnerable code example: + +[source,java] +---- +String[] values = req.getParameterValues("input"); +String arg = args[0]; +String header = req.getHeader("header"); +---- +In the above code, the values of the `input` parameter, the first element of the `args` array, and the value of the `header` HTTP header are directly used without any validation or sanitization. This can allow an attacker to control these values and potentially manipulate the system or configuration settings. + +=== Fix - Buildtime + +To fix this issue, you should always validate and sanitize any input received from request parameters or headers before using them to control system or configuration settings. + +Secure code example: + +[source,java] +---- +String[] values = req.getParameterValues("input"); +String arg = validateAndSanitize(args[0]); +String header = validateAndSanitize(req.getHeader("header")); + +public String validateAndSanitize(String value) { + // Implement validation and sanitization logic here + // ... + return validatedAndSanitizedValue; +} +---- +In the above fixed code, the `validateAndSanitize` method is used to validate and sanitize the input values before using them. This helps prevent any potential security misconfigurations and ensures that only safe and trusted values are used to control system or configuration settings. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-108.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-108.adoc new file mode 100644 index 000000000..fe6339b73 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-108.adoc @@ -0,0 +1,63 @@ + +== External control of system or configuration setting + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_108 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/15.html[CWE:15 - External Control of System or Configuration Setting] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +This SAST policy detects instances where user input is used in the `java.sql.Connection`'s `setCatalog` call. This can be a potential issue as it may allow attackers to change the database during a connection, leading to disruptions or unexpected behaviors. + +Vulnerable code example: + +[source,java] +---- +String userInput = request.getParameter("catalogName"); +connection.setCatalog(userInput); +---- + +In the above code, the `setCatalog` method uses user input `catalogName` directly without any validation or sanitization. This allows an attacker to manipulate the `catalogName` parameter and potentially change the database being accessed. + +=== Fix - Buildtime + +To fix this issue, it is important to properly validate and sanitize the user input before using it in the `setCatalog` call. This can be done by implementing input validation and only allowing certain values or ensuring the input matches specific patterns. + +Secure code example: + +[source,java] +---- +String userInput = request.getParameter("catalogName"); +if(isValidCatalogName(userInput)) { + connection.setCatalog(userInput); +} +---- + +In the secure code example, a function `isValidCatalogName` is used to validate the `userInput`. Only if the `userInput` passes the validation, it is used in the `setCatalog` call. This prevents malicious input from being used to change the database during the connection. + +By implementing proper input validation and sanitization, the risk of external control of system or configuration settings is mitigated. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-109.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-109.adoc new file mode 100644 index 000000000..57256226c --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-109.adoc @@ -0,0 +1,60 @@ + +== Improper authentication + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_109 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/287.html[CWE:287 - Improper Authentication] + +|OWASP Categories +|https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[A07:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +This policy detects cases where SAML's XML parsing is not properly authenticated, which can allow attackers to manipulate the XML comments and bypass security checks. + +Vulnerable code example: + +[source,java] +---- +BasicParserPool $POOL = new BasicParserPool(); +$POOL.parse(); +---- + +The above code is vulnerable because it creates a BasicParserPool object without invoking the `setIgnoreComments(true)` method. This means that if the XML contains malicious comments, they can be manipulated by attackers to disrupt attestation fields and bypass security checks. + +=== Fix - Buildtime + +To fix the issue, invoke the `setIgnoreComments(true)` method on the BasicParserPool object. + +Secure code example: + +[source,java] +---- +BasicParserPool $POOL = new BasicParserPool(); +$POOL.setIgnoreComments(true); +$POOL.parse(); +---- + +The above code is no longer vulnerable because it properly sets the `setIgnoreComments` property of the BasicParserPool object to true. This ensures that any XML comments included in the parsing process will be ignored, preventing attackers from manipulating them to bypass security checks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-110.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-110.adoc new file mode 100644 index 000000000..75c1a0157 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-110.adoc @@ -0,0 +1,57 @@ + +== Improper certificate validation + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_110 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/295.html[CWE-295: Improper Certificate Validation] + +|OWASP Categories +|https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[A07:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +This policy detects the use of the "DefaultHttpClient" class from the "org.apache.http.impl.client" package and the "SSLContext.getInstance" method with specific insecure protocols in Java code. These insecure methods do not properly validate SSL/TLS certificates, leaving the application vulnerable to data interception or malicious transmission. + +Vulnerable code example: + +[source,java] +---- +DefaultHttpClient client = new DefaultHttpClient(); +---- + +The above code is vulnerable because it uses the deprecated "DefaultHttpClient" class, which does not perform proper certificate validation, potentially allowing for Man-in-the-Middle attacks or data interception. + +=== Fix - Buildtime + +To fix this issue, you should avoid using the deprecated "DefaultHttpClient" class and instead opt for the "java.net.http.HttpClient" class introduced in Java 9, which provides automatic TLS validation for secure connections. + +Secure code example: + +[source,java] +---- +HttpClient client = HttpClient.newBuilder().build(); +---- + +The above code is no longer vulnerable because it uses the modern "HttpClient" class, which performs automatic TLS validation, ensuring secure connections. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-111.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-111.adoc new file mode 100644 index 000000000..81996e7e0 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-111.adoc @@ -0,0 +1,66 @@ + +== Improper certificate validation + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_111 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/295.html[CWE:295 - Improper Certificate Validation] + +|OWASP Categories +|https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[A07:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +The SAST policy detects improper certificate validation in Java code. This occurs when the `HostnameVerifier` is overridden to always return `true` or when the `X509TrustManager` is configured to return `null`, effectively disabling the validation of server or client certificates. + +Vulnerable code example: + +[source,java] +---- +class MyHostnameVerifier implements HostnameVerifier { + // Other methods + public boolean verify(String hostname, SSLSession session) { + return true; + } + // Other methods +} +---- + +The above code is vulnerable because it overrides the `verify` method of the `HostnameVerifier` interface and always returns `true`. This means that any hostname would be considered valid, bypassing certificate validation. + +=== Fix - Buildtime + +To fix this issue, you should not override the default `HostnameVerifier`. Use the default implementation or provide a custom implementation that performs proper certificate validation. + +Secure code example: + +[source,java] +---- +// Use the default implementation +HostnameVerifier verifier = HttpsURLConnection.getDefaultHostnameVerifier(); +---- + +The above code is no longer vulnerable because it uses the default `HostnameVerifier` implementation, which performs proper certificate validation. By using the default implementation, the code ensures that the server's identity is verified against the certificate provided. + +Note: The fix may vary depending on the specific use case and requirements, but the key point is to ensure proper certificate validation is performed. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-112.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-112.adoc new file mode 100644 index 000000000..5055fdd86 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-112.adoc @@ -0,0 +1,59 @@ + +== Improper control of generation of code ('Code Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_112 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/94.html[CWE-94: Improper Control of Generation of Code ('Code Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects improper control of generation of code, also known as code injection, in Java applications. It identifies a vulnerability where user input is directly used in a template string, allowing an attacker to execute arbitrary Java code, including OS system commands. Specifically, the policy looks for the use of `HttpServletRequest.getParameter()` in the source code, and the use of `Velocity.evaluate()`, `$C.process()`, or `$C.evaluate()` with user-supplied input in the template string. + +Vulnerable code example: + +[source,java] +---- +String userParam = request.getParameter("param"); +Velocity.evaluate("Hello $userParam"); // Vulnerable code +---- + +The above code is vulnerable because it directly uses user input (`request.getParameter()`) in a template string (`Velocity.evaluate()`), allowing an attacker to inject arbitrary Java code. + +=== Fix - Buildtime + +To fix this issue, you should never call `Velocity.evaluate()` with user-supplied input in the template string. Instead, you should sanitize the user input and ensure that it does not contain any malicious code. One way to achieve this is by using parameterized templates or applying proper input validation and encoding. + +Secure code example: + +[source,java] +---- +String userParam = sanitize(request.getParameter("param")); // Sanitize user input +Velocity.evaluate("Hello $userParam"); // Secure code +---- + +The above code is no longer vulnerable because it sanitizes the user input and ensures that it does not include any malicious code. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-113.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-113.adoc new file mode 100644 index 000000000..3a95d6dcd --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-113.adoc @@ -0,0 +1,79 @@ + +== Improper control of generation of code ('Code Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_113 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/94.html[CWE-94: Improper Control of Generation of Code ('Code Injection')] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects improper control of generation of code ('Code Injection') vulnerabilities in Java code. It identifies instances where user input is passed directly to the `eval` method of a `ScriptEngine`, which may execute OS commands and lead to code injection attacks. + +Vulnerable code example: + +[source,java] +---- +import javax.script.*; + +public class Example { + public static void main(String[] args) { + ScriptEngineManager manager = new ScriptEngineManager(); + ScriptEngine engine = manager.getEngineByName("javascript"); + + String userInput = "1+1"; + engine.eval(userInput); // Vulnerable code + } +} +---- + +The above code is vulnerable because it takes user input (`userInput`) and directly passes it to the `eval` method of the `ScriptEngine`, without any validation or sanitization. An attacker could provide malicious input, such as `userInput = "1; OS.execute('rm -rf /');"`, causing the `eval` method to execute arbitrary OS commands. + +=== Fix - Buildtime + +To fix this issue, it is recommended to avoid using user input directly in the `eval` method of a `ScriptEngine`. Instead, you should use more secure alternatives such as hardcoded JavaScript, lookup tables, or `javax.script.Bindings`. + +Secure code example: + +[source,java] +---- +import javax.script.*; + +public class Example { + public static void main(String[] args) { + ScriptEngineManager manager = new ScriptEngineManager(); + ScriptEngine engine = manager.getEngineByName("javascript"); + + String userInput = "1+1"; + engine.eval("var x = " + userInput + ";"); // Secure code + } +} +---- + +In the secure code example, the user input (`userInput`) is first concatenated with a pre-defined JavaScript code (`"var x = "`) to form a valid JavaScript expression. This ensures that the user input is treated as a variable assignment and not as direct code execution. Thus, the vulnerability is mitigated as the injected code will not be executed. + + + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-114.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-114.adoc new file mode 100644 index 000000000..bc6ee30e1 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-114.adoc @@ -0,0 +1,59 @@ + +== Improper Handling of Unicode Encoding + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_114 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/176.html[CWE-176: Improper Handling of Unicode Encoding] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects the improper handling of Unicode encoding in Java code. This vulnerability can occur when the input containing Unicode encoding is not properly handled, leading to potential security vulnerabilities. + +Vulnerable code example: + +[source,java] +---- +args[$0].toLowerCase(); +---- + +In the above code, the input value from the "args" array is converted to lowercase without properly handling Unicode encoding. This can lead to security vulnerabilities such as Unicode-based homograph attacks or bypassing input validation. + +=== Fix - Buildtime + +To fix this issue, you should use appropriate methods to handle Unicode encoding. In this case, you can use the `java.text.Normalizer.normalize()` method to ensure proper handling of Unicode characters. + +Secure code example: + +[source,java] +---- +Normalizer.normalize(args[$0], Normalizer.Form.NFKC).toLowerCase(); +---- + +In the secure code example, the `Normalizer.normalize()` method is used to normalize the input string and convert it to lowercase. This ensures proper handling of Unicode encoding and reduces the risk of security vulnerabilities. + +By using the `Normalizer.normalize()` method with the appropriate normalization form, the code mitigates the risk of Unicode-based attacks and ensures the proper handling of Unicode characters in the input. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-115.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-115.adoc new file mode 100644 index 000000000..9a1b75480 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-115.adoc @@ -0,0 +1,92 @@ + +== Improper Input Validation + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_115 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects improper input validation in Java classes that extend ActionForm or ValidatorForm. Improper input validation can lead to vulnerabilities such as injection attacks. + +Vulnerable code example: + +[source,java] +---- +class UserForm extends ActionForm { + private String username; + private String password; + + // Getter and setter methods + + public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) { + // Improper input validation + if (username.length() == 0 || password.length() == 0) { + ActionErrors errors = new ActionErrors(); + errors.add("username", new ActionMessage("error.username.required")); + errors.add("password", new ActionMessage("error.password.required")); + return errors; + } + return null; + } +} +---- + +The above code is vulnerable because it performs inadequate input validation for the username and password fields. It only checks if the length of the fields is zero, which can be easily bypassed by an attacker. + +=== Fix - Buildtime + +To fix this issue, proper input validation should be implemented. + +Secure code example: + +[source,java] +---- +class UserForm extends ActionForm { + private String username; + private String password; + + // Getter and setter methods + + public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) { + ActionErrors errors = new ActionErrors(); + + if (username == null || username.trim().isEmpty()) { + errors.add("username", new ActionMessage("error.username.required")); + } + + if (password == null || password.trim().isEmpty()) { + errors.add("password", new ActionMessage("error.password.required")); + } + + return errors; + } +} +---- + +The code above demonstrates secure input validation. It checks if the username and password are null or empty after trimming whitespace. This helps to avoid injection attacks by ensuring that the input is properly validated and sanitized. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-116.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-116.adoc new file mode 100644 index 000000000..732200616 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-116.adoc @@ -0,0 +1,58 @@ + +== Improper Input Validation + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_116 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This SAST policy detects improper input validation in Java code. Without proper access control, executing an LDAP statement that contains a user-controlled value can allow an attacker to abuse poorly configured LDAP context. + +Vulnerable code example: + +[source,java] +---- +new SearchControls($SCOPE, $CLIMIT, $TLIMIT, $ATTR, true, $DEREF) +---- + +The above code is vulnerable because it directly takes user-controlled values ($SCOPE, $CLIMIT, $TLIMIT, $ATTR, $DEREF) as parameters for the `SearchControls` constructor without proper validation or sanitization. This can potentially lead to LDAP injection vulnerabilities. + +=== Fix - Buildtime + +To fix the issue, proper input validation and sanitization techniques should be applied to user-controlled values before passing them to LDAP statements. This can be done by implementing strong input validation checks such as whitelist validation (ensuring only allowed characters are accepted) and input sanitization (removing or escaping special characters). + +Secure code example: + +[source,java] +---- +// Assuming the input values are properly validated and sanitized +new SearchControls(SearchControls.SUBTREE_SCOPE, 100, 10000, new String[] {"cn", "sn"}, true, SearchControls.DEREF_ALWAYS) +---- + +In the secure code example above, the input values have been properly validated and sanitized before constructing the `SearchControls` object. The `SearchControls` constructor now uses specific values (`SUBTREE_SCOPE`, `100`, `10000`, `{"cn", "sn"}`, `true`, `DEREF_ALWAYS`) instead of user-controlled values, reducing the risk of LDAP injection vulnerabilities. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-117.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-117.adoc new file mode 100644 index 000000000..d0b4bb523 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-117.adoc @@ -0,0 +1,64 @@ + +== Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_117 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy detects when a file is opened to read its content, and the filename comes from an input parameter. If an unfiltered parameter is passed to this file API, it could lead to a path traversal vulnerability, allowing files from an arbitrary filesystem location to be read. + +Vulnerable code example: + +[source,java] +---- +String filename = request.getParameter("filename"); +File file = new File(filename); +FileReader fileReader = new FileReader(file); +---- + +In the above code, the `filename` parameter is directly used to create a `File` object and a `FileReader` object without any sanitization or validation. This allows an attacker to manipulate the `filename` parameter and potentially read files from any location on the filesystem. + +=== Fix - Buildtime + +To fix this issue, it is important to validate and sanitize the `filename` parameter before using it to create a `File` object. One approach is to define a whitelist of allowed filenames or restrict the file's location to a specific directory. + +Secure code example: + +[source,java] +---- +String filename = request.getParameter("filename"); +// Validate filename to ensure it is not malicious +if (isValidFilename(filename)) { + File file = new File("/path/to/allowed/directory", filename); + FileReader fileReader = new FileReader(file); +} +---- + +In the secure code example, the `filename` parameter is first passed through a validation function `isValidFilename()` to ensure it does not contain any malicious characters or sequences. If the filename passes the validation, it is then combined with the allowed directory path to create the `File` object. This ensures that only files within the allowed directory can be accessed, mitigating the path traversal vulnerability. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-118.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-118.adoc new file mode 100644 index 000000000..33477e331 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-118.adoc @@ -0,0 +1,59 @@ + +== Improper neutralization of CRLF sequences ('CRLF Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_118 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/93.html[CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This SAST policy detects improper neutralization of CRLF sequences (CRLF Injection) in Java code that involves the use of `setHeader` and `addHeader` methods with tainted data. + +Vulnerable code example: + +[source,java] +---- +String userMessage = req.getParameter("message"); +res.setHeader("X-Message", userMessage); +---- + +The above code is vulnerable because it takes a user-controlled input (`message`) from the request parameter and directly sets it as the value of the `X-Message` header in the response. This can lead to CRLF injection attacks where the attacker can inject newlines and carriage return characters to manipulate the response header and potentially perform malicious actions. + +=== Fix - Buildtime + +To fix the vulnerability, proper input validation and output encoding should be applied. In this case, the `StringEscapeUtils.unescapeJava` method can be used as a sanitizer to remove any potential CRLF sequences or other special characters from the user input before setting it as the header value. + +Secure code example: + +[source,java] +---- +String userMessage = StringEscapeUtils.unescapeJava(req.getParameter("message")); +res.setHeader("X-Message", userMessage); +---- + +In the secure code, the `StringEscapeUtils.unescapeJava` method is used to escape any special characters from the user input before setting it as the header value. This ensures that any CRLF sequences are properly neutralized, preventing any potential CRLF injection attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-119.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-119.adoc new file mode 100644 index 000000000..91d630210 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-119.adoc @@ -0,0 +1,60 @@ + +== Improper neutralization of data within XPath expressions ('XPath Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_119 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/643.html[CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects improper neutralization of data within XPath expressions, also known as XPath Injection. + +Vulnerable code example: + +[source,java] +---- +String xpathQuery = "/*/user[name/text()='" + userInput + "']"; +XPathExpression expr = xpath.compile(xpathQuery); +---- + +The above code is vulnerable because it concatenates user input directly into the XPath query without proper sanitization or parameterization. This allows an attacker to manipulate the XPath query and potentially perform malicious actions such as bypassing protections or extracting sensitive information. + +=== Fix - Buildtime + +To fix the issue, user input should be properly parameterized using a variable resolver. This ensures that the user input is treated as data rather than code. + +Secure code example: + +[source,java] +---- +String xpathQuery = "/*/user[name/text()=$name]"; +XPathExpression expr = xpath.compile(xpathQuery); +expr.setVariable("$name", userInput); +---- + +In the secure code example, the user input is no longer directly concatenated into the XPath query. Instead, a variable `$name` is used and the user input is set as the value of that variable using the `setVariable()` method. This ensures that the user input is properly parameterized and treated as data, preventing XPath injection attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-12.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-12.adoc new file mode 100644 index 000000000..beef6a239 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-12.adoc @@ -0,0 +1,79 @@ +== Integrity of the data during transmission is not being verified + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_12 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/353.html[CWE-353: Missing Support for Integrity Check] + +|OWASP Categories +|https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures[A08:2021 - Software and Data Integrity Failures] + +|=== + + + +=== Description + +This violation is indicating that the cipher being used for encryption does not provide an integrity check to validate that the encrypted data has not been tampered with. Specifically, it flags the use of AES and DES (or triple DES) in ECB (Electronic Codebook) mode and the use of CBC (Cipher Block Chaining) mode with PKCS5 padding, which do not inherently provide integrity checks. + +When these ciphers are used without an additional mechanism to ensure the integrity of the data, it makes the encrypted data susceptible to alterations by an adversary without detection, presenting a security concern. + +Example violating code: + +[source,java] +---- +import javax.crypto.Cipher; +import javax.crypto.spec.SecretKeySpec; + +public class Main { + public static void main(String[] args) throws Exception { + SecretKeySpec key = new SecretKeySpec("1234567812345678".getBytes(), "AES"); + Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); + cipher.init(Cipher.ENCRYPT_MODE, key); + } +} +---- + +In the example above, AES encryption with CBC mode and PKCS5Padding is being used, which doesn't provide an integrity check on the encrypted data. + +=== Fix - Buildtime + +To fix this issue, you could use a mode of operation that provides authenticated encryption, such as GCM (Galois/Counter Mode), which automatically provides integrity checks. Here's how you could modify the example to use AES with GCM: + +[source,java] +---- +import javax.crypto.Cipher; +import javax.crypto.spec.SecretKeySpec; +import javax.crypto.spec.GCMParameterSpec; + +public class Main { + public static void main(String[] args) throws Exception { + SecretKeySpec key = new SecretKeySpec("1234567812345678".getBytes(), "AES"); + Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding"); + GCMParameterSpec spec = new GCMParameterSpec(128, "1234567812345678".getBytes()); // You should use a random IV in real code + cipher.init(Cipher.ENCRYPT_MODE, key, spec); + } +} +---- + +In the updated example, AES is used in GCM mode, which provides both confidentiality and data integrity. Note that a new initialization vector (IV) should be generated for each encryption operation to maintain the security of the encryption. The IV used in this example is a placeholder. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-120.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-120.adoc new file mode 100644 index 000000000..01d92d81b --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-120.adoc @@ -0,0 +1,59 @@ + +== Improper neutralization of CRLF sequences ('CRLF Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_120 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/93.html[CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects improper neutralization of CRLF sequences, also known as CRLF Injection. This vulnerability occurs when log data from untrusted sources is logged without proper validation, allowing attackers to manipulate logs, inject malicious code, and exploit vulnerabilities. + +Vulnerable code example: + +[source,java] +---- +String user = request.getParameter("user"); +LOG.debug("User logged in: " + user); +---- + +In the above code, the user input obtained from the request parameter "user" is directly concatenated to the log message without any sanitization or validation. This can allow an attacker to inject CRLF sequences (\r\n) in the user input, resulting in log injection and potentially enabling further attacks. + +=== Fix - Buildtime + +To fix this issue, the user input should be properly sanitized before being logged. One way to mitigate this vulnerability is to use encoding functions, such as `StringEscapeUtils.escapeJava(value)`, to escape special characters in the user input before concatenating it to the log message. + +Secure code example: + +[source,java] +---- +String user = request.getParameter("user"); +LOG.debug("User logged in: " + StringEscapeUtils.escapeJava(user)); +---- + +In the secure code example, the user input obtained from the request parameter "user" is first passed through the `StringEscapeUtils.escapeJava()` function, which escapes special characters. This ensures that any CRLF sequences or other special characters in the user input are properly neutralized before being logged. This eliminates the possibility of CRLF Injection attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-121.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-121.adoc new file mode 100644 index 000000000..b6c88814a --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-121.adoc @@ -0,0 +1,61 @@ + +== Improper neutralization of special elements used in a command + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_121 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/77.html[CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This SAST policy detects instances where special elements used in a command are not properly neutralized. Specifically, it looks for cases where `MimeMessage` methods are called without encoding new line characters. + +Vulnerable code example: + +[source,java] +``` +MimeMessage message = new MimeMessage(session); +message.setSubject("User input"); +message.addHeader("X-Header", userValue); +``` + +In the above code, the user-provided value for `userValue` is directly passed to the `addHeader` method of the `MimeMessage` object. This can lead to command injection vulnerabilities if the `userValue` contains special characters that could be interpreted as commands or malicious input. + +=== Fix - Buildtime + +To fix this issue, the `userValue` should be properly encoded before being passed to the `addHeader` method. This can be done using methods such as `StringEscapeUtils.escapeJava()` or `URLEncoder.encode()`. + +Secure code example: + +[source,java] +``` +MimeMessage message = new MimeMessage(session); +message.setSubject("User input"); +message.addHeader("X-Header", StringEscapeUtils.escapeJava(userValue)); +``` + +In the secure version of the code, the `userValue` is first escaped using `StringEscapeUtils.escapeJava()` to ensure that any special characters are properly encoded. This prevents command injection vulnerabilities by ensuring that the value is treated as plain text and not interpreted as commands or malicious input. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-122.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-122.adoc new file mode 100644 index 000000000..9c015940f --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-122.adoc @@ -0,0 +1,61 @@ + +== Improper neutralization of special elements used in an expression language statement ('Expression Language Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_122 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/917.html[CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This SAST policy detects improper neutralization of special elements used in an expression language statement, also known as Expression Language Injection. It specifically looks for the usage of the SpringFramework's `SpelExpressionParser.parseExpression` or `SpelExpressionParser.parseRaw` methods with user-supplied input. + +Vulnerable code example: + +[source,java] +---- +SpelExpressionParser parser = new SpelExpressionParser(); +String userInput = request.getParameter("input"); +Expression expression = parser.parseExpression(userInput); +---- + +The above code is vulnerable because it directly passes user-supplied input (`userInput`) to the `parseExpression` method of `SpelExpressionParser`. An attacker can manipulate the input to execute arbitrary Java code, including potentially dangerous OS system commands. + +=== Fix - Buildtime + +To fix this vulnerability, you should avoid calling `SpelExpressionParser.parseExpression` or `SpelExpressionParser.parseRaw` directly with user-supplied input. It is important to properly sanitize and validate any user input before using it in expressions. + +Secure code example: + +[source,java] +---- +SpelExpressionParser parser = new SpelExpressionParser(); +String sanitizedInput = sanitizeInput(request.getParameter("input")); +Expression expression = parser.parseExpression(sanitizedInput); +---- + +In the secure code example, the user input (`request.getParameter("input")`) is first passed through a sanitization function (`sanitizeInput`) that removes any potentially malicious elements. The sanitized input is then used in the `parseExpression` method, ensuring that only safe expressions are evaluated. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-123.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-123.adoc new file mode 100644 index 000000000..87b234692 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-123.adoc @@ -0,0 +1,63 @@ + +== Improper neutralization of special elements used in an OS command ('OS Command Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_123 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/78.html[CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This SAST policy detects improper neutralization of special elements used in an OS command, also known as OS Command Injection vulnerability. This vulnerability occurs when user input is used in constructing commands or command arguments to functions that execute OS commands. This includes filenames supplied by user uploads or downloads. + +Vulnerable code example: + +[source,java] +---- +String fileName = request.getParameter("fileName"); +String command = "rm " + fileName; +Runtime.getRuntime().exec(command); +---- + +The above code is vulnerable because it takes user input (fileName) and directly concatenates it with the "rm" command to create the command that is executed using Runtime.getRuntime().exec() method. An attacker can manipulate the fileName parameter to execute arbitrary commands on the operating system. + +=== Fix - Buildtime + +To fix the OS Command Injection vulnerability, user input should never be directly used in constructing OS commands. Instead, input should be properly validated and sanitized before being used in command execution. + +Secure code example: + +[source,java] +---- +String fileName = request.getParameter("fileName"); +String[] command = {"rm", fileName}; +Runtime.getRuntime().exec(command); +---- + +In the secure code example, the user input is not directly concatenated with the command. Instead, the input is used as an argument in the form of an array of strings. This prevents command injection as the input is not treated as a command string but rather as a separate argument. + +By constructing the command in a safe and controlled manner, the code mitigates the risk of OS Command Injection vulnerability. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-124.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-124.adoc new file mode 100644 index 000000000..bad5cccf4 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-124.adoc @@ -0,0 +1,62 @@ + +== Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_124 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/89.html[CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This SAST policy detects instances of SQL Injection vulnerabilities. SQL Injection is a severe vulnerability where user input can manipulate SQL queries, risking data or system compromise. + +Vulnerable code example: + +[source,java] +---- +String query = "SELECT * FROM users WHERE id = " + userId; +Statement statement = connection.createStatement(); +ResultSet rs = statement.executeQuery(query); +---- + +In the above code, the userId parameter is directly concatenated into the SQL query string, making it vulnerable to SQL Injection attacks. An attacker can manipulate the value of userId to execute arbitrary SQL statements, potentially compromising the integrity of the database. + +=== Fix - Buildtime + +To fix this issue, you should use parameterized queries instead of concatenating user input directly into the query string. This ensures that user input is treated as data and not executable code. + +Secure code example: + +[source,java] +---- +String query = "SELECT * FROM users WHERE id = ?"; +PreparedStatement statement = connection.prepareStatement(query); +statement.setInt(1, userId); +ResultSet rs = statement.executeQuery(); +---- + +In the secure code example, a parameterized query is used. The question mark (?) acts as a placeholder for the userId parameter. The value of userId is then set using the `setInt` method on the `PreparedStatement` object. This approach properly separates the query structure from the user input, preventing SQL Injection attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-125.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-125.adoc new file mode 100644 index 000000000..e489c142b --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-125.adoc @@ -0,0 +1,61 @@ + +== Utilizing a class that isn't primitive in Java RMI could lead to a vulnerability associated with insecure deserialization. + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_125 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/502.html[CWE-502: Deserialization of Untrusted Data] + +|OWASP Categories +|https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/[A08:2021 - Software and Data Integrity Failures] + +|=== + +=== Description + +This policy detects instances in Java Remote Method Invocation (RMI) code where a non-primitive class is used as a parameter, which can lead to a vulnerability associated with insecure deserialization. + +Vulnerable code example: + +[source,java] +---- +public interface MyInterface extends Remote { + void myMethod(MyClass param) throws RemoteException; +} +---- + +The above code is vulnerable because it utilizes a non-primitive class (MyClass) as a parameter in the RMI method. This can introduce a security risk as deserialization of untrusted data can be exploited. + +=== Fix - Buildtime + +To fix the issue, you should avoid using non-primitive classes as parameters in RMI methods. Instead, consider using primitive data types or validated and trusted classes. + +Secure code example: + +[source,java] +---- +public interface MyInterface extends Remote { + void myMethod(int param) throws RemoteException; +} +---- + +The above code is no longer vulnerable as it uses the primitive data type int as the parameter in the RMI method. This eliminates the risk of insecure deserialization. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-126.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-126.adoc new file mode 100644 index 000000000..c7bf8b8c6 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-126.adoc @@ -0,0 +1,60 @@ + +== Improper privilege management + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_126 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/269.html[CWE-269: Improper Privilege Management] + +|OWASP Categories +|https://owasp.org/Top10/A04_2021-Insecure_Design/[A04:2021 - Insecure Design] + +|=== + +=== Description + +This policy detects improper privilege management in Java code. It specifically looks for the use of `RuntimePermission` with the value of `"createClassLoader"` or `ReflectPermission` with the value of `"suppressAccessChecks"`. These permissions grant potentially dangerous capabilities to an application. + +Vulnerable code example: + +[source,java] +---- +RuntimePermission permission = new RuntimePermission("createClassLoader"); +permissionCollection.add(permission); +---- + +The above code is vulnerable because it grants the `createClassLoader` permission to the application. With this permission, an attacker could instantiate their own class loaders and load arbitrary classes, resulting in potential security vulnerabilities. + +=== Fix - Buildtime + +To fix the issue, the code should no longer grant the `createClassLoader` permission. + +Secure code example: + +[source,java] +---- +// Remove the createClassLoader permission +ReflectPermission permission = new ReflectPermission("suppressAccessChecks"); +permissionCollection.add(permission); +---- + +The above code is no longer vulnerable because it only grants the `ReflectPermission` with the value of `"suppressAccessChecks"`. This permission is considered less dangerous compared to the `createClassLoader` permission and does not enable arbitrary class loading. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-127.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-127.adoc new file mode 100644 index 000000000..3a4aaf37f --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-127.adoc @@ -0,0 +1,90 @@ + +== Improper restriction of XML external entity reference ('XXE') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_127 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/611.html[CWE-611: Improper Restriction of XML External Entity Reference] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +This policy detects improper restriction of XML external entity references (XXE) in Java code. XXE attacks occur when an attacker is able to include external entities in an XML document, which can be exploited to read files, communicate with external hosts, exfiltrate data, or cause a Denial of Service (DoS). + +Vulnerable code example: + +[source,java] +---- +import javax.servlet.http.HttpServletRequest; +import javax.xml.parsers.SAXParserFactory; +import org.xml.sax.InputSource; +import org.xml.sax.XMLReader; + +public class XmlParser { + public void parseXml(HttpServletRequest request) { + String input = request.getParameter("xml"); // User-supplied XML input + SAXParserFactory spf = SAXParserFactory.newInstance(); + try { + XMLReader xmlReader = spf.newSAXParser().getXMLReader(); + xmlReader.parse(new InputSource(new StringReader(input))); + } catch (Exception e) { + // Exception handling + } + } +} +---- + +In the above code, the `HttpServletRequest` object `request` is used to obtain user-supplied XML input. This input is then parsed using the `SAXParserFactory` and `XMLReader` classes. However, there is no proper restriction of XML external entity references, allowing potential XXE vulnerabilities. + +=== Fix - Buildtime + +To fix this issue, it is recommended to configure the `SAXParser` to disable DTD doctypes. This can be done by setting the feature `http://apache.org/xml/features/disallow-doctype-decl` to `true` when creating the `SAXParser` instance. + +Secure code example: + +[source,java] +---- +import javax.servlet.http.HttpServletRequest; +import javax.xml.parsers.SAXParserFactory; +import org.xml.sax.InputSource; +import org.xml.sax.XMLReader; + +public class XmlParser { + public void parseXml(HttpServletRequest request) { + String input = request.getParameter("xml"); // User-supplied XML input + SAXParserFactory spf = SAXParserFactory.newInstance(); + try { + spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); + XMLReader xmlReader = spf.newSAXParser().getXMLReader(); + xmlReader.parse(new InputSource(new StringReader(input))); + } catch (Exception e) { + // Exception handling + } + } +} +---- + +In the above code, the `SAXParserFactory` instance `spf` is configured to disable DTD doctypes by setting the feature `http://apache.org/xml/features/disallow-doctype-decl` to `true`. This ensures that the XML parser is protected against the majority of XXE attacks by disallowing the use of external entities. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-128.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-128.adoc new file mode 100644 index 000000000..f61eb8e0e --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-128.adoc @@ -0,0 +1,63 @@ + +== Improper restriction of XML external entity reference ('XXE') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_128 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/611.html[CWE-611: Improper Restriction of XML External Entity Reference] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +This policy detects improper restriction of XML external entity reference (XXE) vulnerabilities in Java code. XXE vulnerabilities can lead to data exfiltration or denial of service attacks. In this case, the policy looks for code patterns that read XML input from an untrusted source and do not disable the "DOCTYPE" feature or the support for external entities in the XML parser configuration. + +Vulnerable code example: + +[source,java] +---- +XMLInputFactory factory = XMLInputFactory.newFactory(); +XMLStreamReader reader = factory.createXMLStreamReader(request.getInputStream()); +---- + +In the above code, the XMLStreamReader is created without disabling the support for external entities or the "DOCTYPE" feature. This can allow an attacker to exploit XXE vulnerabilities. + +=== Fix - Buildtime + +To fix this issue, you should configure the XML parser to disable support for external entities and the "DOCTYPE" feature. Additionally, set the IS_SUPPORTING_EXTERNAL_ENTITIES and SUPPORT_DTD properties of the XMLInputFactory to false. + +Secure code example: + +[source,java] +---- +XMLInputFactory factory = XMLInputFactory.newFactory(); +factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false); +factory.setProperty(XMLInputFactory.SUPPORT_DTD, false); +XMLStreamReader reader = factory.createXMLStreamReader(request.getInputStream()); +---- + +In the secure version of the code, the XMLInputFactory is configured to disable the support for external entities and the "DOCTYPE" feature. This prevents XXE vulnerabilities by restricting the access to external entities. + + + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-129.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-129.adoc new file mode 100644 index 000000000..8dfd13e3f --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-129.adoc @@ -0,0 +1,62 @@ + +== Improper validation of certificate with host mismatch + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_129 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/297.html[CWE-297: Improper Validation of Certificate with Host Mismatch] + +|OWASP Categories +|https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[A07:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +This policy detects when the Apache Commons Mail client is used without enabling TLS server identity validation. Without server identity validation, there is a risk that an attacker in between the application and the target host could intercept sensitive information or transmit malicious data. + +Vulnerable code example: + +[source,java] +---- +Email email = new HtmlEmail(); +email.setSSLOnConnect(true); +email.send(); +---- + +In the above code, the `setSSLOnConnect(true)` method enables TLS for the email connection, but the `setSSLCheckServerIdentity(true)` method is not called to validate the server's identity. This leaves the application vulnerable to "Man-in-the-Middle" attacks. + +=== Fix - Buildtime + +To fix the issue, you need to enable server identity validation by calling the `setSSLCheckServerIdentity(true)` method on the email object. + +Secure code example: + +[source,java] +---- +Email email = new HtmlEmail(); +email.setSSLOnConnect(true); +email.setSSLCheckServerIdentity(true); +email.send(); +---- + +In the secure code, the `setSSLCheckServerIdentity(true)` method is called, which ensures that the server's identity is validated before sending the email. This mitigates the risk of interception or data tampering by an attacker. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-13.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-13.adoc new file mode 100644 index 000000000..f1ca9ddc2 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-13.adoc @@ -0,0 +1,79 @@ +== Unsafe custom MessageDigest is implemented + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_13 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures[A02:2021 - Cryptographic Failures] + +|=== + + + +=== Description + + +Flag any custom classes that extend the `java.security.MessageDigest` class. `MessageDigest` is a Java class used for calculating message digests, also known as checksums or cryptographic hash functions. By extending `MessageDigest`, a developer could be creating a custom cryptographic hash function, which is generally considered error-prone and a bad practice. + +Cryptography is a complex field and implementing a secure and reliable cryptographic hash function requires specific expertise. Improperly implemented hash functions can have vulnerabilities that can be exploited, leading to significant security risks. + +Example of violating code: + +[source,java] +---- +import java.security.MessageDigest; + +public class CustomDigest extends MessageDigest { + public CustomDigest() { + super("CustomDigest"); + } + + // ... custom implementation ... +} +---- + +In the example above, a custom `MessageDigest` is being created, which would be flagged. + +=== Fix - Buildtime + +To fix this issue, you should use a standard, widely accepted and tested cryptographic hash function instead of creating a custom one. The National Institute of Standards and Technology (NIST) recommends the use of SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256. + +Example of fixed code: + +[source,java] +---- +import java.security.MessageDigest; +import java.security.NoSuchAlgorithmException; + +public class Main { + public static void main(String[] args) throws NoSuchAlgorithmException { + MessageDigest digest = MessageDigest.getInstance("SHA-256"); + + // ... usage of standard SHA-256 MessageDigest ... + } +} +---- + +In the fixed code, instead of creating a custom `MessageDigest`, the code uses the built-in `SHA-256` MessageDigest provided by Java's `java.security` package, which is a secure and tested cryptographic hash function. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-130.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-130.adoc new file mode 100644 index 000000000..6d928fb60 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-130.adoc @@ -0,0 +1,59 @@ + +== Inadequate encryption strength + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_130 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/326.html[CWE-326: Inadequate Encryption Strength] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects when an application is generating an RSA key with encryption strength less than the recommended 2048 bits. The use of RSA keys with inadequate encryption strength can leave the application vulnerable to attacks and compromise the confidentiality and integrity of sensitive data. + +Vulnerable code example: + +[source,java] +---- +KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA"); +keyPairGenerator.initialize(1024, new SecureRandom()); +---- + +The above code is vulnerable because it generates an RSA key with encryption strength of 1024 bits, which is less than the recommended 2048 bits. This encryption strength is no longer considered secure and can be easily compromised by attackers. + +=== Fix - Buildtime + +To fix this issue, the encryption strength of the RSA key should be increased to at least 2048 bits. + +Secure code example: + +[source,java] +---- +KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA"); +keyPairGenerator.initialize(2048, new SecureRandom()); +---- + +The above secure code increases the encryption strength of the RSA key to 2048 bits. This ensures that the key is more secure and less susceptible to attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-131.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-131.adoc new file mode 100644 index 000000000..31c5ed4d0 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-131.adoc @@ -0,0 +1,59 @@ + +== Inadequate encryption strength + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_131 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/326.html[CWE-326: Inadequate Encryption Strength] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects when an application enables insecure TLS protocol versions. The recommended TLS protocol versions that should be allowed are TLSv1.2, TLSv1.3, DTLSv1.2, and DTLSv1.3. Older versions such as TLSv1.0 should be disallowed to mitigate potential security risks. + +Vulnerable code example: + +[source,java] +---- +SSLContext context = SSLContext.getInstance("TLSv1.0"); +context.createSSLEngine().setEnabledProtocols(new String[]{"TLSv1.0"}); +---- + +The above code example is vulnerable because it enables the insecure TLSv1.0 protocol version. + +=== Fix - Buildtime + +To fix the issue, the code should be updated to enforce TLS 1.2 as the minimum protocol version and disallow older versions. + +Secure code example: + +[source,java] +---- +SSLContext context = SSLContext.getInstance("TLSv1.2"); +context.createSSLEngine().setEnabledProtocols(new String[]{"TLSv1.2", "TLSv1.3", "DTLSv1.2", "DTLSv1.3"}); +---- + +The above code example is no longer vulnerable as it enforces TLS 1.2 as the minimum protocol version and allows only secure versions (TLSv1.2, TLSv1.3, DTLSv1.2, DTLSv1.3). + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-132.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-132.adoc new file mode 100644 index 000000000..5e39ebda0 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-132.adoc @@ -0,0 +1,57 @@ + +== Inadequate encryption strength + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_132 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/326.html[CWE-326: Inadequate Encryption Strength] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects instances where the network communications for Hazelcast is configured to use a deprecated symmetric cipher, leading to inadequate encryption strength. + +Vulnerable code example: + +[source,java] +---- +NC.setSymmetricEncryptionConfig(SEC); +---- + +The code above sets the symmetric encryption configuration for the network communications in Hazelcast. However, it uses a deprecated symmetric cipher, which is considered to have inadequate encryption strength. + +=== Fix - Buildtime + +To fix the issue, you should consider using TLS/SSL when establishing communications across the Hazelcast cluster, instead of the deprecated symmetric cipher. + +Secure code example: + +[source,java] +---- +NC.setSSLConfig(SSL); +---- + +By setting the SSL configuration (using TLS/SSL) for the network communications in Hazelcast, you ensure a stronger and more secure encryption mechanism. This eliminates the use of the deprecated symmetric cipher and improves the encryption strength. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-133.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-133.adoc new file mode 100644 index 000000000..0a391a4bc --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-133.adoc @@ -0,0 +1,61 @@ + +== Incorrect behavior order: validate before canonicalize + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_133 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/180.html[CWE-180: Incorrect Behavior Order: Validate Before Canonicalize] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects an incorrect behavior order where input validation is performed after the Unicode normalization process. This can be a security vulnerability as an attacker may try to exploit the normalization process. + +Vulnerable code example: + +[source,java] +---- +String input = request.getParameter("input"); +Pattern pattern = Pattern.compile("pattern"); +Matcher matcher = pattern.matcher(input); +String normalizedInput = Normalizer.normalize(input, Normalizer.Form.NFC); +---- +In the above code example, the input is first used in a regular expression pattern match and then the `Normalizer.normalize` function is called to perform Unicode normalization. However, the validation of the input occurs after the normalization process, which can allow attackers to manipulate the input and bypass the validation. + +=== Fix - Buildtime + +To fix this issue, the Unicode normalization should be performed before any validation of the input. + +Secure code example: + +[source,java] +---- +String input = request.getParameter("input"); +String normalizedInput = Normalizer.normalize(input, Normalizer.Form.NFC); +Pattern pattern = Pattern.compile("pattern"); +Matcher matcher = pattern.matcher(normalizedInput); +---- +In the secure code example, the input is first normalized using `Normalizer.normalize` function before being used in the regular expression pattern match. This ensures that the input is validated based on the normalized version, preventing potential exploitations of the normalization process. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-134.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-134.adoc new file mode 100644 index 000000000..ff9fa5a7d --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-134.adoc @@ -0,0 +1,59 @@ + +== Incorrect permission assignment for critical resource + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_134 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/732.html[CWE-732: Incorrect Permission Assignment for Critical Resource] + +|OWASP Categories +| + +|=== + +=== Description + +This SAST policy detects instances where the application sets file permissions to overly permissive values, which can lead to security vulnerabilities. + +Vulnerable code example: + +[source,java] +---- +PosixFilePermissions.fromString("rwxrwxrwx"); +Files.setPosixFilePermissions(file, perms); +---- + +In the above code, the file permissions are set to "rwxrwxrwx", which allows read, write, and execute access for all users. This is overly permissive and can potentially allow unauthorized access to the file. + +=== Fix - Buildtime + +To fix this issue, the file permissions should be set to more restrictive values. + +Secure code example: + +[source,java] +---- +PosixFilePermissions.fromString("rw-------"); +Files.setPosixFilePermissions(file, perms); +---- + +In the secure code example, the file permissions are set to "rw-------", which allows read and write access only for the application user. This ensures that only the application user has access to the file, reducing the risk of unauthorized access. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-135.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-135.adoc new file mode 100644 index 000000000..6287d0326 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-135.adoc @@ -0,0 +1,65 @@ + +== Incorrect Permission Assignment for Critical Resource + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_135 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/732.html[CWE-732: Incorrect Permission Assignment for Critical Resource] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects instances where overly permissive file permissions are assigned to critical resources in Java code. These file permissions may allow unauthorized users or processes to read, write, or execute the critical resource. + +Vulnerable code example: + +[source,java] +---- +Path path = Paths.get("path/to/critical/resource.txt"); +Set permissions = new HashSet<>(); +permissions.add(PosixFilePermission.OTHERS_READ); +permissions.add(PosixFilePermission.OTHERS_WRITE); +Files.setPosixFilePermissions(path, permissions); +---- + +The above code assigns read and write permissions to the "others" group for a critical resource. This means that any other user or process on the system can read or modify the contents of the critical resource, which can lead to unauthorized access or data manipulation. + +=== Fix - Buildtime + +To fix the issue, you should assign the appropriate file permissions for the critical resource. Only necessary permissions should be granted to authorized users or processes. + +Secure code example: + +[source,java] +---- +Path path = Paths.get("path/to/critical/resource.txt"); +Set permissions = new HashSet<>(); +permissions.add(PosixFilePermission.OWNER_READ); +permissions.add(PosixFilePermission.OWNER_WRITE); +Files.setPosixFilePermissions(path, permissions); +---- + +In the secure code example, we assign read and write permissions to the owner of the critical resource. This restricts access to only the owner, ensuring that unauthorized users or processes cannot read or modify the critical resource. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-136.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-136.adoc new file mode 100644 index 000000000..6778d42f4 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-136.adoc @@ -0,0 +1,58 @@ + +== Incorrect type conversion or cast + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_136 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/704.html[CWE-704: Incorrect Type Conversion or Cast] + +|OWASP Categories +| + +|=== + +=== Description + +This SAST policy detects the usage of an incorrect type conversion or cast in Java code. In particular, it looks for code that uses `Integer.toHexString` on a digest array buffer, which can lead to incorrect values. + +Vulnerable code example: + +[source,java] +---- +byte[] digest = MD.digest(data); +String hexString = Integer.toHexString(digest); +---- + +In the above code, the `Integer.toHexString` method is being used to convert a byte array (digest) to a hex string. However, this can lead to incorrect values. + +=== Fix - Buildtime + +To fix this issue, you should consider using the `HexFormat` object introduced in Java 17. For older Java applications, you can use the `javax.xml.bind.DatatypeConverter`. + +Secure code example: + +[source,java] +---- +String hexString = HexFormat.of(digest).toHexString(); +---- + +In the fixed code, the `HexFormat` object is used to convert the digest byte array to a hex string. This ensures the correct conversion and eliminates the vulnerability. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-137.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-137.adoc new file mode 100644 index 000000000..febcfb388 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-137.adoc @@ -0,0 +1,71 @@ + +== Information exposure through an error message + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_137 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/209.html[CWE-209: Generation of Error Message Containing Sensitive Information] + +|OWASP Categories +|https://owasp.org/Top10/A04_2021-Insecure_Design/[A04:2021 - Insecure Design] + +|=== + +=== Description + +This policy detects instances where an application prints stack trace information to the default system output. Printing stack trace data to the default system output can expose sensitive information to potential attackers. + +Vulnerable code example: + +[source,java] +---- +try { + // Some code +} +catch(Exception e) { + // Some code + e.printStackTrace(); + // Some code +} +---- + +In the above code, the exception stack trace is printed to the console using the `printStackTrace()` method. This can reveal sensitive information about the application's internal workings and potentially aid attackers in exploiting vulnerabilities. + +=== Fix - Buildtime + +To fix this issue, it is recommended to log the stack trace information using a secure logging framework. This ensures that sensitive information is not leaked to the default system output. + +Secure code example: + +[source,java] +---- +try { + // Some code +} +catch(Exception e) { + // Some code + logger.error("An error occurred", e); // Logging the error with a secure logging framework + // Some code +} +---- + +In the secure code example, the stack trace is logged using a secure logging framework (represented by `logger`). This ensures that sensitive information is stored securely in the log files and not exposed to the default system output. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-138.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-138.adoc new file mode 100644 index 000000000..2112ae496 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-138.adoc @@ -0,0 +1,72 @@ + +== Information exposure through an error message + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_138 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/209.html[CWE-209: Generation of Error Message Containing Sensitive Information] + +|OWASP Categories +|https://owasp.org/Top10/A04_2021-Insecure_Design/[A04:2021 - Insecure Design] + +|=== + +=== Description + +This policy detects when an application prints stack trace information to the default system output, which can lead to information exposure. Stack trace data may contain sensitive information, such as file paths, database connection details, or other system-specific information. It is recommended to log this information using a secure logging framework and protect the log files with proper operating system permission levels. + +Vulnerable code example: + +[source,java] +---- +try { + // code that may throw an exception +} +catch(Exception e) { + e.printStackTrace(); +} +---- + +In the above code, the exception's stack trace is printed to the default system output using the `printStackTrace()` method. This can leak sensitive information to the attacker or provide valuable clues about the system's internals. + +=== Fix - Buildtime + +To fix this issue, the application should use a secure logging framework instead of directly printing the stack trace to the default system output. Additionally, access to the log files should be restricted by setting proper operating system permission levels. + +Secure code example: + +[source,java] +---- +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +private static final Logger LOGGER = LoggerFactory.getLogger(YourClass.class); + +try { + // code that may throw an exception +} +catch(Exception e) { + LOGGER.error("An error occurred", e); +} +---- + +In the secure code example, the SLF4J logging framework is used to log the error message and the exception stack trace. By using a logging framework, the sensitive information is not exposed to the default system output. Instead, it is logged in a controlled manner, allowing for proper configuration and secure handling of log files. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-139.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-139.adoc new file mode 100644 index 000000000..a7738a0f4 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-139.adoc @@ -0,0 +1,59 @@ + +== Missing authentication for critical function (database) + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_139 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/306.html[CWE-306: Missing Authentication for Critical Function] + +|OWASP Categories +|https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[A07:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +This SAST policy detects the presence of missing authentication for a critical function (database) in Java code. It looks for two specific patterns: +1. `DriverManager.getConnection($URI, $USR, "");` +2. `$DS.setPassword("")` + +Vulnerable code example: + +[source,java] +---- +DriverManager.getConnection("jdbc:mysql://localhost:3306/myDB", "root", ""); +---- + +The above code is vulnerable because it establishes a connection to a MySQL database without providing any authentication credentials. This means that anyone with access to the code can execute queries on the database without authentication. + +=== Fix - Buildtime + +To fix this issue, proper authentication should be implemented when communicating with the database server. This can be done by providing valid username and password credentials when establishing the connection. + +Secure code example: + +[source,java] +---- +DriverManager.getConnection("jdbc:mysql://localhost:3306/myDB", "root", "password"); +---- + +In the secure version of the code, a secure password (e.g., "password") is provided as an argument to the `getConnection` method. This ensures that only authorized users with the correct credentials can access and execute queries on the database. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-14.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-14.adoc new file mode 100644 index 000000000..8fc9da75b --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-14.adoc @@ -0,0 +1,74 @@ +== Unsafe use of Cross-Origin Resource Sharing (CORS) + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_14 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/942.html[CWE-942: Permissive Cross-domain Policy with Untrusted Domains] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + + + +=== Description + + +This policy identifies configurations where Cross-Origin Resource Sharing (CORS) is enabled on a server. CORS is a mechanism that allows resources on a web page to be requested from another domain outside the domain from which the resource originated. This is done using HTTP headers, in particular, the `Access-Control-Allow-Origin` header. A permissive configuration (where the value of this header is set to "*") can pose a risk as it allows any domain to access the resource, potentially leading to various security issues such as Cross-Site Scripting (XSS) and data theft. + +Example of violating code: + +[source,java] +---- +import javax.servlet.http.HttpServletResponse; + +public class Main { + public static void main(String[] args) { + HttpServletResponse response = new HttpServletResponse(); + response.setHeader("Access-Control-Allow-Origin", "*"); + } +} +---- + +In this example, the `Access-Control-Allow-Origin` header is set to "*", indicating that any domain can access the resources. + +=== Fix - Buildtime + +To fix this issue, you should limit the access to specific, trusted domains, instead of allowing all domains. You can do this by specifying the trusted domains instead of "*". + +Example of fixed code: + +[source,java] +---- +import javax.servlet.http.HttpServletResponse; + +public class Main { + public static void main(String[] args) { + HttpServletResponse response = new HttpServletResponse(); + response.setHeader("Access-Control-Allow-Origin", "https://trusteddomain.com"); + } +} +---- + +In the fixed code, only "https://trusteddomain.com" is granted access to the resources, rather than any domain. Please note that in a real scenario, the `HttpServletResponse` would not be directly instantiated with `new HttpServletResponse()`, but would be provided by the servlet container (e.g., in the `doGet` or `doPost` method of a `HttpServlet`). + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-140.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-140.adoc new file mode 100644 index 000000000..ad5350f98 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-140.adoc @@ -0,0 +1,67 @@ + +== Missing authentication for critical function (LDAP) + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_140 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/306.html[CWE-306: Missing Authentication for Critical Function] + +|OWASP Categories +|https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[A07:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +This policy detects when an application does not provide authentication when communicating with an LDAP server. It is important to have authentication in place to ensure that only authorized users can execute queries on the LDAP server. + +Vulnerable code example: + +[source,java] +---- +Hashtable ENV = new Hashtable<>(); +ENV.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); +ENV.put(Context.PROVIDER_URL, "ldap://example.com:389"); +ENV.put(Context.SECURITY_AUTHENTICATION, "none"); +InitialContext ctx = new InitialContext(ENV); +---- + +The above code does not provide any authentication when communicating with the LDAP server. This means that anyone can execute queries on the server without any form of authentication, which can lead to unauthorized access and potential security breaches. + +=== Fix - Buildtime + +To fix the issue, authentication should be added when communicating with the LDAP server. This can be achieved by providing valid credentials through the `Context.SECURITY_PRINCIPAL` and `Context.SECURITY_CREDENTIALS` properties. + +Secure code example: + +[source,java] +---- +Hashtable ENV = new Hashtable<>(); +ENV.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); +ENV.put(Context.PROVIDER_URL, "ldap://example.com:389"); +ENV.put(Context.SECURITY_AUTHENTICATION, "simple"); +ENV.put(Context.SECURITY_PRINCIPAL, "cn=admin,dc=example,dc=com"); +ENV.put(Context.SECURITY_CREDENTIALS, "password"); +InitialContext ctx = new InitialContext(ENV); +---- + +The updated code now specifies that authentication is required (`Context.SECURITY_AUTHENTICATION = "simple"`) and provides valid credentials (`Context.SECURITY_PRINCIPAL` and `Context.SECURITY_CREDENTIALS`) for accessing the LDAP server. This ensures that only authorized users with valid credentials can execute queries on the server, reducing the risk of unauthorized access. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-141.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-141.adoc new file mode 100644 index 000000000..cf0833cb6 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-141.adoc @@ -0,0 +1,63 @@ + +== Permissive Cross-domain Policy with Untrusted Domains + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_141 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/942.html[CWE-942: Permissive Cross-domain Policy with Untrusted Domains] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +This policy detects the usage of a permissive cross-domain policy with untrusted domains. It verifies if the code contains a vulnerable pattern in which the HttpServletRequest object is used to obtain a parameter value, and the HttpServletResponse object is used to set the Access-Control-Allow-Origin header. + +Vulnerable code example: + +[source,java] +---- +String origin = request.getParameter("origin"); +response.setHeader("Access-Control-Allow-Origin", origin); +---- + +The above code is vulnerable because it does not properly validate and sanitize the "origin" parameter obtained from the HttpServletRequest object. This lack of validation allows an attacker to provide a malicious value for the "origin", potentially enabling cross-domain requests from untrusted domains. + +=== Fix - Buildtime + +To fix this issue, the code should properly validate and sanitize the "origin" parameter before setting it as the value for the Access-Control-Allow-Origin header. This can be done by using a whitelist of trusted domains and ensuring that the provided "origin" value is present in the whitelist. + +Secure code example: + +[source,java] +---- +String origin = request.getParameter("origin"); +if (isValidOrigin(origin)) { + response.setHeader("Access-Control-Allow-Origin", origin); +} else { + response.setHeader("Access-Control-Allow-Origin", "https://trusted-domain.com"); +} +---- + +In the secure version of the code, the "origin" parameter is checked against a list of trusted domains using the isValidOrigin() function. If the "origin" is found in the whitelist, it is set as the value for the Access-Control-Allow-Origin header. Otherwise, a default trusted domain is used instead. This ensures that only trusted domains are allowed for cross-domain access, mitigating the risk of data theft and spoofing. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-142.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-142.adoc new file mode 100644 index 000000000..9ae23b198 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-142.adoc @@ -0,0 +1,62 @@ + +== Sensitive Cookie in HTTPS Session Without 'Secure' Attribute + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_142 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/614.html[CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +This SAST policy detects the use of a sensitive cookie in an HTTPS session without the 'Secure' attribute set. This vulnerability can allow an attacker to intercept the sensitive information stored in the cookie if the connection is not secure. + +Vulnerable code example: + +[source,java] +---- +Cookie userCookie = new Cookie("username", "admin"); +response.addCookie(userCookie); +---- + +In the above code, a sensitive cookie called "username" is created without setting the 'Secure' attribute. This means that the cookie can be transmitted over an insecure connection, making it vulnerable to interception by an attacker. + +=== Fix - Buildtime + +To fix this issue, the 'Secure' attribute should be set when creating the cookie. + +Secure code example: + +[source,java] +---- +Cookie userCookie = new Cookie("username", "admin"); +userCookie.setSecure(true); +response.addCookie(userCookie); +---- + +In the secure code example, the 'Secure' attribute is set to true using the `setSecure(true)` method before adding the cookie to the response. This ensures that the cookie will only be transmitted over a secure connection. + +By setting the 'Secure' attribute, the sensitive cookie can only be transmitted over HTTPS, making it more secure and protecting the sensitive information from interception by attackers. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-143.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-143.adoc new file mode 100644 index 000000000..32e813f3c --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-143.adoc @@ -0,0 +1,62 @@ + +== Sensitive Cookie in HTTPS Session Without 'Secure' Attribute + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_143 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/614.html[CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +This policy detects the presence of a sensitive cookie in an HTTPS session that does not have the 'Secure' attribute set. Storing sensitive data in a persistent cookie without the 'Secure' attribute can lead to a breach of confidentiality or account compromise. + +Vulnerable code example: + +[source,java] +---- +Cookie cookie = new Cookie("sessionId", sessionId); +cookie.setMaxAge(3600); +response.addCookie(cookie); +---- + +The above code is vulnerable because it creates a cookie named "sessionId" and sets its max age to 3600 seconds, but it does not set the 'Secure' attribute. Without the 'Secure' attribute, the cookie can be sent over an insecure HTTP connection, potentially exposing sensitive data. + +=== Fix - Buildtime + +To fix the issue, the 'Secure' attribute should be set when creating the cookie. This ensures that the cookie will only be sent over secure HTTPS connections. + +Secure code example: + +[source,java] +---- +Cookie cookie = new Cookie("sessionId", sessionId); +cookie.setMaxAge(3600); +cookie.setSecure(true); +response.addCookie(cookie); +---- + +The above code is no longer vulnerable because it sets the 'Secure' attribute to true when creating the cookie. This ensures that the cookie will only be sent over secure HTTPS connections, mitigating the risk of data exposure. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-144.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-144.adoc new file mode 100644 index 000000000..ef018c947 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-144.adoc @@ -0,0 +1,58 @@ + +== Sensitive cookie without 'HttpOnly' flag + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_144 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/1004.html[CWE-1004: Sensitive Cookie Without 'HttpOnly' Flag] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +This policy detects sensitive cookies that are created without the 'HttpOnly' flag set. When the 'HttpOnly' flag is set to true, it prevents client-side JavaScript from accessing the cookie value. This provides protection against cross-site scripting (XSS) attacks, as malicious scripts will not be able to read the cookie values. + +Vulnerable code example: + +[source,java] +---- +Cookie sessionCookie = new Cookie("session", "12345"); +---- + +In the above code, a cookie named "session" is created without setting the 'HttpOnly' flag to true. This makes it vulnerable to XSS attacks, as client-side scripts can access the value of this cookie using `document.cookie`. + +=== Fix - Buildtime + +To fix this issue, set the 'HttpOnly' flag of the cookie to true. + +Secure code example: + +[source,java] +---- +Cookie sessionCookie = new Cookie("session", "12345"); +sessionCookie.setHttpOnly(true); +---- + +In the secure version of the code, the 'HttpOnly' flag of the cookie is set to true using the `setHttpOnly(true)` method. This ensures that the cookie value cannot be accessed by client-side JavaScript, providing protection against XSS attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-145.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-145.adoc new file mode 100644 index 000000000..c86e9e72b --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-145.adoc @@ -0,0 +1,60 @@ + +== Server-Side Request Forgery (SSRF) + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_145 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/918.html[CWE-918: Server-Side Request Forgery (SSRF)] + +|OWASP Categories +|https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/[A10:2021 - Server-Side Request Forgery (SSRF)] + +|=== + +=== Description + +This SAST policy detects potential Server-Side Request Forgery (SSRF) vulnerabilities in Java code. SSRF exploits backend systems that initiate requests to third parties. If user input is used in constructing or sending these requests, an attacker could supply malicious data to force the request to other systems or modify request data to cause unwanted actions. + +Vulnerable code example: + +[source,java] +---- +String url = request.getParameter("url"); +new URL(url); +---- + +The above code is vulnerable because it directly uses user input (retrieved from the "url" parameter) in constructing the URL object. An attacker could maliciously supply a different URL, potentially targeting internal or restricted systems. + +=== Fix - Buildtime + +To fix this issue, it is important to ensure that user input is properly validated and sanitized before using it to construct URLs or URIs for making requests to third-party systems. + +Secure code example: + +[source,java] +---- +String url = request.getParameter("url"); +String validatedUrl = validateAndSanitizeUrl(url); +new URL(validatedUrl); +---- + +In the secure code example, the user input is first passed through a validateAndSanitizeUrl() method, which applies appropriate validation and sanitization techniques to ensure the URL is safe before constructing the URL object. This helps prevent any malicious or unauthorized access to sensitive systems. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-147.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-147.adoc new file mode 100644 index 000000000..8974ed5bc --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-147.adoc @@ -0,0 +1,63 @@ + +== URL Redirection to Untrusted Site ('Open Redirect') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_147 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/601.html[CWE-601: URL Redirection to Untrusted Site ('Open Redirect')] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This SAST policy detects the URL Redirection to Untrusted Site vulnerability. This vulnerability occurs when an application redirects a user to a destination URL that is specified by a user-supplied parameter that is not properly validated. This can be exploited by attackers to perform phishing attacks. + +Vulnerable code example: + +[source,java] +---- +String redirectUrl = request.getParameter("url"); +response.sendRedirect(redirectUrl); +---- + +In the above code example, the application retrieves the value of the "url" parameter from the user's request and directly uses it as the destination URL for redirection. This can allow an attacker to craft a malicious URL and redirect the user to an untrusted site. + +=== Fix - Buildtime + +To fix this issue, it is important to validate and sanitize any user-supplied URL parameters before using them for redirection. + +Secure code example: + +[source,java] +---- +String redirectUrl = request.getParameter("url"); +if (isValidUrl(redirectUrl)) { + response.sendRedirect(redirectUrl); +} else { + // Handle invalid URL error +} +---- + +In the secure code example, the application first checks if the user-supplied URL is valid using a custom validation function (isValidUrl). Only if the URL passes the validation, it is then used for redirection. This ensures that only trusted URLs are used for redirection and prevents attackers from manipulating the URL parameter to redirect users to untrusted sites. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-148.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-148.adoc new file mode 100644 index 000000000..b1952e72c --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-148.adoc @@ -0,0 +1,57 @@ + +== Use of a broken or risky cryptographic algorithm + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_148 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects the use of a broken or risky cryptographic algorithm in Java code. The use of these algorithms can introduce vulnerabilities that could be exploited by attackers to tamper with ciphertext and compromise the security of the system. + +Vulnerable code example: + +[source,java] +---- +Cipher.getInstance("DES"); +---- + +The above code example uses the "DES" cryptographic algorithm, which is considered weak and vulnerable to attack. It does not provide built-in message integrity, making it easier for an adversary to tamper with the ciphertext and potentially decrypt the data. + +=== Fix - Buildtime + +To address this issue, you should use a more secure cryptographic algorithm that has built-in message integrity. For example, "ChaCha20Poly1305" or "AES-256-GCM" are recommended algorithms. + +Secure code example: + +[source,java] +---- +Cipher.getInstance("ChaCha20Poly1305"); +---- + +The above code example demonstrates the use of the "ChaCha20Poly1305" algorithm, which provides both encryption and message integrity. By using this algorithm, the ciphertext is protected against tampering, ensuring the security of the encrypted data. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-149.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-149.adoc new file mode 100644 index 000000000..3f403993a --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-149.adoc @@ -0,0 +1,57 @@ + +== Use of a broken or risky cryptographic algorithm (SHA1/MD5) + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_149 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects the use of insecure or risky cryptographic algorithms, specifically MD5 and SHA1. Both MD5 and SHA1 hash algorithms have been found to be vulnerable to producing collisions, meaning that two different values can lead to the same hash value. The use of these algorithms weakens the security of the application. + +Vulnerable code example: + +[source,java] +---- +MessageDigest.getInstance("SHA1") +---- + +The above code is vulnerable because it uses the SHA1 algorithm, which is considered insecure and risk-prone due to its vulnerability to collisions. + +=== Fix - Buildtime + +To fix the issue, you should use a secure cryptographic algorithm instead. For example: + +Secure code example: + +[source,java] +---- +MessageDigest.getInstance("SHA-256") +---- + +The above code is no longer vulnerable because it uses the more secure SHA-256 algorithm instead of SHA1. SHA-256 is not vulnerable to collision attacks and offers better security. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-15.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-15.adoc new file mode 100644 index 000000000..b8feb9482 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-15.adoc @@ -0,0 +1,75 @@ +== Unsafe use of hazelcast symmetric encryption + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_15 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/326.html[CWE-326: Inadequate Encryption Strength] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + + + +=== Description + + +This policy targets the use of Hazelcast's symmetric encryption configuration. Hazelcast is a widely used in-memory data grid, and its network communication can be secured using different configurations. Symmetric encryption, where the same key is used for both encryption and decryption, is one such method. + +However, symmetric encryption protocols such as DES or Blowfish do not provide data integrity or secure authentication, and can be vulnerable to various types of cryptographic attacks. Asymmetric encryption, where different keys are used for encryption and decryption, is generally more secure and therefore recommended for sensitive data. + +An example of violating code could be: + +[source,java] +---- +import com.hazelcast.config.*; + +public class Main { + public static void main(String[] args) { + SymmetricEncryptionConfig sec = new SymmetricEncryptionConfig(); + // Other configuration + } +} +---- + +In this example, a new instance of `SymmetricEncryptionConfig` is created, indicating that symmetric encryption is being used for Hazelcast's network communication. + +=== Fix - Buildtime + +To fix this, you could use Hazelcast's SSL/TLS configuration instead, which provides more secure encryption: + +[source,java] +---- +import com.hazelcast.config.*; + +public class Main { + public static void main(String[] args) { + SSLConfig sslConfig = new SSLConfig(); + sslConfig.setEnabled(true); + // Other configuration + } +} +---- + +In this fixed code, an instance of `SSLConfig` is created and enabled, meaning that SSL/TLS (an asymmetric encryption protocol) will be used for Hazelcast's network communication instead of symmetric encryption. Please consult Hazelcast's official documentation for more information about correctly configuring SSL/TLS. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-150.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-150.adoc new file mode 100644 index 000000000..a2335ce73 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-150.adoc @@ -0,0 +1,58 @@ + +== Use of externally-controlled format string + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_150 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/134.html[CWE-134: Use of Externally-Controlled Format String] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects the use of externally-controlled format strings in Java code. An externally-controlled format string is a format string that is provided by a user or from an external source. Manipulating format string parameters can potentially cause exceptions or data leaks based on the application's logic. + +Vulnerable code example: + +[source,java] +---- +String input = request.getParameter("input"); +String formatStr = "%" + input; +String output = String.format(formatStr, "some value"); +---- + +The above code is vulnerable because it takes user input from the "input" parameter and directly uses it in the format string without proper validation or sanitization. An attacker can manipulate the format string parameter, leading to unexpected behavior, such as format string vulnerabilities or information disclosure. + +=== Fix - Buildtime + +To fix this issue, never use user-supplied input directly in format strings. Instead, use hardcoded strings containing the required specifiers. Here is an example of secure code: + +[source,java] +---- +String formatStr = "%s"; // Assuming string format +String output = String.format(formatStr, "some value"); +---- + +In the secure code example, the format string is hardcoded as "%s" which specifies a string format. This eliminates the potential for user input to manipulate the format string parameter. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-151.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-151.adoc new file mode 100644 index 000000000..6617de997 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-151.adoc @@ -0,0 +1,57 @@ + +== Unencrypted payload with JWT + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_151 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This SAST policy detects the usage of unencrypted payloads with JSON Web Tokens (JWTs). + +Vulnerable code example: + +[source,java] +---- +com.auth0.jwt.algorithms.Algorithm.none() +---- + +The above code is vulnerable because it uses the `com.auth0.jwt.algorithms.Algorithm.none()` method to create a JWT algorithm that does not encrypt the payload. This means that the contents of the token can be easily read and manipulated by attackers. + +=== Fix - Buildtime + +To fix this issue, the payload of the JWT should be encrypted using a secure cryptographic algorithm. + +Secure code example: + +[source,java] +---- +com.auth0.jwt.algorithms.Algorithm.HMAC256("your-secret") +---- + +The above code is no longer vulnerable because it uses the `HMAC256` algorithm to encrypt the JWT payload with a secure secret key. This ensures that the payload is protected and cannot be easily tampered with by attackers. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-155.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-155.adoc new file mode 100644 index 000000000..e1801b038 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-155.adoc @@ -0,0 +1,59 @@ + +== Use of insufficiently random values + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_155 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/330.html[CWE-330: Use of Insufficiently Random Values] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects the use of insufficiently random values, which can expose cryptographic functions to be exploitable. It recommends using the `SecureRandom` class's `DRBG` instance when generating numbers for sensitive values such as tokens, nonces, and cryptographic keys. + +Vulnerable code example: + +[source,java] +---- +Random rand = new Random(); +int randomNumber = rand.nextInt(100); +---- + +The above code is vulnerable because it uses the `Random` class from Java's standard library to generate random numbers. The `Random` class uses a linear congruential formula to generate pseudo-random numbers, which can be predictable and easy to guess. This weak randomness can compromise the security of cryptographic functions and make them susceptible to attacks. + +=== Fix - Buildtime + +To fix the issue, it is recommended to use the `SecureRandom` class's `DRBG` (Deterministic Random Bit Generator) instance. + +Secure code example: + +[source,java] +---- +SecureRandom rand = new SecureRandom(); +int randomNumber = rand.nextInt(100); +---- + +The above code is no longer vulnerable because it uses the `SecureRandom` class, which provides a higher level of randomness by utilizing a cryptographic algorithm to generate random numbers. This improves the security of cryptographic functions that rely on these numbers and makes them less susceptible to attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-156.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-156.adoc new file mode 100644 index 000000000..a1fb46963 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-156.adoc @@ -0,0 +1,57 @@ + +== Use of RSA algorithm without OAEP + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_156 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/780.html[CWE-780: Use of RSA Algorithm without OAEP] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This SAST policy detects the use of the RSA algorithm without incorporating Optimal Asymmetric Encryption Padding (OAEP), making the algorithm vulnerable to chosen plaintext attacks. + +Vulnerable code example: + +[source,java] +---- +Cipher.getInstance("RSA/ECB/NoPadding"); +---- + +The above code is vulnerable because it uses the RSA algorithm without enabling padding. Without padding, the algorithm is susceptible to chosen plaintext attacks. + +=== Fix - Buildtime + +To fix the issue, you should enable OAEP mode by passing "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" to the `Cipher.getInstance` method. + +Secure code example: + +[source,java] +---- +Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); +---- + +The above code is no longer vulnerable because it incorporates OAEP padding, which provides additional security and protects against chosen plaintext attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-16.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-16.adoc new file mode 100644 index 000000000..1c0dac14a --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-16.adoc @@ -0,0 +1,73 @@ +== Cookie created without HttpOnly flag + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_16 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/1004.html[CWE-1004: Sensitive Cookie Without 'HttpOnly' Flag] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration[A05:2021 - Security Misconfiguration] + +|=== + + + +=== Description + + +This policy is targeting the creation of HTTP cookies without the "HttpOnly" flag in Java code. The HttpOnly flag is an important security feature that prevents client-side scripts from reading the contents of the cookie. When this flag is not set, it could potentially lead to disclosure of the cookie's contents in the event of a Cross-Site Scripting (XSS) attack. + +Here's an example of violating code: + +[source,java] +---- +import javax.servlet.http.Cookie; + +public class CookieHandler { + public void createCookie(String name, String value) { + Cookie cookie = new Cookie(name, value); + // Other code + } +} +---- + +In this example, a new cookie is created with a provided name and value, but the HttpOnly flag is not set. + +=== Fix - Buildtime + +The fix for this would be to call the `setHttpOnly` method on the cookie object with `true` as the argument, like so: + +[source,java] +---- +import javax.servlet.http.Cookie; + +public class CookieHandler { + public void createCookie(String name, String value) { + Cookie cookie = new Cookie(name, value); + cookie.setHttpOnly(true); + // Other code + } +} +---- + +This updated code sets the HttpOnly flag on the cookie, preventing it from being accessed by client-side scripts. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-162.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-162.adoc new file mode 100644 index 000000000..a3bccfc50 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-162.adoc @@ -0,0 +1,60 @@ + +== Permissive cross-domain policy with untrusted domains + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_162 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/942.html[CWE-942: Permissive Cross-domain Policy with Untrusted Domains] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +This SAST policy detects a potential vulnerability related to a permissive cross-domain policy with untrusted domains. The issue arises when the application allows user-supplied input into the value of the `Access-Control-Allow-Origin` response header. This header is part of the Cross-Origin Resource Sharing (CORS) specification and controls which domains can communicate with the server. By allowing user input to specify the allowed domains, an attacker could exploit a weakness in the server to force clients to send credentials (such as session identifiers) to the attacker's server. + +To successfully execute such an attack, the application would need to suffer from an additional vulnerability, such as Cross-Site Scripting (XSS). + +Vulnerable code example: + +[source, java] +``` +String userOrigin = request.getParameter("origin"); +response.setHeader("Access-Control-Allow-Origin", userOrigin); +``` + +In the above code, the value for the `Access-Control-Allow-Origin` header is taken directly from the user-supplied `origin` parameter without any validation or sanitization. This allows any domain specified by the user to be set as an allowed origin, potentially enabling cross-site scripting attacks. + +=== Fix - Buildtime + +To fix this issue, the application should not use user-supplied information when calling `setHeader` or `addHeader` for the `Access-Control-Allow-Origin` header's value. Instead, the allowed domain(s) should be hardcoded and referenced in a lookup. + +Secure code example: + +[source, java] +``` +response.setHeader("Access-Control-Allow-Origin", "https://example.com"); +``` + +In the secure version of the code, the `Access-Control-Allow-Origin` header is set to a specific trusted domain (`https://example.com` in this example), eliminating the use of user-supplied input. This prevents an attacker from manipulating the allowed domains and reduces the risk of potential security vulnerabilities. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-163.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-163.adoc new file mode 100644 index 000000000..8f9aac1c9 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-163.adoc @@ -0,0 +1,64 @@ + +== Improper neutralization of special elements in output used by a downstream component ('Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_163 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/74.html[CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects cases where XSLT translation is performed with potentially malicious input, which can lead to Injection vulnerabilities. Specifically, the policy looks for the use of `new FileInputStream()` or `getClass().getResourceAsStream()` methods to read files, in combination with XSLT transformation methods like `newTransformer()` or `transform()`. + +Vulnerable code example: + +[source,java] +---- +FileInputStream fis = new FileInputStream(userSuppliedFile); +TransformerFactory tf = TransformerFactory.newInstance(); +Transformer transformer = tf.newTransformer(userSuppliedXSL); +transformer.transform(xmlSource, result); +---- + +The above code is vulnerable because it reads a file (`userSuppliedFile`) using `FileInputStream`, which can allow an attacker to inject a path to a sensitive file on the server. The `userSuppliedXSL` is then used in XSLT transformation, potentially allowing the attacker to execute arbitrary XSL functions or perform XML entity attacks. + +=== Fix - Buildtime + +To fix this issue, it is recommended to avoid processing user-supplied XSL style sheets. If XSLT processing is absolutely necessary, ensure that the `FEATURE_SECURE_PROCESSING` feature is enabled prior to processing the XSLT. + +Secure code example: + +[source,java] +---- +InputStream xslInput = new ByteArrayInputStream(userSuppliedXSL.getBytes()); +TransformerFactory tf = TransformerFactory.newInstance(); +tf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); +Transformer transformer = tf.newTransformer(new StreamSource(xslInput)); +transformer.transform(xmlSource, result); +---- + +The secure code example avoids processing user-supplied XSL style sheets directly. Instead, it creates an `InputStream` from the `userSuppliedXSL` and enables the `FEATURE_SECURE_PROCESSING` feature on the `TransformerFactory` to ensure secure processing of the XSLT. This mitigates the risk of XSLT injection and XML entity attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-164.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-164.adoc new file mode 100644 index 000000000..cb361b054 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-164.adoc @@ -0,0 +1,69 @@ + +== Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_164 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/79.html[CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects instances where a custom cross-site scripting (XSS) filtering mechanism is implemented in a Java class that extends HttpServletRequestWrapper. It specifically looks for the "stripXSS" function being used. + +Vulnerable code example: + +[source,java] +---- +public class CustomRequestWrapper extends HttpServletRequestWrapper { + public String stripXSS(String value) { + // Custom XSS filtering logic + ... + } +} +---- + +The above code is vulnerable because it implements a custom XSS filtering mechanism instead of using standard sanitization functions. Custom filtering can often lead to incomplete or ineffective protection against XSS attacks. + +=== Fix - Buildtime + +To fix this issue, you should avoid using custom XSS filtering and instead use standard sanitization functions provided by frameworks or libraries. + +Secure code example: + +[source,java] +---- +import org.apache.commons.text.StringEscapeUtils; + +public class CustomRequestWrapper extends HttpServletRequestWrapper { + // Use standard sanitization function + public String stripXSS(String value) { + return StringEscapeUtils.escapeHtml4(value); + } +} +---- + +The secure version of the code uses the "StringEscapeUtils.escapeHtml4" function from the Apache Commons Text library to sanitize input and prevent XSS attacks. This standard sanitization function provides more robust protection compared to a custom implementation. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-165.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-165.adoc new file mode 100644 index 000000000..39bd3fe03 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-165.adoc @@ -0,0 +1,62 @@ + +== Improper Neutralization of Special Elements in Data Query Logic + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_165 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/943.html[CWE-943: Improper Neutralization of Special Elements in Data Query Logic] + + +|=== + +=== Description + +This SAST policy detects the improper neutralization of special elements in data query logic. It specifically looks for code patterns in Java where user input is used to construct SimpleDB queries, which can allow an attacker to view unauthorized records. + +Vulnerable code example: + +[source,java] +---- +String input = userInput; +SelectRequest selectRequest = new SelectRequest("SELECT * FROM Users WHERE Username = '" + input + "'"); +AmazonSimpleDBClient client = new AmazonSimpleDBClient(); +client.select(selectRequest); +---- + +In the above code, the user input is directly concatenated into the query string without proper sanitization or parameterization. This can lead to SQL injection vulnerabilities, where an attacker can manipulate the user input to execute arbitrary queries and access unauthorized data. + +=== Fix - Buildtime + +To fix this issue, it is important to properly sanitize or parameterize the user input before constructing the query. One way to achieve this is to use prepared statements or query parameterization. By separating the query structure from the input values, the database engine can handle the input safely and prevent SQL injection attacks. + +Secure code example: + +[source,java] +---- +String input = userInput; +SelectRequest selectRequest = new SelectRequest("SELECT * FROM Users WHERE Username = ?"); +selectRequest.addSelectExpressionAttribute("Username", input); +AmazonSimpleDBClient client = new AmazonSimpleDBClient(); +client.select(selectRequest); +---- + +In the secure code example, a prepared statement is used with a placeholder "?" to represent the user input. The actual input value is then bound to the statement using the "addSelectExpressionAttribute" method. This ensures that the user input is properly sanitized and prevents any possible SQL injection vulnerabilities. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-17.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-17.adoc new file mode 100644 index 000000000..a4079679a --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-17.adoc @@ -0,0 +1,73 @@ +== Unsafe DES algorithm used + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_17 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + + + +=== Description + +This policy is warning against the use of the Data Encryption Standard (DES) encryption algorithm in Java applications. DES, including its variant Triple DES (3DES or DESede), has been found to be insecure against sufficiently equipped attackers due to its relatively small key size. NIST (the National Institute of Standards and Technology) recommends using the AES (Advanced Encryption Standard) block cipher instead. + +Here's an example of violating code: + +[source,java] +---- +import javax.crypto.Cipher; + +public class Encryption { + public byte[] encryptData(byte[] data, SecretKey key) throws Exception { + Cipher cipher = Cipher.getInstance("DES"); + cipher.init(Cipher.ENCRYPT_MODE, key); + return cipher.doFinal(data); + } +} +---- + +In this code snippet, the `Cipher.getInstance` method is called with "DES" as an argument, indicating that DES encryption is being used. + +=== Fix - Buildtime + +The correct way to resolve this issue would be to replace "DES" with "AES" to use the AES encryption standard instead: + +[source,java] +---- +import javax.crypto.Cipher; + +public class Encryption { + public byte[] encryptData(byte[] data, SecretKey key) throws Exception { + Cipher cipher = Cipher.getInstance("AES"); + cipher.init(Cipher.ENCRYPT_MODE, key); + return cipher.doFinal(data); + } +} +---- + +This updated code uses AES encryption which is a more secure encryption standard. Please note that AES requires different key sizes, so your `SecretKey` generation should also be updated to match AES requirements. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-171.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-171.adoc new file mode 100644 index 000000000..0b6c9317f --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-171.adoc @@ -0,0 +1,61 @@ + +== Expression injection (OGNL) + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_171 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/917.html[CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects expression injection vulnerabilities in Java code that use the Object Graph Navigation Language (OGNL). The OGNL language allows access to Java objects and properties stored in an ActionContext. The usage of OGNL functions is discouraged because they can execute strings as code, leading to remote code execution vulnerabilities. + +Vulnerable code example: + +[source,java] +---- +String username = request.getParameter("username"); +User user = (User) Ognl.getValue("user." + username, context, root); +---- + +In the above code, the user-supplied input from the "username" parameter is directly concatenated with the OGNL expression "user." and passed to the OGNL `getValue()` function. This can allow an attacker to inject malicious OGNL expressions and execute arbitrary code. + +=== Fix - Buildtime + +To fix this issue, you should avoid using user-supplied input directly in OGNL expressions. Instead, consider using struts tags or other secure methods when processing user-supplied input and templates. + +Secure code example: + +[source,java] +---- +String username = request.getParameter("username"); +User user = userService.getUserByName(username); +---- + +In the secure version of the code, the user-supplied input is used as a parameter to a secure method (`getUserByName()`) that handles input validation and sanitization. This helps prevent expression injection vulnerabilities. + +Using this approach mitigates the risk of remote code execution vulnerabilities through expression injection. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-172.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-172.adoc new file mode 100644 index 000000000..e4ab5d29c --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-172.adoc @@ -0,0 +1,60 @@ + +== Improper neutralization of special elements used in an LDAP query ('LDAP Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_172 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/90.html[CWE-90: Improper neutralization of special elements used in an LDAP query ('LDAP Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This SAST policy detects improper neutralization of special elements used in an LDAP query, also known as LDAP injection vulnerabilities. The policy targets Java code and looks for patterns in source and sink locations that may indicate the presence of LDAP injection vulnerabilities. + +Vulnerable code example: + +[source,java] +---- +String username = request.getParameter("username"); +String query = "(&(uid=" + username + ")(objectClass=person))"; +NamingEnumeration results = ctx.search(query, null); +---- + +In the above code, the value received from the "username" parameter is directly concatenated into the LDAP query without proper sanitization or encoding. This allows an attacker to manipulate the query and potentially perform unauthorized queries or gain access to sensitive information. + +=== Fix - Buildtime + +To fix the LDAP injection vulnerability, proper sanitization and encoding should be applied to the user input before constructing the LDAP query. The following is a secure version of the code: + +[source,java] +---- +String username = request.getParameter("username"); +String encodedUsername = sanitizeAndEncode(username); +String query = "(&(uid=" + encodedUsername + ")(objectClass=person))"; +NamingEnumeration results = ctx.search(query, null); +---- + +In the secure code example, the user input obtained from the "username" parameter is passed through a custom function, sanitizeAndEncode(), which performs proper sanitization and encoding of the input. This ensures that any special characters are properly neutralized and prevents LDAP injection attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-18.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-18.adoc new file mode 100644 index 000000000..2061b4974 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-18.adoc @@ -0,0 +1,72 @@ +== Encryption keys with less than 128 bits + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_18 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/326.html[CWE-326: Inadequate Encryption Strength] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + + + +=== Description + + +The policy is cautioning against the use of small key sizes for encryption, in particular with the Blowfish encryption algorithm. The key size should be at least 128 bits to ensure sufficient resistance against brute force attacks, where an attacker systematically checks all possible keys to decrypt the encrypted data. + +An example of violating code could be: + +[source,java] +---- +import javax.crypto.KeyGenerator; + +public class KeyGen { + public void generateKey() throws Exception { + KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish"); + keyGen.init(64); // Violates the policy. + } +} +---- + +In this code snippet, the `KeyGenerator.init` method is called with `64`, indicating a 64-bit key size is being used for Blowfish, which is smaller than the recommended 128 bits. + +=== Fix - Buildtime + +To fix this issue, you should initialize the key generator with at least 128 bits: + +[source,java] +---- +import javax.crypto.KeyGenerator; + +public class KeyGen { + public void generateKey() throws Exception { + KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish"); + keyGen.init(128); // Correct key size. + } +} +---- + +The above code ensures that a 128-bit key is used for Blowfish, providing stronger encryption and making brute force attacks significantly more difficult. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-19.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-19.adoc new file mode 100644 index 000000000..0646c054e --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-19.adoc @@ -0,0 +1,74 @@ +== Cookie created without Secure flag set + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_19 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/614.html[CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration[A05:2021 - Security Misconfiguration] + +|=== + + + +=== Description + + +The policy addresses the issue of creating and setting cookies without the Secure flag. The Secure flag is a directive for the browser, indicating that the cookie should only be sent over secure (HTTPS) connections. If the Secure flag is not set, the cookie may be sent over insecure (HTTP) connections, potentially exposing sensitive information in an environment vulnerable to eavesdropping. + +A violating code example could be: + +[source,java] +---- +import javax.servlet.http.Cookie; + +public class CookieCreator { + public void createCookie(javax.servlet.http.HttpServletResponse response) { + Cookie myCookie = new Cookie("name", "value"); + // The cookie is being created without the Secure flag. + response.addCookie(myCookie); + } +} +---- + +In the above code, a new cookie is being created and added to the HTTP response without setting the Secure flag, thus violating the policy. + +=== Fix - Buildtime + +To fix the issue, you should set the Secure flag when creating a new cookie, as in the following example: + +[source,java] +---- +import javax.servlet.http.Cookie; + +public class CookieCreator { + public void createCookie(javax.servlet.http.HttpServletResponse response) { + Cookie myCookie = new Cookie("name", "value"); + myCookie.setSecure(true); // Setting the Secure flag. + response.addCookie(myCookie); + } +} +---- + +By setting the Secure flag with `myCookie.setSecure(true)`, we ensure that the cookie will only be sent over secure connections, preventing exposure of potentially sensitive information over insecure connections. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-20.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-20.adoc new file mode 100644 index 000000000..2bb5000dd --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-20.adoc @@ -0,0 +1,74 @@ +== Cookie stored for an extended period of time + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_20 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/539.html[CWE-539: Information Exposure Through Persistent Cookies] + +|OWASP Categories +|https://owasp.org/Top10/A04_2021-Insecure_Design[A04:2021 - Insecure Design] + +|=== + + + +=== Description + + +This policy refers to the practice of setting cookies to persist for an extended period of time. The value of `31536000` seconds corresponds to one year. If a cookie, especially one containing sensitive data, is set to persist for a year or more, it can increase the risk of data exposure or account compromise, especially if the user's system is compromised or the cookie is otherwise mishandled. + +Here is an example of a violating code: + +[source,java] +---- +import javax.servlet.http.Cookie; + +public class PersistentCookieCreator { + public void createCookie(javax.servlet.http.HttpServletResponse response) { + Cookie myCookie = new Cookie("user", "john"); + myCookie.setMaxAge(31536000); // Cookie is set to persist for one year + response.addCookie(myCookie); + } +} +---- + +In the above code, a new cookie is being created and the maximum age of the cookie is being set to one year. This means the cookie will persist for that duration, even if the user closes the browser or restarts the system. + +=== Fix - Buildtime + +To fix this violation, we should reduce the maximum age of the cookie. The suitable duration depends on the context and requirements of the application. If possible, the session cookie should be destroyed when the user logs out or closes the browser. Here is an example fix: + +[source,java] +---- +import javax.servlet.http.Cookie; + +public class ShortLivedCookieCreator { + public void createCookie(javax.servlet.http.HttpServletResponse response) { + Cookie myCookie = new Cookie("user", "john"); + myCookie.setMaxAge(1800); // Cookie will expire in 30 minutes + response.addCookie(myCookie); + } +} +---- + +In this corrected example, the maximum age of the cookie is set to 30 minutes (1800 seconds), which is a more reasonable timeframe. The exact timeframe should be adjusted based on the needs of your application and the sensitivity of the data stored in the cookie. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-21.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-21.adoc new file mode 100644 index 000000000..74af35482 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-21.adoc @@ -0,0 +1,92 @@ +== Cookie contains sensitive session info + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_21 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/200.html[CWE-200: Exposure of Sensitive Information to an Unauthorized Actor] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + + + +=== Description + + +This policy highlights the issue of storing sensitive information or session-related data in a cookie. Cookies are susceptible to a variety of attacks (such as Cross-Site Scripting (XSS) or Cross-Site Request Forgery (CSRF)), and sensitive data stored in them can potentially be exposed to unauthorized actors. It's best practice to only store non-sensitive data in cookies, and keep sensitive or session-related data server-side, associated with the session ID stored in the cookie. + +An example of violating code could look like this: + +[source,java] +---- +import javax.servlet.http.Cookie; +import javax.servlet.http.HttpServletRequest; +import javax.jws.WebMethod; + +public class SensitiveCookieHandler { + @WebMethod + public void handleCookies(HttpServletRequest request) { + for (Cookie cookie : request.getCookies()) { + String cookieName = cookie.getName(); + String cookieValue = cookie.getValue(); + String cookiePath = cookie.getPath(); + // Sensitive information is being accessed from the cookies + System.out.println("Cookie name: " + cookieName); + System.out.println("Cookie value: " + cookieValue); + System.out.println("Cookie path: " + cookiePath); + } + } +} +---- + +This code is problematic because it implies that sensitive information is stored in cookies, which is then accessed and potentially used or exposed. + +=== Fix - Buildtime + +To fix this violation, you should avoid storing sensitive data in cookies and keep it on the server side instead. Cookies should only be used to store session IDs or non-sensitive data. Here's how the revised code might look: + +[source,java] +---- +import javax.servlet.http.Cookie; +import javax.servlet.http.HttpServletRequest; +import javax.servlet.http.HttpSession; +import javax.jws.WebMethod; + +public class SensitiveSessionHandler { + @WebMethod + public void handleSession(HttpServletRequest request) { + HttpSession session = request.getSession(true); + for (Cookie cookie : request.getCookies()) { + String cookieName = cookie.getName(); + // Only session IDs or non-sensitive data should be accessed from the cookies + if (cookieName.equals("sessionID")) { + session.setAttribute("sessionID", cookie.getValue()); + } + } + } +} +---- + +In this revised code, sensitive data is stored in the session (server side) instead of in the cookies. The cookies are only used to store and retrieve the session ID. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-22.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-22.adoc new file mode 100644 index 000000000..524ef3b2c --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-22.adoc @@ -0,0 +1,80 @@ +== Trust Boundary is Violated + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_22 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/501.html[CWE-501: Trust Boundary Violation] + +|OWASP Categories +|https://owasp.org/Top10/A04_2021-Insecure_Design/[A04:2021 - Insecure Design] + +|=== + + + +=== Description + + +A trust boundary can be thought of as a line drawn through a program. On one side of the line, data is untrusted; on the other side, data is considered trustworthy. The role of validation logic is to allow data to safely cross this boundary. Trust boundary violations occur when a program mixes trusted and untrusted data, making it easier for developers to mistakenly trust unvalidated data. + +An example of violating code could look like this: + +[source,java] +---- +import javax.servlet.http.HttpServletRequest; + +public class TrustBoundaryViolation { + public void handleRequest(HttpServletRequest request) { + String untrustedData = request.getParameter("untrustedData"); + // Trust boundary violation: setting untrusted data without validation + request.setAttribute("trustedData", untrustedData); + } +} +---- + +This code is problematic because it places untrusted data (`untrustedData`) into a data structure that is assumed to contain trusted data (`trustedData`), without any validation. + +=== Fix - Buildtime + +To fix this violation, you should add validation logic to verify the data before it crosses the trust boundary. Here's how the revised code might look: + +[source,java] +---- +import javax.servlet.http.HttpServletRequest; + +public class TrustBoundarySafety { + public void handleRequest(HttpServletRequest request) { + String untrustedData = request.getParameter("untrustedData"); + // Validation logic + if (isValid(untrustedData)) { + request.setAttribute("trustedData", untrustedData); + } + } + + public boolean isValid(String data) { + // Implement your validation logic here + return true; // Replace with actual validation logic + } +} +---- + +In this revised code, `untrustedData` is validated by the `isValid()` method before being placed into the `trustedData` attribute. diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-23.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-23.adoc new file mode 100644 index 000000000..dd98fee78 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-23.adoc @@ -0,0 +1,87 @@ +== Security of REST web service is not analyzed + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_23 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + + + +=== Description + + +This policy is aimed at analyzing the security of REST Web Services implemented using JSR311. Focus areas for security analysis include authentication, access control, input validation, and secure communication (preferably SSL/TLS). + +Example of violating code: + +[source,java] +---- +import javax.ws.rs.Path; + +@Path("/api/resource") +public class UnsafeRESTService { + @Path("/data") + public String getData(String input) { + // No security measures in place + return "Data: " + input; + } +} +---- + +This code is problematic because it does not implement any security measures such as authentication, access control, or input validation, and it does not enforce secure communication. + +=== Fix - Buildtime + +To remedy this violation, implement a comprehensive security strategy that includes the following: + +1. **Authentication:** Implement authentication mechanisms to ensure that only authorized users can access the service. + +2. **Access Control:** Implement fine-grained access control policies to regulate what authenticated users are allowed to do. + +3. **Input Validation:** Implement robust input validation to prevent vulnerabilities like SQL injection, XSS, etc. + +4. **Secure Communication:** Ensure that the service communicates over SSL/TLS. + +Here's a sample revised code snippet that implements basic input validation: + +[source,java] +---- +import javax.ws.rs.Path; +import org.apache.commons.text.StringEscapeUtils; + +@Path("/api/resource") +public class SecureRESTService { + @Path("/data") + public String getData(String input) { + String sanitizedInput = StringEscapeUtils.unescapeJava(input); + // Add further security measures here + return "Data: " + sanitizedInput; + } +} +---- + +In the revised code, the `StringEscapeUtils.unescapeJava()` method is used to sanitize the input, reducing the risk of injection attacks. Note that this is just a start and further security measures are needed. diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-24.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-24.adoc new file mode 100644 index 000000000..ae4fe61c7 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-24.adoc @@ -0,0 +1,73 @@ +== File Creation in Publicly Shared Directories + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_24 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/377.html[CWE-377: Insecure Temporary File] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy aims to prevent applications from creating files in publicly shared directories such as `/tmp` or `/var/tmp` on Linux-based systems. These directories are generally writable by any user, making them susceptible to race condition attacks involving filenames. A successful attack could lead to unauthorized file access, modification, corruption, or deletion. The risk escalates if the application operates with elevated permissions. + +Example of violating code: + +[source,java] +---- +import java.nio.file.Paths; +import java.io.File; + +public class InsecureFileCreation { + public void createFile() { + Paths.get("/tmp/insecureFile"); + new File("/var/tmp/insecureFile"); + } +} +---- + +This code is problematic because it creates files in publicly shared directories, exposing the application to risks associated with insecure temporary files. + +=== Fix - Buildtime + +To fix this violation, you should create files in directories that are not publicly writable, or use safer methods that are designed to avoid these issues. Here's an example using Java's built-in `File.createTempFile()` method, which creates a new empty file in the default temporary-file directory: + +[source,java] +---- +import java.io.IOException; +import java.io.File; + +public class SecureFileCreation { + public void createFile() { + try { + File temp = File.createTempFile("prefix", "suffix"); + // Do something with temp + } catch (IOException e) { + // Handle exception + } + } +} +---- + +In this revised code, `File.createTempFile()` is used to safely create a temporary file in a directory managed by the operating system, reducing the risk associated with race conditions and unauthorized file operations. diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-25.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-25.adoc new file mode 100644 index 000000000..ebd8f6f9d --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-25.adoc @@ -0,0 +1,69 @@ +== CSRF is Disabled + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_25 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/352.html[CWE-352: Cross-Site Request Forgery (CSRF)] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy aims to prevent the disabling of Cross-Site Request Forgery (CSRF) protection in web applications. CSRF is an attack that tricks the victim into submitting a malicious request. Since web browsers automatically include cookies, the actions can be authenticated and sensitive if CSRF protection is disabled. + +Example of violating code: + +[source,java] +---- +import org.springframework.security.config.annotation.web.builders.HttpSecurity; + +public class SecurityConfig { + public void configure(HttpSecurity http) throws Exception { + http.csrf().disable(); + // OR + http.csrf().ignoringAntMatchers("/api/*"); + } +} +---- + +This code is problematic because it disables CSRF protection entirely or for specific URL patterns, leaving the application vulnerable to CSRF attacks. + +=== Fix - Buildtime + +To fix this violation, CSRF protection should not be disabled. If you have specific endpoints that require disabling CSRF, it's crucial to understand the risks involved and consider other forms of protection. + +Example of revised code: + +[source,java] +---- +import org.springframework.security.config.annotation.web.builders.HttpSecurity; + +public class SecurityConfig { + public void configure(HttpSecurity http) throws Exception { + http.csrf().enable(); + } +} +---- + +In this revised code, CSRF protection is enabled for all endpoints, making it more difficult for attackers to exploit the vulnerability. diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-26.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-26.adoc new file mode 100644 index 000000000..4614cfe6d --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-26.adoc @@ -0,0 +1,68 @@ +== Authorization is not robust + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_26 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/285.html[CWE-285: Improper Authorization] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy aims to ensure that the authorization process within an application is robust and not subject to vulnerabilities. Authorization decisions should be robust and depend on strong variables such as user authentication, roles, privileges, location, and time of access. + +Example of violating code: + +[source,java] +---- +public class WeakVoter implements AccessDecisionVoter { + @Override + public int vote(SecurityContext context) { + // Weak decision + return ACCESS_ABSTAIN; + } +} +---- + +This code is problematic because it abstains from making a strong authorization decision, potentially allowing unauthorized access. + +=== Fix - Buildtime + +To fix this issue, make sure to implement strong decision-making mechanisms in your authorization layer. Here's how the revised code might look: + +[source,java] +---- +public class StrongVoter implements AccessDecisionVoter { + @Override + public int vote(SecurityContext context) { + // Strong decision based on authentication, roles, privileges, etc. + if (context.isAuthenticated() && context.hasRole("ADMIN")) { + return ACCESS_GRANTED; + } + return ACCESS_DENIED; + } +} +---- + +In this revised code, authorization decisions are made based on strong variables, such as user authentication status and role privileges, thereby bolstering security. diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-43.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-43.adoc new file mode 100644 index 000000000..7115815d9 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-43.adoc @@ -0,0 +1,76 @@ +== Pathname input not restricted + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_43 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy identifies potential risks in Java applications where file-related functions from the Apache Commons IO library might be used without properly filtering input parameters. Without filtering, there's a risk that an attacker could read files from arbitrary filesystem locations, leading to unauthorized data access or information disclosure. Such vulnerabilities are commonly referred to as path traversal or directory traversal attacks. + +Specifically, this policy checks for the usage of methods like: +- `normalize()` +- `getExtension()` +- `isExtensions()` +- `getName()` +- `getBaseName()` +and their fully qualified counterparts in the `org.apache.commons.io.FilenameUtils` class. + +Example of violating code: + +[source,java] +---- +import static org.apache.commons.io.FilenameUtils; + +String userFilePath = getUserInput(); +String normalizedPath = normalize(userFilePath); +---- + +=== Fix - Buildtime + +To mitigate this issue, ensure that all file path inputs are rigorously validated and sanitized. Limit file operations to a specific directory, and do not allow any input to traverse outside of this controlled location. + +For instance: + +- Use whitelist validation for file paths. +- Reject file paths containing sequences like `..` or `../`. + +Example of a safer approach: + +[source,java] +---- +import static org.apache.commons.io.FilenameUtils; + +String userFilePath = getUserInput(); +if(isValidPath(userFilePath)) { + String normalizedPath = normalize(userFilePath); +} +// ... Define and implement the isValidPath method ... +---- + +By taking these precautions, you can reduce the risk of path traversal vulnerabilities in your Java applications. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-44.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-44.adoc new file mode 100644 index 000000000..96fc99652 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-44.adoc @@ -0,0 +1,75 @@ +== File path not validated in file uploads + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_44 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy detects potential security vulnerabilities in Java applications using the FileUpload API where the filename could be tampered with by a client. Such tampering could allow referencing unauthorized files. Proper validation should be applied to ensure that the filename is appropriately structured, devoid of unauthorized path characters (like `/` or `\`), and references an authorized file. + +Specifically, the policy checks for instances where filenames are retrieved from file items within parsed requests, without evident validation. + +Example of potentially risky code: + +[source,java] +---- +public void uploadFile(HttpServletRequest request) { + List items = new ServletFileUpload(new DiskFileItemFactory()).parseRequest(request); + for (FileItem item : items) { + String filename = item.getName(); + // ... Process file upload ... + } +} +---- + +=== Fix - Buildtime + +To address this vulnerability, ensure that the retrieved filename is validated and sanitized: + +- Validate the filename against a whitelist of expected files or patterns. +- Remove or replace path traversal sequences and special characters from the filename. +- Consider prepending a fixed directory path to the filename, ensuring that the file will be saved in a controlled location. + +Example of corrected code: + +[source,java] +---- +public void uploadFile(HttpServletRequest request) { + List items = new ServletFileUpload(new DiskFileItemFactory()).parseRequest(request); + for (FileItem item : items) { + String filename = sanitizeFilename(item.getName()); + if (isValidFilename(filename)) { + // ... Process file upload ... + } + } +} +// ... Implement the sanitizeFilename and isValidFilename methods ... +---- + +By applying these measures, the risk of path traversal or unauthorized file access via file uploads can be significantly reduced. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-45.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-45.adoc new file mode 100644 index 000000000..ea2b6a2ae --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-45.adoc @@ -0,0 +1,70 @@ +== Pathname not restricted in HTTP requests + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_45 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy identifies potential security vulnerabilities in Java applications when constructing pathnames from HTTP request parameters. There is a risk that an attacker could manipulate the HTTP request parameter to traverse directories and access or overwrite unauthorized files. This form of attack, often termed path or directory traversal, can lead to unauthorized data access, information disclosure, or even code execution in certain contexts. + +Specifically, the policy checks for instances where: +- Pathnames are constructed directly from HTTP request parameters. +- These pathnames are passed to various file operation functions or constructors without adequate validation or sanitization. + +For a detailed understanding of the risks associated with path traversal, refer to [CWE-22](http://cwe.mitre.org/data/definitions/36.html). + +Example of potentially risky code: + +[source,java] +---- +HttpServletRequest request; +String userFilePath = request.getParameter("filePath"); +File file = new File(userFilePath); +---- + +=== Fix - Buildtime + +To mitigate this vulnerability: + +1. Avoid using raw input from HTTP request parameters to construct file paths directly. +2. Utilize sanitizers such as `org.apache.commons.io.FilenameUtils.getName()` to obtain just the base name of a file without path information. +3. Implement whitelist validations for file paths and names. +4. Reject or sanitize input containing path traversal sequences or special characters. + +Example of corrected code: + +[source,java] +---- +HttpServletRequest request; +String userFilePath = request.getParameter("filePath"); +String sanitizedPath = org.apache.commons.io.FilenameUtils.getName(userFilePath); +File file = new File("/safe/directory/" + sanitizedPath); +---- + +By adopting these measures, the risk of path traversal vulnerabilities can be significantly minimized, ensuring safer file operations. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-46.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-46.adoc new file mode 100644 index 000000000..cd23f42ee --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-46.adoc @@ -0,0 +1,74 @@ +== File path not validated for file writes + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_46 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy detects potential path traversal vulnerabilities in Java applications where file paths are derived from input parameters and used to write or modify file content. Such vulnerabilities can arise when applications fail to validate or sanitize file paths before conducting file operations, potentially allowing an attacker to modify files in unauthorized locations. + +Specifically, the policy checks for: +- Constructing file paths directly from function arguments without evident validation or sanitization. +- Writing or modifying files using the constructed paths. + +The issue could lead to unauthorized file modifications, data tampering, or even execution of malicious code if critical configuration or code files are modified. + +Example of potentially risky code: + +[source,java] +---- +public void saveFile(String[] args) { + String userFilePath = args[0]; + FileWriter writer = new FileWriter(userFilePath); + // ... Writing to the file ... +} +---- + +=== Fix - Buildtime + +To address this issue: + +1. Avoid constructing file paths directly from raw input parameters. +2. Use sanitizers, such as `org.apache.commons.io.FilenameUtils.getName()`, to extract just the base name of a file without path information. +3. Use whitelist validations for file paths and names. +4. Reject or sanitize input containing path traversal sequences or special characters. + +Example of corrected code: + +[source,java] +---- +public void saveFile(String[] args) { + String userInput = args[0]; + String sanitizedPath = org.apache.commons.io.FilenameUtils.getName(userInput); + FileWriter writer = new FileWriter("/safe/directory/" + sanitizedPath); + // ... Writing to the file ... +} +---- + +Implementing these precautions ensures a reduced risk of path traversal vulnerabilities during file writes. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-47.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-47.adoc new file mode 100644 index 000000000..66360e3af --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-47.adoc @@ -0,0 +1,75 @@ +== Missing validation for paths when processing style sheets + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_47 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy identifies potential security vulnerabilities in Java applications when processing style sheets. By manipulating style sheets or their source paths, an attacker could execute malicious actions, leading to remote code execution or other forms of attack. + +Specifically, the policy checks for: +- Paths constructed from function arguments or class-level variables, which are then used to read files or resources. +- The subsequent usage of these paths in XML transformation operations, a context where maliciously crafted style sheets could be exploited. + +This sort of attack vector is particularly concerning because style sheets can carry behaviors (e.g., in the form of XSLT), and if an attacker can control or inject content, it could lead to arbitrary code execution. + +Example of potentially vulnerable code: + +[source,java] +---- +public void transformStyleSheet(String filePath) { + Source source = new FileInputStream(filePath); + TransformerFactory factory = TransformerFactory.newInstance(); + Transformer transformer = factory.newTransformer(source); + // ... transformation logic ... +} +---- + +=== Fix - Buildtime + +To mitigate this vulnerability: + +1. Avoid using raw input or unvalidated paths to read files or resources, especially when these are to be used in XML transformations. +2. Ensure paths are rigorously validated and sanitized. Reject or sanitize input containing path traversal sequences or special characters. +3. If possible, use known, fixed paths or whitelisted paths for style sheets and avoid dynamic construction based on user input or external data. + +Example of a safer approach: + +[source,java] +---- +public void transformStyleSheet(String filePath) { + String validatedPath = validateAndSanitizePath(filePath); + Source source = new FileInputStream(validatedPath); + TransformerFactory factory = TransformerFactory.newInstance(); + Transformer transformer = factory.newTransformer(source); + // ... transformation logic ... +} +// ... Implement the validateAndSanitizePath method ... +---- + +By adopting these measures, the risk of exploiting path traversal vulnerabilities when processing style sheets can be significantly reduced. diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-48.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-48.adoc new file mode 100644 index 000000000..80f4236ae --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-48.adoc @@ -0,0 +1,70 @@ +== Unrestricted directory for pathname construction from HTTP requests + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_48 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy identifies potential security vulnerabilities in Java applications when constructing pathnames directly from HTTP request parameters. If not properly sanitized or validated, this can lead to path traversal vulnerabilities, which can allow an attacker to read, write, or manipulate files in unintended directories. + +The policy specifically checks for: +- The direct usage of HTTP request parameters to construct or modify file paths. +- These constructed or modified paths being used in various file or resource operations. + +An attacker exploiting this type of vulnerability could access or tamper with files outside of the intended directory, leading to information disclosure, data tampering, or even further security breaches depending on the nature of the accessed files. + +Example of potentially risky code: + +[source,java] +---- +HttpServletRequest request; +String userFilePath = request.getParameter("filePath"); +File file = new File("/base/directory/" + userFilePath); +---- + +=== Fix - Buildtime + +To mitigate this issue: + +1. Never construct file paths directly from raw input parameters without validation or sanitization. +2. Utilize sanitizers such as `org.apache.commons.io.FilenameUtils.getName()` to ensure only the base name of a file is retrieved without any path sequences. +3. Implement whitelist validations for file paths and names. Ensure paths are rigorously validated and sanitized before use. +4. Reject or sanitize input containing path traversal sequences, such as `..`, or special characters that could modify the intended path. + +Example of a safer approach: + +[source,java] +---- +HttpServletRequest request; +String userInput = request.getParameter("filePath"); +String sanitizedPath = org.apache.commons.io.FilenameUtils.getName(userInput); +File file = new File("/base/directory/" + sanitizedPath); +---- + +Implementing these best practices ensures the application is protected against path traversal attacks stemming from unsanitized HTTP request parameters. + diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-49.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-49.adoc new file mode 100644 index 000000000..eab26c900 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-49.adoc @@ -0,0 +1,73 @@ +== Unrestricted pathnames from HTTP requests + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_49 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Java + +|CWEs +|https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy is designed to detect potential path traversal vulnerabilities in Java applications arising from the direct use of HTTP request parameters to form or modify file paths. Without rigorous validation or sanitization, this could allow an attacker to access or modify files outside the intended directory. + +The identified code patterns include: +- Direct usage of arguments or specific method parameters to form paths. +- The potential use of these paths in various file or resource operations. + +Path traversal attacks can lead to unintended information disclosure, data tampering, or more severe impacts depending on the nature of the accessed files. + +Example of potentially vulnerable code: + +[source,java] +---- +public void handleRequest(String[] args) { + String userFilePath = args[0]; + File file = new File("/secure/directory/" + userFilePath); + // ... some operations ... +} +---- + +=== Fix - Buildtime + +To address this vulnerability: + +1. Avoid directly using raw input parameters, especially those obtained from HTTP requests, to form file paths. This applies not only to HTTP request parameters but also to any input that could come from an external or untrusted source. +2. Use sanitizers like `org.apache.commons.io.FilenameUtils.getName()` to ensure that the formed path is limited to the filename without any path sequences. +3. Implement strict whitelist validations for file paths and names. This means paths should be rigorously validated and sanitized before being used. +4. Deny or sanitize inputs containing path traversal sequences such as `..` or other special characters that could modify the intended path. + +Example of a remediated approach: + +[source,java] +---- +public void handleRequest(String[] args) { + String userInput = args[0]; + String sanitizedPath = org.apache.commons.io.FilenameUtils.getName(userInput); + File file = new File("/secure/directory/" + sanitizedPath); + // ... some operations ... +} +---- + +By following these guidelines, the application becomes less susceptible to path traversal attacks stemming from unsanitized input parameters. diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-7.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-7.adoc new file mode 100644 index 000000000..69ea459b9 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-7.adoc @@ -0,0 +1,62 @@ + +== Improper neutralization of argument delimiters in a command ('Argument Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_7 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/88.html[CWE-88: Improper neutralization of argument delimiters in a command ('Argument Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects improper neutralization of argument delimiters in a command, also known as argument injection. In particular, it focuses on detecting the vulnerability of HTTP Response Splitting. HTTP Response Splitting is a vulnerability where carriage return (CR) and line feed (LF) characters are introduced into an HTTP header from user-supplied input. By injecting the `\\r\\n` character sequence, an adversary could potentially modify how the response is interpreted by the client or any downstream caching services. This could allow an adversary to poison the cache data or execute Cross-Site Scripting (XSS) attacks. + +Vulnerable code example: + +[source,java] +---- +String input = request.getParameter("input"); +response.setHeader("Location", input); +---- + +The above code is vulnerable because it blindly uses the user-supplied input to set the value of the "Location" header without proper validation or encoding. An attacker can exploit this by injecting CR LF characters and manipulating the response interpretation. + +=== Fix - Buildtime + +To fix the issue, the user-supplied input should be properly validated and encoded before being set as a header value. + +Secure code example: + +[source,java] +---- +String input = request.getParameter("input"); +validateHeader(input); +response.setHeader("Location", escapeValue(input)); +---- + +In the secure code example, the user-supplied input is first validated using the `validateHeader` method. This method checks each character of the input and throws an exception if any invalid characters are detected. Then, the `escapeValue` method is used to escape the input before setting it as the value of the "Location" header. This ensures that any potential harmful characters are properly encoded. + +By validating and encoding the user-supplied input, the code prevents HTTP Response Splitting attacks and ensures that the response interpretation remains secure. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-8.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-8.adoc new file mode 100644 index 000000000..1219cad48 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-8.adoc @@ -0,0 +1,80 @@ + +== Files or directories accessible to external parties + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_8 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/552.html[CWE-552: Files or directories accessible to external parties] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This SAST policy detects code that may allow access to restricted files or directories by external parties. Specifically, it looks for the usage of the `org.springframework.web.servlet.ModelAndView` class and `HttpRequest.getRequestDispatcher()`'s `include` and `forward` methods that are called with user-supplied input. + +Vulnerable code example: + +[source,java] +---- +@RequestMapping(value="/mvc", method=RequestMethod.GET) +public ModelAndView mvc(HttpServletRequest request, HttpServletResponse response, Model model) +{ + // Get user input + String userInput = request.getParameter("key"); + // Use user input directly to resolve a view + return new ModelAndView(userInput); +} +---- + +The above code is vulnerable because it takes user-supplied input (`userInput`) and directly uses it to resolve a view without any validation or sanitization. This could potentially allow an attacker to access restricted views that they are not supposed to have access to. + +=== Fix - Buildtime + +To fix the vulnerability, it is recommended to validate and sanitize the user-supplied input before using it to resolve a view. One approach is to use a lookup table or data source to map the user input to a specific view. Here is an example of how to fix the code: + +Secure code example: + +[source,java] +---- +@RequestMapping(value="/mvc", method=RequestMethod.GET) +public ModelAndView mvc(HttpServletRequest request, HttpServletResponse response, Model model) +{ + // Create a lookup table or pull from a data source + HashMap lookupTable = new HashMap<>(); + lookupTable.put("key1", "view1"); + lookupTable.put("key2", "view2"); + + // Get user input + String userInput = request.getParameter("key"); + + // Look up view from the user input + String viewValue = lookupTable.getOrDefault(userInput, userInput); + + // Return the new model and view + return new ModelAndView(viewValue); +} +---- + +In the fixed code, a lookup table is used to map the user input to a specific view. This ensures that only valid and authorized views are accessible, preventing unauthorized access to restricted views. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/java-policies/sast-policy-9.adoc b/application-security/policy-reference/sast-policies/java-policies/sast-policy-9.adoc new file mode 100644 index 000000000..f86ccf5e9 --- /dev/null +++ b/application-security/policy-reference/sast-policies/java-policies/sast-policy-9.adoc @@ -0,0 +1,58 @@ +== Improper neutralization of CRLF sequences in HTTP headers ('HTTP Response Splitting') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_9 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|java + +|CWEs +|https://cwe.mitre.org/data/definitions/113.html[CWE-113: Improper neutralization of CRLF sequences in HTTP headers ('HTTP Response Splitting')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This SAST policy detects improper neutralization of CRLF sequences in HTTP headers, also known as "HTTP Response Splitting." This vulnerability allows attackers to inject CR (\r) and LF (\n) characters into headers, which can lead to cache poisoning and cross-site scripting (XSS) attacks. + +Vulnerable code example: + +[source,java] +---- +String userHeader = request.getHeader("User-Agent\r\nInjected-Header: malicious"); +response.addHeader("X-Forwarded-For\r\nInjected-Header: 127.0.0.1"); +---- + +The above code is vulnerable because it does not properly sanitize or validate user inputs used in HTTP headers, allowing for the injection of newline characters that can be exploited. + +=== Fix - Buildtime + +To fix this issue, you should validate and sanitize user inputs used in HTTP headers. One approach is to use tools like Apache Commons Text to escape inputs and remove any potentially malicious characters. + +Secure code example: + +[source,java] +---- +String userHeader = StringEscapeUtils.escapeJava(request.getHeader("User-Agent")); +response.addHeader("X-Forwarded-For", "127.0.0.1"); +---- + +The above code is no longer vulnerable because it uses StringEscapeUtils.escapeJava to escape any special characters in the User-Agent header, preventing HTTP Response Splitting. Additionally, the X-Forwarded-For header is properly set without any potential injections. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-javascript-policy-index.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-javascript-policy-index.adoc new file mode 100644 index 000000000..fc82617a7 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-javascript-policy-index.adoc @@ -0,0 +1,150 @@ +== SAST JavaScript Policy Index + +[width=85%] +[cols="1,1,1"] +|=== +|Policy|Checkov ID| Severity + +|xref:sast-policy-27.adoc[Escape markup is removed leading to risk for XSS] +|CKV3_SAST_27 +|LOW + +|xref:sast-policy-28.adoc[CSRF is not used before `methodOverride`] +|CKV3_SAST_28 +|LOW + +|xref:sast-policy-29.adoc[Calls to fs functions that take a non Literal value as the filename parameter] +|CKV3_SAST_29 +|MEDIUM + +|xref:sast-policy-30.adoc[Bracket object notation with user input] +|CKV3_SAST_30 +|MEDIUM + +|xref:sast-policy-31.adoc[Insecure use of crypto.pseudoRandomBytes] +|CKV3_SAST_31 +|MEDIUM + +|xref:sast-policy-32.adoc[Creating temp tile done with insecure permissions] +|CKV3_SAST_32 +|HIGH + +|xref:sast-policy-33.adoc[Encryption Keys are less than 16 bytes] +|CKV3_SAST_33 +|MEDIUM + +|xref:sast-policy-34.adoc[Hash used without salt] +|CKV3_SAST_34 +|MEDIUM + +|xref:sast-policy-35.adoc[Use of RSA Algorithm without Optimal Asymmetric Encryption Padding (OAEP)] +|CKV3_SAST_35 +|HIGH + +|xref:sast-policy-36.adoc[Superuser port is set] +|CKV3_SAST_36 +|MEDIUM + +|xref:sast-policy-38.adoc[Insecure use of weak hashing algorithms] +|CKV3_SAST_38 +|HIGH + +|xref:sast-policy-39.adoc[Use of insecure HTTP connections] +|CKV3_SAST_39 +|MEDIUM + +|xref:sast-policy-40.adoc[Use of insecure HTTP Connections with Axios] +|CKV3_SAST_40 +|LOW + +|xref:sast-policy-41.adoc[Insecure use of `eval` with non-string parameters] +|CKV3_SAST_41 +|MEDIUM + +|xref:sast-policy-42.adoc[Insecure use of `new Buffer()`] +|CKV3_SAST_42 +|LOW + +|xref:sast-policy-74.adoc[Insecure communication using postMessage and event listeners] +|CKV3_SAST_74 +|MEDIUM + +|xref:sast-policy-75.adoc[Encryption algorithm not using secure modes and padding] +|CKV3_SAST_75 +|HIGH + +|xref:sast-policy-76.adoc[Risk of Regular Expression Denial of Service (ReDoS)] +|CKV3_SAST_76 +|HIGH + +|xref:sast-policy-77.adoc[Weak SSL/TLS protocols] +|CKV3_SAST_77 +|MEDIUM + +|xref:sast-policy-78.adoc[Restrict Unnecessary Powerful Browser Features] +|CKV3_SAST_78 +|MEDIUM + +|xref:sast-policy-79.adoc[Prevent Public Network Access to Cloud Resources] +|CKV3_SAST_79 +|MEDIUM + +|xref:sast-policy-80.adoc[Enforce HTTPS Access for S3 Buckets] +|CKV3_SAST_80 +|MEDIUM + +|xref:sast-policy-81.adoc[Prevent OS Command Argument Injections] +|CKV3_SAST_81 +|MEDIUM + +|xref:sast-policy-83.adoc[Complex/formatted SQL query] +|CKV3_SAST_83 +|HIGH + +|xref:sast-policy-84.adoc[AngularJS misconfiguration dangerous protocol allowed] +|CKV3_SAST_84 +|LOW + +|xref:sast-policy-85.adoc[AngularJS Misconfiguration Strict Contextual Escaping Disabled] +|CKV3_SAST_85 +|MEDIUM + +|xref:sast-policy-92.adoc[Detection of XSS vulnerability] +|CKV3_SAST_92 +|LOW + +|xref:sast-policy-95.adoc[Cookie Security Overly Permissive Samesite Attribute] +|CKV3_SAST_95 +|MEDIUM + +|xref:sast-policy-101.adoc[Insecure SSL Server Identity Verification Disabled] +|CKV3_SAST_101 +|MEDIUM + +|xref:sast-policy-146.adoc[Ensure Usage of JWT Algo] +|CKV3_SAST_146 +|MEDIUM + +|xref:sast-policy-153.adoc[Sensitive Data Logging] +|CKV3_SAST_153 +|MEDIUM + +|xref:sast-policy-157.adoc[Cross-Site Request Forgery (CSRF)] +|CKV3_SAST_157 +|MEDIUM + +|xref:sast-policy-158.adoc[Improper restriction of operations within the bounds of a memory buffer] +|CKV3_SAST_158 +|MEDIUM + +|xref:sast-policy-159.adoc[Incorrect regular expression] +|CKV3_SAST_159 +|MEDIUM + +|xref:sast-policy-160.adoc[Information Exposure Through an Error Message] +|CKV3_SAST_160 +|MEDIUM + +|xref:sast-policy-161.adoc[Observable timing discrepancy] +|CKV3_SAST_161 +|MEDIUM diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-101.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-101.adoc new file mode 100644 index 000000000..c22e24243 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-101.adoc @@ -0,0 +1,60 @@ + +== Insecure SSL Server Identity Verification Disabled + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_101 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript + +|CWEs +|https://cwe.mitre.org/data/definitions/297.html[CWE-297: Insecure SSL Server Identity Verification Disabled] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects when the SSL server identity verification is disabled in JavaScript code. Disabling SSL/TLS certificate validation can lead to insecure communication and authentication failures. + +Vulnerable code example: + +[source,javascript] +---- +process.env["NODE_TLS_REJECT_UNAUTHORIZED"] = "0"; +---- + +The above code sets the environment variable "NODE_TLS_REJECT_UNAUTHORIZED" to 0, disabling SSL server identity verification. This means that the code will accept any SSL certificate, even if it is not valid or cannot be trusted. + +=== Fix - Buildtime + +To fix the issue, you should remove or disable the code that sets "NODE_TLS_REJECT_UNAUTHORIZED" to 0. Instead, use proper SSL server identity verification to ensure secure communication. + +Secure code example: + +[source,javascript] +---- +// Enable SSL server identity verification +process.env["NODE_TLS_REJECT_UNAUTHORIZED"] = "1"; +---- + +In the secure version of the code, the environment variable "NODE_TLS_REJECT_UNAUTHORIZED" is set to 1, enabling SSL server identity verification. This ensures that the code will only accept valid and trusted SSL certificates. + +Note: Disabling SSL server identity verification should only be used for debugging purposes and not in production code. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-146.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-146.adoc new file mode 100644 index 000000000..ed17c61c7 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-146.adoc @@ -0,0 +1,75 @@ + +== Ensure Usage of JWT Algo + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_146 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript + +|CWEs +|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects the usage of JWT (JSON Web Token) with a non-secure algorithm. + +Vulnerable code example: + +[source,javascript] +---- +const jwt = require('jsonwebtoken'); + +const payload = { + user: 'admin', + role: 'admin' +}; + +const token = jwt.sign(payload, 'secret', { algorithm: 'none' }); + +console.log(token); +---- + +In the above code, the `algorithm` option for JWT signing is set to `'none'`. This means that the JWT token is not encrypted and can be easily tampered with or read by unauthorized parties. + +=== Fix - Buildtime + +To fix the issue, you should ensure that a secure algorithm is used for JWT signing, such as HMAC SHA256 or RSA. + +Secure code example: + +[source,javascript] +---- +const jwt = require('jsonwebtoken'); + +const payload = { + user: 'admin', + role: 'admin' +}; + +const token = jwt.sign(payload, 'secret', { algorithm: 'HS256' }); + +console.log(token); +---- + +In the fixed code, the `algorithm` option is set to `'HS256'`, which uses HMAC SHA256 for JWT encryption. This ensures that the JWT token is securely encrypted and protected from tampering or unauthorized access. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-153.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-153.adoc new file mode 100644 index 000000000..9f62643fa --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-153.adoc @@ -0,0 +1,57 @@ + +== Sensitive Data Logging + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_153 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript + +|CWEs +|https://cwe.mitre.org/data/definitions/532.html[CWE-532: Insertion of Sensitive Information into Log File] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects sensitive data logging in JavaScript code. It ensures that web applications do not log sensitive data, including credit card numbers and personal details. Logging mechanisms should be configured to mask or remove sensitive data from logs to comply with regulations and protect user privacy. + +Vulnerable code example: + +[source,javascript] +``` +const name = document.getElementById('name').value; +console.log('User name: ' + name); +``` + +The above code is vulnerable because it logs the user's name without any masking or removal of sensitive data. + +=== Fix - Buildtime + +To fix the issue, you should configure the logging mechanism to mask or remove sensitive data. Here's an example of secure code: + +[source,javascript] +``` +const name = document.getElementById('name').value; +console.log('User name: ' + maskSensitiveData(name)); +``` + +In the secure code example, the sensitive data (user's name) is passed to a function called `maskSensitiveData` before being logged. This function ensures that the sensitive data is properly masked or removed, preventing it from being logged in plaintext. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-157.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-157.adoc new file mode 100644 index 000000000..647ab524a --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-157.adoc @@ -0,0 +1,59 @@ + +== Cross-Site Request Forgery (CSRF) + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_157 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript, typescript + +|CWEs +|https://cwe.mitre.org/data/definitions/352.html[CWE-352: Cross-Site Request Forgery (CSRF)] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy detects the use of express.csrf() middleware before express.methodOverride(). This can allow GET requests (which are not checked by csrf) to turn into POST requests later. + +Vulnerable code example: + +[source,javascript] +---- +app.use(express.csrf()); +app.use(express.methodOverride()); +---- + +The above code is vulnerable because it uses the `express.csrf()` middleware before `express.methodOverride()`. This means that GET requests, which are not checked by CSRF protection, can later be turned into POST requests. + +=== Fix - Buildtime + +To fix the issue, the `express.methodOverride()` middleware should be used before the `express.csrf()` middleware. + +Secure code example: + +[source,javascript] +---- +app.use(express.methodOverride()); +app.use(express.csrf()); +---- + +The above code is no longer vulnerable because it uses the `express.methodOverride()` middleware before the `express.csrf()` middleware. This ensures that POST requests are not created from GET requests without proper CSRF protection. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-158.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-158.adoc new file mode 100644 index 000000000..3e6df1c67 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-158.adoc @@ -0,0 +1,69 @@ + +== Improper restriction of operations within the bounds of a memory buffer + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_158 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript, typescript + +|CWEs +|https://cwe.mitre.org/data/definitions/119.html[CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer] + + +|=== + +=== Description + +This policy detects the usage of the `noAssert` argument when calling the Buffer API in JavaScript or TypeScript. The `noAssert` argument has been deprecated since Node 10 and allows the offset specified to be beyond the end of the buffer. This can result in writing or reading beyond the end of the buffer and cause a segmentation fault, leading to the application crashing. + +Vulnerable code example: + +[source,javascript] +---- +const buf = Buffer.alloc(4); + +// Reading an integer with noAssert argument set to true +const value = buf.readInt32BE(4, true); +---- + +The above code is vulnerable because it uses the `noAssert` argument when calling the `readInt32BE` method of the Buffer API. This allows the offset to be beyond the end of the buffer, potentially causing out-of-bounds memory access. + +=== Fix - Buildtime + +To fix this issue, remove the `true` argument when calling any of the Buffer read methods. The application should still handle `RangeError` exception cases where the offset is beyond the end of the buffer. + +Secure code example: + +[source,javascript] +---- +const buf = Buffer.alloc(4); + +// Reading an integer without the noAssert argument +try { + const value = buf.readInt32BE(4); + // Work with value +} catch (e) { + if (e instanceof RangeError) { + console.log('Invalid offset: %s', e.message); + } + // Handle other errors +} +---- + +The above code is no longer vulnerable because it removes the `true` argument when calling `readInt32BE` method and gracefully handles the `RangeError` exception cases. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-159.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-159.adoc new file mode 100644 index 000000000..3659be693 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-159.adoc @@ -0,0 +1,59 @@ + +== Incorrect regular expression + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_159 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript, typescript + +|CWEs +|https://cwe.mitre.org/data/definitions/185.html[CWE-185: Incorrect Regular Expression] + + +|=== + +=== Description + +This SAST policy detects the usage of the `RegExp` constructor with a non-literal variable, which can lead to a Regular Expression Denial of Service (ReDoS) vulnerability. If an adversary is able to supply a malicious regex, it can cause the application to become unresponsive, potentially affecting the availability of the application for other users. + +Vulnerable code example: + +[source,javascript] +``` +var userInput = prompt("Enter a regular expression:"); +var regex = new RegExp(userInput); +``` + +In the above code, the `RegExp` constructor is used with the `userInput` variable, which comes from user input. This allows an adversary to supply a malicious regex that can potentially cause the application to perform excessive and inefficient matching, resulting in a DoS condition. + +=== Fix - Buildtime + +To fix this issue, user-supplied regular expressions should never be allowed. Instead, the regular expression should be hardcoded or generated from a trusted source. If user input is necessary for building regular expressions, it is recommended to validate and sanitize the input to prevent any malicious patterns. + +Secure code example: + +[source,javascript] +``` +var userInput = prompt("Enter a regular expression:"); +var regex = /^([a-z]+)\d+$/; +``` + +In the above code, a hardcoded regular expression `/^([a-z]+)\d+$/` is used instead of the user-supplied input. This ensures that only specific patterns are matched, mitigating the risk of excessive matching and potential DoS. + +By using a hardcoded regular expression, the application no longer relies on user input for generating regular expressions, eliminating the potential for malicious patterns and ReDoS vulnerabilities. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-160.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-160.adoc new file mode 100644 index 000000000..2546b4eea --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-160.adoc @@ -0,0 +1,59 @@ + +== Information Exposure Through an Error Message + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_160 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript + +|CWEs +|https://cwe.mitre.org/data/definitions/209.html[CWE-209: Generation of Error Message Containing Sensitive Information] + +|OWASP Categories +|https://owasp.org/Top10/A04_2021-Insecure_Design/[A04:2021 - Insecure Design] + +|=== + +=== Description + +This policy detects information exposure through an error message. If the code contains a pattern that matches either `console.trace()` or a `try-catch` block with a function containing one of the following methods: `console.log`, `console.error`, `console.warn`, `alert`, `prompt`, or `confirm`, and the catch block includes a variable `$ERR` or a variable that contains sensitive information such as `message`, `stack`, `status`, or `name`, then it is considered a vulnerability. + +Vulnerable code example: + +[source,javascript] +``` +console.trace('Error message containing sensitive information'); +``` + +The above code is vulnerable because it directly exposes sensitive information through the `console.trace` method. + +=== Fix - Buildtime + +To fix the issue, avoid printing sensitive information directly in error messages. Instead, modify the error handling logic to handle sensitive information securely. + +Secure code example: + +[source,javascript] +``` +throw new Error('An unexpected error occurred'); +``` + +In the secure code example, the error message does not contain any sensitive information. The code throws a generic error message to avoid exposing any internal details about the error. + +By following this approach, sensitive information is not leaked through error messages, improving the overall security of the application. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-161.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-161.adoc new file mode 100644 index 000000000..c1f082651 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-161.adoc @@ -0,0 +1,64 @@ + +== Observable timing discrepancy + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_161 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript + +|CWEs +|https://cwe.mitre.org/data/definitions/208.html[CWE-208: Observable Timing Discrepancy] + + +|=== + +=== Description + +This SAST policy detects string comparisons using the `===`, `!==`, `==`, or `!=` operators against security-sensitive values. These string comparisons are not constant time, meaning that the conditional statement will immediately exit as soon as the first character that does not match is found. This can lead to observable timing discrepancies and potentially allow an adversary to calculate or observe small timing differences to brute force a string that matches the expected value. + +Vulnerable code example: + +[source,javascript] +---- +if (password == userInput) { + // Do something +} +---- + +The above code is vulnerable because it compares the user's input with a security-sensitive value, `password`, using the `==` operator. This type of comparison is not constant time and allows an adversary to potentially guess the correct value by monitoring the timing differences. + +=== Fix - Buildtime + +To fix this issue, you should use the `crypto.timingSafeEqual` method when comparing strings. This method ensures that the comparison is done in constant time. + +Secure code example: + +[source,javascript] +---- +const crypto = require('crypto'); + +function constantTimeIsPasswordEqual(userInput) { + // Retrieve the password from a secure data store such as a KMS or Hashicorp's vault. + const password = getPasswordFromSecureDataStore(); + // Use crypto timingSafeEqual to ensure the comparison is done in constant time. + return crypto.timingSafeEqual(Buffer.from(userInput, 'utf-8'), Buffer.from(password, 'utf-8')); +} +---- + +The secure version of the code above uses the `crypto.timingSafeEqual` method to compare the user's input with the secure password. This method performs the comparison in constant time, preventing timing discrepancies that could be exploited by an adversary. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-27.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-27.adoc new file mode 100644 index 000000000..9cb591b43 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-27.adoc @@ -0,0 +1,63 @@ +== Escape markup is removed leading to risk for XSS + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_27 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/79.html[CWE-79: Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting")] + +|OWASP Categories +a|https://owasp.org/Top10/A7_2017-Cross-Site_Scripting_(XSS)/[A7:2017 - Cross-Site Scripting (XSS)] + +https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy aims to flag instances where the `escapeMarkup` option is explicitly set to `false`. In some template engines, setting `escapeMarkup` to `false` would disable the escaping of HTML entities, making the application vulnerable to Cross-site Scripting (XSS) attacks. + +Example of violating code: + +[source,javascript] +---- +let template = new TemplateEngine(); +// Disabling escapeMarkup +template.escapeMarkup = false; +---- + +This code is problematic because it disables the HTML escaping feature, making it susceptible to XSS attacks. + +=== Fix - Buildtime + +To resolve this issue, do not set `escapeMarkup` to `false` or leave it at its default value, which is typically `true`. If needed, handle special cases more securely. + +Example of corrected code: + +[source,javascript] +---- +let template = new TemplateEngine(); +// Leave escapeMarkup at its default value (typically true) +// Or explicitly set it to true +template.escapeMarkup = true; +---- + +By setting `escapeMarkup` to its default value or explicitly setting it to `true`, the code ensures that HTML entities are escaped properly, mitigating the risk of XSS attacks. + diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-28.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-28.adoc new file mode 100644 index 000000000..71276f058 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-28.adoc @@ -0,0 +1,65 @@ +== CSRF is not used before `methodOverride` + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_28 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/352.html[CWE-352: Cross-Site Request Forgery (CSRF)] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy aims to prevent the misuse of Connect's `methodOverride` middleware by ensuring that `csrf` middleware is used before `methodOverride`. When using Connect, the order in which middlewares are declared determines their execution stack. If `methodOverride` is used before `csrf`, it may allow attackers to bypass standard CSRF protection mechanisms in Connect. + +Example of violating code: + +[source,javascript] +---- +const express = require('express'); +const app = express(); + +app.use(express.methodOverride()); +app.use(express.csrf()); +// other middleware and routes +---- + +In this example, the `methodOverride` middleware is used before `csrf`, which creates a security risk. + +=== Fix - Buildtime + +To resolve this issue, ensure that the `csrf` middleware is declared before the `methodOverride` middleware. + +Example of corrected code: + +[source,javascript] +---- +const express = require('express'); +const app = express(); + +app.use(express.csrf()); +app.use(express.methodOverride()); +// other middleware and routes +---- + +By ensuring that `csrf` middleware is used before `methodOverride`, the application reduces the risk of CSRF diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-29.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-29.adoc new file mode 100644 index 000000000..985c6f22c --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-29.adoc @@ -0,0 +1,57 @@ +== Calls to fs functions that take a non Literal value as the filename parameter + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_29 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ("Path Traversal")] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy detects calls to Node.js `fs` (File System) functions where the filename argument is not a literal string. Using variables in the filename argument of `fs` calls could expose the system to path traversal attacks. + +Example of violating code: + +[source,javascript] +---- +const fs = require('fs'); +let userProvidedPath = req.query.filename; +fs.readFile(userProvidedPath, 'utf8', callback); +---- + +=== Fix - Buildtime + +Ensure that all calls to `fs` functions specify the filename using a literal string or apply adequate validation and sanitization on any variable that contributes to the filename. + +Example of corrected code: + +[source,javascript] +---- +const fs = require('fs'); +let safePath = '/known/sub/directory/' + sanitize(req.query.filename); +fs.readFile(safePath, 'utf8', callback); +---- + +Here, `sanitize()` should be a function that you define to ensure that only safe paths are permitted. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-30.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-30.adoc new file mode 100644 index 000000000..b59b16c1d --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-30.adoc @@ -0,0 +1,56 @@ +== Bracket object notation with user input + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_30 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/94.html[CWE-94: Improper Control of Generation of Code ("Code Injection")] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects usages of bracket notation for object access (`$OBJ[$ARG]`) in JavaScript where the argument (`$ARG`) is not a literal or number. This usage could potentially allow an attacker to access any property of the object, including its prototype, which might lead to arbitrary code execution. + +Example of violating code: + +[source,javascript] +---- +const userProvidedKey = req.query.key; +const value = obj[userProvidedKey]; +---- + +=== Fix - Buildtime + +To resolve this issue, validate and sanitize the user-provided keys before using them to access object properties. + +Example of corrected code: + +[source,javascript] +---- +const userProvidedKey = sanitize(req.query.key); +const value = obj[userProvidedKey]; +---- + +In this example, `sanitize()` is a function that ensures only safe, whitelisted keys are used for object access. + diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-31.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-31.adoc new file mode 100644 index 000000000..97a67719f --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-31.adoc @@ -0,0 +1,56 @@ +== Insecure use of crypto.pseudoRandomBytes + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_31 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/338.html[CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects the use of `crypto.pseudoRandomBytes` in JavaScript, which produces cryptographically weak pseudo-random numbers. This method should not be used for cryptographic purposes as it can lead to vulnerabilities. + +Example of violating code: + +[source,javascript] +---- +const crypto = require('crypto'); +const buffer = crypto.pseudoRandomBytes(256); +---- + +=== Fix - Buildtime + +To resolve this issue, use a cryptographically secure method to generate random bytes. + +Example of corrected code: + +[source,javascript] +---- +const crypto = require('crypto'); +const buffer = crypto.randomBytes(256); +---- + +In this example, `crypto.randomBytes` is used, which generates a cryptographically secure random buffer. + diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-32.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-32.adoc new file mode 100644 index 000000000..af5193e68 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-32.adoc @@ -0,0 +1,59 @@ +== Creating temp tile done with insecure permissions + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_32 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/377.html[CWE-377: Insecure Temporary File] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy detects insecure temporary file creation in JavaScript. Temporary files created without secure permissions can lead to vulnerabilities like unauthorized file access or sensitive information disclosure. + +Example of violating code: + +[source,javascript] +---- +const fs = require('fs'); +fs.writeFileSync('tempfile.txt', 'some data'); +---- + +=== Fix - Buildtime + +To mitigate this issue, always specify secure file permissions when creating temporary files. Use options like `constants.S_IRUSR | constants.S_IWUSR` to set file mode securely. + +Example of corrected code: + +[source,javascript] +---- +const fs = require('fs'); +const constants = require('constants'); + +fs.writeFileSync('tempfile.txt', 'some data', { + mode: constants.S_IRUSR | constants.S_IWUSR, +}); +---- + +In this example, secure options are used for file creation, providing read and write permissions only for the owner. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-33.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-33.adoc new file mode 100644 index 000000000..dc9277c1e --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-33.adoc @@ -0,0 +1,62 @@ +== Encryption Keys are less than 16 bytes + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_33 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/326.html[CWE-326: Inadequate Encryption Strength] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects the use of encryption keys with inadequate size in JavaScript. Encryption keys with a size less than 16 bytes may pose a risk of being brute-forced, leading to vulnerabilities like unauthorized access or data breaches. + +Some common patterns this policy checks for include the usage of: +- `nacl.randomBytes` +- `randomBytes` from either the `randombytes` module or `node:crypto` +- `getBytesSync` from `node-forge` +- `cryptoRandomString` and `cryptoRandomStringAsync` +- `brorand.Rand` instances + +Example of violating code: + +[source,javascript] +---- +const nacl = require('tweetnacl'); +const key = nacl.randomBytes(8); +---- + +=== Fix - Buildtime + +To mitigate this issue, always use encryption keys that are at least 16 bytes in length. This ensures a higher degree of encryption strength, making brute-force attacks significantly more challenging. + +Example of corrected code: + +[source,javascript] +---- +const nacl = require('tweetnacl'); +const key = nacl.randomBytes(16); +---- + +In this example, an encryption key of the recommended size (16 bytes) is generated, ensuring adequate cryptographic strength. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-34.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-34.adoc new file mode 100644 index 000000000..dd5f27b21 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-34.adoc @@ -0,0 +1,61 @@ +== Hash used without salt + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_34 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/759.html[CWE-759: Use of a One-Way Hash without a Salt] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy identifies the use of cryptographic hash functions against inputs like passwords without employing a salt. Employing hashes without a salt can make systems vulnerable to certain types of attacks, such as rainbow table attacks. + +Common functions this policy checks for include: +- `crypto.pbkdf2Sync` +- `crypto.scrypt` +- `crypto.scryptSync` + +Example of violating code: + +[source,javascript] +---- +const crypto = require('crypto'); +const hashedPassword = crypto.pbkdf2Sync('userPassword', 'fixedIV', 10000, 64, 'sha512'); +---- + +=== Fix - Buildtime + +To mitigate this issue, always use a unique salt with cryptographic hash functions. Salting helps in preventing attackers from using precomputed tables to look up the hash values. + +Example of corrected code: + +[source,javascript] +---- +const crypto = require('crypto'); +const salt = crypto.randomBytes(16).toString('hex'); +const hashedPassword = crypto.pbkdf2Sync('userPassword', salt, 10000, 64, 'sha512'); +---- + +In the corrected example, a unique salt is generated and then utilized in the hashing function, ensuring the resulting hash is unique and more secure. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-35.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-35.adoc new file mode 100644 index 000000000..3a7acb82c --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-35.adoc @@ -0,0 +1,63 @@ +== Use of RSA Algorithm without Optimal Asymmetric Encryption Padding (OAEP) + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_35 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/780.html[CWE-780: Use of RSA Algorithm without OAEP] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects instances where the RSA algorithm is used without Optimal Asymmetric Encryption Padding (OAEP). Omitting OAEP can make the encryption weaker and vulnerable to certain cryptographic attacks. Padding schemes like OAEP are crucial in maintaining the strength of encryption when using algorithms like RSA. + +The policy specifically checks for the use of `publicEncrypt` and `privateEncrypt` functions with the padding set to `RSA_PKCS1_PADDING`. + +Example of violating code: + +[source,javascript] +---- +const crypto = require('crypto'); +const encrypted = crypto.publicEncrypt({ + key: publicKey, + padding: crypto.constants.RSA_PKCS1_PADDING +}, Buffer.from('sensitiveData')); +---- + +=== Fix - Buildtime + +To mitigate this issue, ensure that the RSA encryption uses OAEP for padding. OAEP is a much safer padding scheme that significantly reduces the risks associated with cryptographic attacks. + +Example of corrected code: + +[source,javascript] +---- +const crypto = require('crypto'); +const encrypted = crypto.publicEncrypt({ + key: publicKey, + padding: crypto.constants.RSA_PKCS1_OAEP_PADDING +}, Buffer.from('sensitiveData')); +---- + +In the corrected example, OAEP is used as the padding scheme for RSA encryption, ensuring that the encryption remains robust and secure. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-36.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-36.adoc new file mode 100644 index 000000000..b8cbbc481 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-36.adoc @@ -0,0 +1,59 @@ + +== Superuser port is set + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_36 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript + +|CWEs +|https://cwe.mitre.org/data/definitions/289.html[CWE-289: Authentication Bypass by Alternate Name] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects if a superuser port is set in the code. Superuser ports are reserved for privileged services and should not be used by regular applications. Using a superuser port could potentially lead to an authentication bypass vulnerability. + +Vulnerable code example: + +[source,javascript] +---- +const app = express(); +app.listen(80); +---- + +The above code is vulnerable because it sets the port to a superuser port (port 80), which is reserved for privileged services. This could allow an attacker to bypass authentication and gain unauthorized access to the application. + +=== Fix - Buildtime + +To fix the issue, the application should use a non-superuser port for communication. + +Secure code example: + +[source,javascript] +---- +const app = express(); +app.listen(3000); +---- + +The above code is no longer vulnerable because it sets the port to a non-superuser port (port 3000). Using a non-privileged port ensures that the application follows best practices and mitigates the risk of an authentication bypass. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-38.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-38.adoc new file mode 100644 index 000000000..b8d85680a --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-38.adoc @@ -0,0 +1,62 @@ +== Insecure use of weak hashing algorithms + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_38 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/328.html[CWE-328: Use of Weak Hash] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects instances in JavaScript where weak hashing algorithms are used. Leveraging weak algorithms can expose applications to vulnerabilities like hash collisions, making it easier for attackers to deduce the original input. + +Specifically, this policy checks for the use of the `createHash` and `createHmac` functions with algorithms such as: +- sha1 +- md2 +- md4 +- md5 +- ripemd160 + +Example of violating code: + +[source,javascript] +---- +const crypto = require('crypto'); +const hash = crypto.createHash('md5').update('password').digest('hex'); +---- + +=== Fix - Buildtime + +To address this issue, replace weak hashing algorithms with stronger ones, such as SHA-256 or SHA-3. Strengthening the hashing algorithm helps ensure the security of hashed data, making it more resistant to attacks. + +Example of corrected code: + +[source,javascript] +---- +const crypto = require('crypto'); +const hash = crypto.createHash('sha256').update('password').digest('hex'); +---- + +In the corrected example, a stronger hashing algorithm (SHA-256) is utilized, ensuring better cryptographic security for the hashed data. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-39.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-39.adoc new file mode 100644 index 000000000..6cdb803cc --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-39.adoc @@ -0,0 +1,67 @@ +== Use of insecure HTTP connections + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_39 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/319.html[CWE-319: Cleartext Transmission of Sensitive Information] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects the use of unsecured HTTP connections in JavaScript. Unsecured connections, such as those that start with "http://", can expose sensitive data to potential eavesdroppers or malicious entities. It's crucial to use HTTPS, which encrypts the data transmitted between the client and the server, ensuring confidentiality and integrity. + +Specific patterns this policy checks for include: +- Use of `axios` functions like `get`, `post`, `delete`, `put`, `patch`, `options`, and `create` with unsecured URLs. +- Use of the `fetch` function with unsecured URLs. +- Creation of axios instances with a base URL that starts with "http://". + +Example of violating code: + +[source,javascript] +---- +axios.get('http://example.com/data'); +---- + +or + +[source,javascript] +---- +const api = axios.create({ + baseURL: 'http://example.com' +}); +---- + +=== Fix - Buildtime + +To address this security concern, always use HTTPS for making HTTP requests. Replace "http://" with "https://" in your URLs to ensure the data transmission is encrypted. + +Example of corrected code: + +[source,javascript] +---- +axios.get('https://example.com/data'); +---- + +In the corrected example, a secure HTTPS connection is used, ensuring that the data is encrypted during transmission and protecting it from potential threats. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-40.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-40.adoc new file mode 100644 index 000000000..4020ddab8 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-40.adoc @@ -0,0 +1,61 @@ +== Use of insecure HTTP Connections with Axios + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_40 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/319.html[CWE-319: Cleartext Transmission of Sensitive Information] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects instances in JavaScript where Axios, a popular HTTP client, is used with an unsecured HTTP connection. Such unencrypted connections, which start with "http://", can expose sensitive data to potential eavesdroppers or malicious entities. For data protection, it's essential to always use HTTPS, which encrypts data transmitted between the client and server. + +The policy specifically checks for direct Axios requests where the `url` option is set to an unsecured URL. + +Example of violating code: + +[source,javascript] +---- +axios({ + method: 'get', + url: 'http://example.com/data' +}); +---- + +=== Fix - Buildtime + +To address this security concern, ensure that Axios requests are made over HTTPS. Convert "http://" URLs to "https://" to secure data transmission through encryption. + +Example of corrected code: + +[source,javascript] +---- +axios({ + method: 'get', + url: 'https://example.com/data' +}); +---- + +In the corrected example, a secure HTTPS connection is utilized, ensuring data is encrypted during transit, safeguarding it from potential threats. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-41.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-41.adoc new file mode 100644 index 000000000..fc2499660 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-41.adoc @@ -0,0 +1,61 @@ +== Insecure use of `eval` with non-string parameters + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_41 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/94.html[CWE-94: Improper Control of Generation of Code ("Code Injection")] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2021/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects the use of the `eval` function in JavaScript with parameters that are not strings. The use of `eval` can introduce significant security risks, especially when it is used with non-string parameters, as this can easily lead to code injection attacks. + +For a deeper understanding of the risks associated with `eval`, refer to the [Mozilla Developer Network documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#never_use_eval!) and the [ESLint Community Plugin](https://github.com/eslint-community/eslint-plugin-security/blob/main/rules/detect-eval-with-expression.js). + +Example of violating code: + +[source,javascript] +---- +let userCode = getUserInput(); // Potentially unsafe user input +eval(userCode); +---- + +=== Fix - Buildtime + +To mitigate this vulnerability, avoid using the `eval` function. If dynamic code execution is necessary, consider safer alternatives, validate all inputs rigorously, and ensure that only string parameters are passed to `eval`. + +Example of a safer approach: + +[source,javascript] +---- +let userCode = String(getUserInput()); // Convert to string and sanitize input +// ... additional validations ... +if(isValid(userCode)) { + eval(userCode); +} +---- + +However, even with stringent validations, the use of `eval` is generally discouraged. It's best to seek alternative methods to achieve the required functionality without dynamic code execution. + diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-42.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-42.adoc new file mode 100644 index 000000000..20ce66b6d --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-42.adoc @@ -0,0 +1,57 @@ +== Insecure use of `new Buffer()` + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_42 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/119.html[CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2004/A5-buffer-overflows/[A5:2004 - Buffer Overflows] + +|=== + +=== Description + +This policy identifies instances in JavaScript where the `new Buffer()` constructor is used with non-literal values. Such usage can lead to potential memory leaks. The `new Buffer()` constructor is considered unsafe when used with non-literal arguments, and it's recommended to use safer alternatives such as `Buffer.from()` or `Buffer.alloc()`. + +For more information about the risks and deprecation of the `new Buffer()` constructor, refer to the [Node.js documentation](https://nodejs.org/en/docs/guides/buffer-constructor-deprecation/), the [Node.js GitHub issue](https://github.com/nodejs/node/issues/4660), and the [ESLint Community Plugin](https://github.com/eslint-community/eslint-plugin-security/blob/main/rules/detect-new-buffer.js). + +Example of violating code: + +[source,javascript] +---- +let userSize = getUserInput(); // Potentially unsafe user input +let buffer = new Buffer(userSize); +---- + +=== Fix - Buildtime + +To mitigate this issue, replace the use of the `new Buffer()` constructor with safer alternatives. Preferably use `Buffer.from()` or `Buffer.alloc()` based on your specific requirements. + +Example of corrected code: + +[source,javascript] +---- +let userSize = getUserInput(); +let buffer = Buffer.alloc(parseInt(userSize, 10)); +---- + +In the corrected example, the safer `Buffer.alloc()` method is utilized, ensuring controlled memory allocation and reducing potential risks. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-74.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-74.adoc new file mode 100644 index 000000000..5ffa27e09 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-74.adoc @@ -0,0 +1,69 @@ +== Insecure communication using postMessage and event listeners + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_74 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/345.html[CWE-345: Insufficient Verification of Data Authenticity] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration[A01:2021 - Broken Access Control] + +|=== + +=== Description + +In web applications, the `postMessage` method and the `addEventListener` for `message` events are used to facilitate cross-origin communication. When misconfigured, these can lead to security vulnerabilities such as data leakage or unauthorized actions. + +One common vulnerability arises when using the wildcard origin (`*`) with the `postMessage` method. This allows any website to receive the message, potentially leading to sensitive information being exposed. + +Similarly, not verifying the origin of the message in an `addEventListener` handler can lead to processing messages from malicious sources. + +For example, vulnerable code might look like: + +[source,javascript] +---- +window.contentWindow.postMessage(data, '*'); +window.addEventListener('message', function(event) { + // Process event.data without verifying event.origin +}, false); +---- + +=== Fix - Buildtime + +To address this vulnerability: + +1. Never use a wildcard origin (`*`) with `postMessage`. Always specify the exact target origin you intend to communicate with. +2. Always check the `event.origin` in your `message` event handlers to ensure the data is coming from a trusted source. + +A more secure example would be: + +[source,javascript] +---- +const trustedOrigin = 'https://trusted.com'; + +window.contentWindow.postMessage(data, trustedOrigin); +window.addEventListener('message', function(event) { + if (event.origin !== trustedOrigin) return; + // Process event.data after verifying event.origin +}, false); +---- + +By following these practices, you can ensure that your cross-origin communication is secure, and you're only processing messages from trusted sources. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-75.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-75.adoc new file mode 100644 index 000000000..a2a80ecbb --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-75.adoc @@ -0,0 +1,69 @@ +== Encryption algorithm not using secure modes and padding + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_75 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication[A2:2021 - Cryptographic Failures] + +https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration[A6:2017 - Security Misconfiguration] + +|=== + +=== Description + +For cryptographic operations, it is crucial to use encryption modes and padding schemes that ensure the confidentiality, integrity, and authenticity of the data. When insecure modes or schemes are employed, it compromises the security of the encrypted data, leading to vulnerabilities that attackers can exploit. + +Two common pitfalls are: + +1. **Use of ECB mode:** ECB (Electronic Codebook) mode for block cipher encryption algorithms doesn’t provide adequate message confidentiality. The same plaintext block will always produce the same ciphertext block, making it unsuitable for most applications. +2. **Use of CBC with padding:** CBC (Cipher Block Chaining) with padding is vulnerable to padding oracle attacks. + +For RSA encryption, the OAEP padding scheme is recommended over older padding schemes like PKCS#1 v1.5. + +Vulnerable code might look like: + +[source,javascript] +---- +const cipher = crypto.createCipheriv('aes-128-cbc', key, iv); +const encrypted = cipher.update(plaintext); +---- + +=== Fix - Buildtime + +To enhance the security of encryption: + +1. Avoid using ECB mode for block cipher encryption algorithms. +2. Avoid CBC mode with padding because of its vulnerability to padding oracle attacks. +3. Use modes like GCM, CCM, CWC, EAX, IAPM, or OCB, which are designed to provide both data authenticity and confidentiality. +4. For RSA encryption, prefer the OAEP padding scheme. + +A secure encryption example: + +[source,javascript] +---- +const cipher = crypto.createCipheriv('aes-128-gcm', key, iv); +const encrypted = cipher.update(plaintext); +---- + +By following these practices, you can ensure that your cryptographic operations remain secure against potential attacks and vulnerabilities. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-76.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-76.adoc new file mode 100644 index 000000000..a6d825320 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-76.adoc @@ -0,0 +1,66 @@ +== Risk of Regular Expression Denial of Service (ReDoS) + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_76 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +a|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +https://cwe.mitre.org/data/definitions/400.html[CWE-400: Uncontrolled Resource Consumption] + +https://cwe.mitre.org/data/definitions/1333.html[CWE-1333: Inefficient Regular Expression Complexity] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[A3:2021 - Injection] + +https://owasp.org/www-project-top-ten/2017/A1_2017-Injection[A1:2017 - Injection] + +|=== + +=== Description + +Regular Expression Denial of Service (ReDoS) is an attack strategy that can exploit poorly crafted regular expressions to execute a denial of service (DoS) on a server. Particularly, some regex patterns are vulnerable to catastrophic backtracking situations, making them a potential target for such attacks. + +Examples of bad practices include: + +1. General bad practice, e.g. - `(\w+\s?)*$` +2. Nested quantifiers, e.g. - `(\d+)+` +3. Multiple overlapping patterns, e.g. - `(a|aa)+` +4. Grouping with repeating backreferences inside patterns with quantifiers. +5. Evil regex pattern, e.g. - `(a+)*` + +To protect against ReDoS attacks: + +1. **Never use user input directly:** Always sanitize and validate user inputs before using them in regular expressions. +2. **Use Libraries:** Utilize libraries or functions that escape regex metacharacters and sequences. This helps to ensure the regex is processed safely. +3. **Server-Side Validation:** Always validate and sanitize on the server side, not on the client-side frontend. +4. **Use Non-Backtracking Engines:** Consider using non-backtracking regex engines, such as Google's re2, to handle complex regex operations. + +=== Fix - Buildtime + +Here's how to safeguard against ReDoS attacks: + +1. **Sanitize User Input:** Ensure user input is sanitized or validated before being used in regular expressions. +2. **Avoid Catastrophic Backtracking:** Craft regular expressions that do not lead to catastrophic backtracking situations. +3. **Escape Metacharacters:** Utilize libraries or functions that escape regex metacharacters and sequences. +4. **Server-Side Over Client-Side:** Always sanitize and validate on the server side and not on the client-side frontend. +5. **Alternative Regex Engines:** Use non-backtracking regex engines like Google's re2. + +By following these best practices, you can ensure a more secure and robust application that's safeguarded against potential ReDoS attacks. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-77.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-77.adoc new file mode 100644 index 000000000..325940de5 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-77.adoc @@ -0,0 +1,72 @@ +== Weak SSL/TLS protocols + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_77 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Inadequate Encryption Strength] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2021/A02_2021-Cryptographic_Failures[A2:2021 - Cryptographic Failures] + +https://owasp.org/www-project-top-ten/2021/A07_2021-Identification_and_Authentication_Failures[A7:2021 - Identification and Authentication Failures] + +https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[A3:2017 - Sensitive Data Exposure] + +https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration[A6:2017 - Security Misconfiguration] + +|=== + +=== Description + +To ensure the confidentiality and integrity of data during transmission, it's imperative to use secure SSL/TLS protocol versions. Outdated or insecure versions, such as TLSv1.0 or TLSv1.1, contain vulnerabilities that attackers can exploit. + +Relying on system defaults for selecting the protocol version may lead to non-compliance with industry standards and best practices. To safeguard against potential attacks, you should always explicitly set your protocol versions in configurations. + +Vulnerable code example: + +[source,javascript] +---- +const serverOptions = { + secureProtocol: 'TLSv1_0_method' +}; +const server = https.createServer(serverOptions, app); +---- + +=== Fix - Buildtime + +To achieve secure data transmission: + +1. Review configurations and ensure that the protocol versions are set to at least TLSv1.2. +2. Avoid using insecure protocol versions. +3. Do not rely on system or library defaults. Be explicit in your configurations. +4. Periodically review and update configurations to match evolving security best practices and standards. + +Secure encryption example: + +[source,javascript] +---- +const serverOptions = { + secureProtocol: 'TLSv1_2_method' +}; +const server = https.createServer(serverOptions, app); +---- + +By adhering to these guidelines, you ensure secure communication channels, reducing the risk of data breaches and man-in-the-middle attacks. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-78.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-78.adoc new file mode 100644 index 000000000..cb02733b1 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-78.adoc @@ -0,0 +1,83 @@ +== Restrict Unnecessary Powerful Browser Features + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_78 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +a|https://cwe.mitre.org/data/definitions/250.html[CWE-250: Execution with Unnecessary Privileges] + +https://cwe.mitre.org/data/definitions/359.html[CWE-359: Exposure of Private Information] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2021/A01_2021-Broken_Access_Control[A1:2021 - Broken Access Control] + +https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[A3:2017 - Sensitive Data Exposure] + +|=== + +=== Description + +Browser features like geolocation, camera, and microphone offer vast functionalities but come with inherent security and privacy implications. These features are accessible through JavaScript APIs and often require user permissions. While these permissions might be essential for certain applications, they can be misused or exploited by attackers if not properly managed. + +When unnecessary access to these features is allowed, it can lead to situations where sensitive information is exposed or where the application operates with more privileges than required, leading to potential security vulnerabilities. + +Vulnerable code example: + +[source,javascript] +---- +// Querying for geolocation permission +navigator.permissions.query({name: "geolocation"}).then(response => { + if (response.state == 'granted') { + // Access granted + } else { + // Access denied + } +}); +---- + +=== Fix - Buildtime + +To ensure the safety of user data: + +1. Only request access to powerful browser features when absolutely necessary. +2. Do not request permissions upfront. Instead, ask for them contextually when the user triggers the feature. +3. Always inform users why a particular permission is needed, ensuring transparency. +4. Periodically review your application to check for redundant permissions and remove them. + +Secure practice example: + +[source,javascript] +---- +// Only query for geolocation when a user action requires it +function getLocation() { + if ("geolocation" in navigator) { + navigator.geolocation.getCurrentPosition(position => { + // Use the position data + }); + } else { + // Handle no geolocation scenario + } +} + +// This function should only be triggered when the user explicitly requests a feature that needs geolocation +document.querySelector("#getLocationButton").addEventListener('click', getLocation); +---- + +By following these guidelines, you ensure that you respect user privacy and minimize the potential attack surface of your application. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-79.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-79.adoc new file mode 100644 index 000000000..1df27ffe9 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-79.adoc @@ -0,0 +1,79 @@ +== Prevent Public Network Access to Cloud Resources + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_79 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +a|https://cwe.mitre.org/data/definitions/284.html[CWE-284: Improper Access Control] + +https://cwe.mitre.org/data/definitions/668.html[CWE-668: Exposure of Resource to Wrong Sphere] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2021/A01_2021-Broken_Access_Control[A1:2021 - Broken Access Control] + +https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control[A5:2017 - Broken Access Control] + +|=== + +=== Description + +The cloud offers vast scalability and reach, but with this convenience comes security implications. One common pitfall is exposing cloud services directly to the Internet without sufficient security controls. Such exposures can lead to unauthorized access, data breaches, and a variety of other malicious activities. + +For many services, especially databases or backend servers, there's no need to have public Internet access. They can be contained within a private network or VPC and communicate via internal routes, improving their security posture. + +Vulnerable code example: + +[source,javascript] +---- +// Creating an EC2 instance in a public subnet +const instance = new ec2.Instance(stack, 'Instance', { + vpcSubnets: { + subnetType: ec2.SubnetType.PUBLIC + } +}); +---- + +=== Fix - Buildtime + +To minimize the risk of exposure: + +1. Avoid deploying cloud services on public subnets or with public IP addresses unless it's a requirement. +2. Utilize private networks or VPCs for internal services. +3. Use secure communication methods like VPC peering for inter-service communication. +4. If a service does not support a no-public-IP configuration, ensure it does not listen on the public IP. + +Secure code example: + +[source,javascript] +---- +// Creating an EC2 instance in a private subnet +const instance = new ec2.Instance(stack, 'Instance', { + vpcSubnets: { + subnetType: ec2.SubnetType.PRIVATE + } +}); + +// Ensuring a DMS replication instance is not publicly accessible +const replicationInstance = new dms.CfnReplicationInstance(stack, 'ReplicationInstance', { + publiclyAccessible: false +}); +---- + +By adhering to these best practices, you can significantly reduce the risk of unauthorized access to your cloud resources. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-80.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-80.adoc new file mode 100644 index 000000000..bf07b3d0e --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-80.adoc @@ -0,0 +1,63 @@ +== Enforce HTTPS Access for S3 Buckets + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_80 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|JavaScript + +|CWEs +|https://cwe.mitre.org/data/definitions/319.html[CWE-319: Cleartext Transmission of Sensitive Information] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2021/A2_2021-Cryptographic_Failures[A2:2021 - Cryptographic Failures] + +https://owasp.org/www-project-top-ten/2021/A5_2021-Security_Misconfiguration[A5:2021 - Security Misconfiguration] + +https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[A3:2017 - Sensitive Data Exposure] + +https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration[A6:2017 - Security Misconfiguration] + +|=== + +=== Description + +Amazon S3 is a widely used object storage service. By default, S3 buckets can be accessed using both HTTP and HTTPS protocols. Although HTTPS encrypts the transmission, HTTP does not, leaving the data vulnerable to interception, eavesdropping, and man-in-the-middle attacks. + +Using HTTPS ensures that the data is encrypted during transit, safeguarding against potential interceptions and offering a more secure method for data transfer. + +Vulnerable code example: + +[source,javascript] +---- +const myBucket = new s3.Bucket(stack, 'MyBucket'); +---- + +=== Fix - Buildtime + +Always ensure that S3 buckets are accessed exclusively via HTTPS. This can be enforced by setting the `enforceSSL` property to `true` during the S3 bucket creation. + +Secure code example: + +[source,javascript] +---- +const myBucket = new s3.Bucket(stack, 'MyBucket', { + enforceSSL: true +}); +---- + +By enforcing HTTPS for your S3 buckets, you significantly enhance the security of your data during transit. diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-81.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-81.adoc new file mode 100644 index 000000000..c2243dd79 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-81.adoc @@ -0,0 +1,57 @@ +== Prevent OS Command Argument Injections + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_81 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript + +|CWEs +a|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +https://cwe.mitre.org/data/definitions/88.html[CWE-88: Argument Injection or Modification] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A3:2021 - Injection] + +|=== + +=== Description + +This policy detects potential OS command argument injections in JavaScript code. + +Vulnerable code example: + +[source,javascript] +---- +child_process.exec('ls ' + userInput); +---- + +=== Fix - Buildtime + +To fix this issue, you should ensure that untrusted data is never used as arguments in operating system commands. Instead, use the language's native SDK to accomplish the desired tasks. + +Secure code example: + +[source,javascript] +---- +const { exec } = require('child_process'); + +// Securely execute the command +exec('ls', [userInput]); +---- + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-83.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-83.adoc new file mode 100644 index 000000000..460e373af --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-83.adoc @@ -0,0 +1,57 @@ +== Complex/formatted SQL query + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_83 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|javascript + +|CWEs +a|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +https://cwe.mitre.org/data/definitions/89.html[CWE-89: Improper Neutralization of Special Elements used in an SQL Command] + +|=== + +=== Description + +This policy detects complex or formatted SQL queries that increase the risk of SQL injection. It advises avoiding these and opting for safer alternatives like parameterized queries, prepared statements, or ORM frameworks. It ensures that no query uses direct concatenation of untrusted values. + +Vulnerable code example: + +[source,javascript] +---- +const query = 'SELECT * FROM users WHERE id = ' + req.params.id; +db.query(query, (err, result) => { + // handle result +}); +---- + +=== Fix - Buildtime + +To fix the issue, you should use parameterized queries or prepared statements instead of direct concatenation. It helps to prevent SQL injection attacks by separating the SQL code from the user input. + +Secure code example: + +[source,javascript] +---- +const query = 'SELECT * FROM users WHERE id = ?'; +db.query(query, [req.params.id], (err, result) => { + // handle result +}); +---- + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-84.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-84.adoc new file mode 100644 index 000000000..431b101a5 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-84.adoc @@ -0,0 +1,51 @@ + +== AngularJS misconfiguration dangerous protocol allowed + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_84 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|javascript + +|CWEs +|https://cwe.mitre.org/data/definitions/554.html[CWE-554: ASP.NET Misconfiguration: Not Using Input Validation Framework] + + +|=== + +=== Description + +This SAST policy detects AngularJS misconfigurations where dangerous protocols, such as "javascript", are allowed. Allowing "javascript" as an allowed protocol can lead to cross-site scripting (XSS) vulnerabilities. + +Vulnerable code example: + +[source,javascript] +---- +$scope.imgSrcSanitizationWhitelist('javascript:alert("XSS")'); +---- + +=== Fix - Buildtime + +To fix this issue, update the AngularJS configuration to exclude dangerous protocols like "javascript" from the allowed list. + +Secure code example: + +[source,javascript] +---- +$scope.imgSrcSanitizationWhitelist('https://example.com/image.jpg'); +---- + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-85.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-85.adoc new file mode 100644 index 000000000..eb24843af --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-85.adoc @@ -0,0 +1,56 @@ + +== AngularJS Misconfiguration Strict Contextual Escaping Disabled + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_85 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript + +|CWEs +|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 Injection] + +|=== + +=== Description + +This SAST policy detects instances where the AngularJS framework's Strict Contextual Escaping (SCE) is disabled, which can potentially lead to cross-site scripting (XSS) vulnerabilities. + +Vulnerable code example: + +[source,javascript] +---- +angular.module('myApp', []).config(($sceProvider) => $sceProvider.enabled(false)); +---- + +In the above code, the `config` function of the AngularJS module is used to disable the Strict Contextual Escaping, which allows insecure injection of user-controlled content into the application. + +=== Fix - Buildtime + +To fix this issue, you should avoid disabling the Strict Contextual Escaping in your AngularJS application. Instead, you should enable and use proper input validation and sanitization techniques to prevent XSS vulnerabilities. + +Secure code example: + +[source,javascript] +---- +angular.module('myApp', []).config(($sceProvider) => $sceProvider.enabled(true)); +---- + + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-92.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-92.adoc new file mode 100644 index 000000000..eccdf56c2 --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-92.adoc @@ -0,0 +1,59 @@ +== Detection of XSS vulnerability + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_92 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|javascript + +|CWEs +|https://cwe.mitre.org/data/definitions/554.html[CWE-554: ASP.NET Misconfiguration: Not Using Input Validation Framework] + +|OWASP Categories +| + +|=== + +=== Description + +This SAST policy detects the usage of the Express framework without the Helmet framework for protection against XSS (Cross-Site Scripting) attacks. + +Vulnerable code example: + +[source,javascript] +---- +const express = require('express'); +---- + +The above code is vulnerable because it initializes the Express framework without using the Helmet framework for securing against XSS attacks. + +=== Fix - Buildtime + +To fix the issue, the code should be modified to include the Helmet framework for XSS protection. + +Secure code example: + +[source,javascript] +---- +const express = require('express'); +const helmet = require('helmet'); + +app.use(helmet()); +---- + +The secure code includes the Helmet framework by requiring it and using it with the Express framework. This way, the application is protected against XSS attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-95.adoc b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-95.adoc new file mode 100644 index 000000000..3a61f861c --- /dev/null +++ b/application-security/policy-reference/sast-policies/javascript-policies/sast-policy-95.adoc @@ -0,0 +1,57 @@ + +== Cookie Security Overly Permissive Samesite Attribute + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_95 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|javascript + +|CWEs +|https://cwe.mitre.org/data/definitions/352.html[CWE-352: Cross-Site Request Forgery (CSRF)] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects code that sets the Samesite cookie attribute to either "Lax" or "None" and does not enable the secure flag. This can lead to cross-site request forgery (CSRF) attacks. + +Vulnerable code example: + +[source,javascript] +---- +document.cookie = "session=abc; SameSite=Lax"; +---- + +The vulnerable code example sets the Samesite attribute of the cookie to "Lax" but does not enable the secure flag. This means that the cookie can be sent over insecure HTTP connections, making it vulnerable to CSRF attacks. + +=== Fix - Buildtime + +To fix this issue, you should set the Samesite cookie attribute to "Strict" and enable the secure flag. + +Secure code example: + +[source,javascript] +---- +document.cookie = "session=abc; SameSite=Strict; Secure"; +---- + +In the secure code example, the Samesite attribute of the cookie is set to "Strict" and the secure flag is enabled. This ensures that the cookie will only be sent over secure HTTPS connections, reducing the risk of CSRF attacks. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-10.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-10.adoc new file mode 100644 index 000000000..8ccb1d804 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-10.adoc @@ -0,0 +1,66 @@ +== Encryption keys below 2048 bit + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_10 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/326.html[CWE-326: Inadequate Encryption Strength] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures[A02:2021 - Cryptographic Failures] + +|=== + + + +=== Description + +The warning is about the use of encryption keys that are too small. According to guidelines from the National Institute of Standards and Technology (NIST), RSA and DSA keys should be 2048 bits or larger. Smaller keys are considered to be weak and can be broken with sufficient computational power, which could potentially allow an attacker to decrypt your data or impersonate your users. + +Here's an example of violating code: + +[source,python] +---- +from cryptography.hazmat.primitives.asymmetric import rsa + +private_key = rsa.generate_private_key( + public_exponent=65537, + key_size=1024 # This key size is too small. +) +---- + +In this code, the key size of 1024 is smaller than the recommended minimum of 2048, which makes the key weak. + +=== Fix - Buildtime + +To fix this issue, you simply need to use a larger key size when generating your keys: + +[source,python] +---- +from cryptography.hazmat.primitives.asymmetric import rsa + +private_key = rsa.generate_private_key( + public_exponent=65537, + key_size=2048 # This key size is sufficiently large. +) +---- + +In this revised code, the key size is 2048, which meets the NIST recommendations for key size. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-100.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-100.adoc new file mode 100644 index 000000000..8957c1687 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-100.adoc @@ -0,0 +1,65 @@ + +== Improper Check or Handling of Exceptional Conditions + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_100 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/703.html[CWE-703: Improper Check or Handling of Exceptional Conditions] + + +|=== + +=== Description + +This policy detects instances where there is improper handling of exceptional conditions in Python code. It checks for the use of a try-except block with a generic exception type and a pass statement. + +Vulnerable code example: + +[source,python] +---- +try: + # Any code that may raise an exception +except Exception: + pass +---- + +The above code is vulnerable because it catches all types of exceptions without any specific handling. This can lead to potential issues such as hiding critical errors or mistakenly ignoring unexpected exceptions. + +=== Fix - Buildtime + +To fix this issue, it is recommended to either handle specific exceptions or include appropriate error handling code within the except block. + +Secure code example: + +[source,python] +---- +try: + # Any code that may raise an exception +except ValueError: + # Handle specific exception + print("Invalid value error occurred.") +except FileNotFoundError as e: + # Handle specific exception + print(f"File not found: {e.filename}") +---- + +The secure code example demonstrates the use of specific exception types within the except block. By handling specific exceptions, the code can perform appropriate actions based on the type of exception encountered. This ensures more robust and reliable error handling. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-11.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-11.adoc new file mode 100644 index 000000000..b9509cf74 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-11.adoc @@ -0,0 +1,58 @@ +== Use of module setting superuser port + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_11 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/289.html[CWE-289: Authentication Bypass by Alternate Name] + + +|=== + + + +=== Description + +This issue arises when your Python script tries to bind a socket to a port number below 1024, which are known as "privileged ports". Only root or a user with appropriate privileges can bind to these ports. This may indicate a situation where your application is running with more privileges than necessary, which is a security concern. + +Here's an example of violating code: + +[source,python] +---- +def set_port(port): + # some code that binds to the port + +set_port(80) # This is a privileged port +---- + +The code is trying to bind to port 80, which is a privileged port. This means that the script must be running with root or elevated privileges. + +To fix the issue, you should avoid using privileged ports unless absolutely necessary: + +[source,python] +---- +def set_port(port): + # some code that binds to the port + +set_port(8080) # This is a non-privileged port +---- + +In the revised code, we're using port 8080, which is a non-privileged port. The script can bind to this port without needing extra privileges. This reduces the potential security risk. If your application requires the use of privileged ports, you should consider using a reverse proxy setup, which allows the application to run without elevated privileges. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-152.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-152.adoc new file mode 100644 index 000000000..c39470d7e --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-152.adoc @@ -0,0 +1,66 @@ +== Hardcoded passwords are being used + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_152 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/798.html[CWE-798: Use of Hard-coded Credentials] + +|OWASP Categories +|https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[A07:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +The SAST policy detects the use of hardcoded passwords as default arguments in certain Flask or FastAPI routes or functions. This is considered a security vulnerability because hardcoded passwords can be easily obtained by attackers, compromising the authentication system. + +Vulnerable code example: + +[source,python] +---- +@app.route('/login') +def login(password='admin'): + if password == GLOBAL_DICT.get('admin'): + # do something + # do something else +---- + +In the above code, the `login` function has a default password argument of 'admin'. This means that if a real password is not supplied when calling the function, it falls back to the hardcoded password 'admin'. An attacker could potentially discover this password and gain unauthorized access. + +=== Fix - Buildtime + +To fix this issue, it is recommended to remove the hardcoded password and implement a secure authentication mechanism. One possible approach is to use a secure password storage mechanism, such as hashing the passwords and comparing the hashes instead of plaintext. + +Secure code example: + +[source,python] +---- +@app.route('/login') +def login(password=None): + if password and password == GLOBAL_DICT.get('admin'): + # do something + # do something else +---- + +In the fixed code, the default password argument has been changed to `None`, indicating that if no password is provided, it will not automatically fall back to a hardcoded value. Additionally, the code now checks if the `password` variable is not empty before comparing it with the stored password in `GLOBAL_DICT`. This ensures that only valid passwords are accepted. + +By implementing these changes, the code no longer relies on hardcoded passwords and provides a more secure authentication mechanism. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-154.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-154.adoc new file mode 100644 index 000000000..de066cedd --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-154.adoc @@ -0,0 +1,65 @@ +== Unsanitized path input from an HTTP parameter is being opened + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_154 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/79.html[CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy ensures that unsanitized path input from an HTTP parameter is not being opened. Opening unsanitized input can lead to a path traversal attack, where an attacker could potentially access, read, or even overwrite sensitive files on the server. To avoid this vulnerability, the input should be validated before using it, to ensure it adheres to the expected format. + +Vulnerable code example: + +[source,python] +---- +path = flask.request.args.get('path') +file = open(path, 'r') +---- + +In the above code, the value of the 'path' parameter from the HTTP request is directly used without any validation. This allows an attacker to control the value of 'path' and potentially traverse to any file on the server, leading to a path traversal vulnerability. + +=== Fix - Buildtime + +To fix this issue, the input should be validated before opening it. One way to achieve this is by using a whitelist approach, where only allowed paths are accepted. Here's an example of secure code: + +[source,python] +---- +ALLOWED_PATHS = ['/var/www/html', '/home/user'] + +path = flask.request.args.get('path') +if path in ALLOWED_PATHS: + file = open(path, 'r') +else: + # Handle invalid path input + # Return an appropriate error message or handle the exception + ... +---- + +In the secure code, the 'path' parameter is checked against a list of allowed paths (e.g., `/var/www/html`, `/home/user`). Only if the 'path' value is in the list of allowed paths, the file is opened. Otherwise, the code handles the invalid path input appropriately, such as returning an error message or handling the exception. + +By validating and restricting the input based on a whitelist, the code prevents path traversal attacks and ensures that only authorized paths are opened. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-166.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-166.adoc new file mode 100644 index 000000000..eee331bba --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-166.adoc @@ -0,0 +1,69 @@ + +== Improper Check or Handling of Exceptional Conditions + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_166 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/703.html[CWE-703: Improper Check or Handling of Exceptional Conditions] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects instances where there is improper check or handling of exceptional conditions. It looks for code that uses a try-except block and immediately continues execution inside the except block, without properly addressing or handling the exceptional condition. + +Vulnerable code example: + +[source,python] +---- +try: + # Some code that may raise an exception +except Exception: + continue +---- + +The above code is vulnerable because it captures all exceptions using a broad "Exception" class and simply continues execution without any proper handling or logging of the exception. This can result in unhandled exceptions and unexpected behavior in the application. + +=== Fix - Buildtime + +To fix this issue, it is important to appropriately handle the exceptional condition. This involves: + +- Identifying the specific exception(s) that may be raised within the try block. +- Implementing appropriate error handling or recovery logic within the except block. +- Properly logging or reporting the exception for debugging purposes. + +Secure code example: + +[source,python] +---- +try: + # Some code that may raise an exception +except SpecificException as e: + # Handle the specific exception + log_error(e) + # Take necessary actions to recover from the exception +---- + +In the secure code example, the specific exception type (e.g., "SpecificException") is caught in the except block, allowing for proper handling and recovery. The example also includes logging the error for debugging purposes, and taking necessary actions to recover from the exception, instead of simply continuing execution. This ensures that exceptional conditions are properly addressed and the application can maintain its expected behavior. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-167.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-167.adoc new file mode 100644 index 000000000..201827e68 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-167.adoc @@ -0,0 +1,61 @@ + +== Use of Insufficiently Random Values + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_167 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/330.html[CWE-330: Use of Insufficiently Random Values] + +|OWASP Categories +|https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +This policy detects the use of insufficiently random values in Python code. It specifically looks for the usage of the `random` module's non-secure pseudo-random number generator functions. + +Vulnerable code example: + +[source,python] +---- +import random + +password = "secret_" + str(random.randint(1, 100)) +---- + +The above code is vulnerable because it uses the `random.randint` function from the `random` module, which is a non-secure pseudo-random number generator. This type of generator is not suitable for security or cryptographic purposes as it can be easily predicted or brute-forced. + +=== Fix - Buildtime + +To fix the vulnerability, you should use the `random.SystemRandom()` function instead, which is based on the underlying operating system's random source and provides a more secure random number generator. + +Secure code example: + +[source,python] +---- +import random + +password = "secret_" + str(random.SystemRandom().randint(1, 100)) +---- + +The above code is no longer vulnerable because it uses the `random.SystemRandom().randint` function, which uses the operating system's random source to generate more secure random numbers. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-168.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-168.adoc new file mode 100644 index 000000000..9c3a52bc6 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-168.adoc @@ -0,0 +1,65 @@ + +== Improper Control of Generation of Code ('Code Injection') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_168 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/94.html[CWE-94: Improper Control of Generation of Code ('Code Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects the usage of the `logging.config.listen()` function in Python, which can potentially introduce code injection vulnerabilities. The `logging.config.listen()` function allows the application to listen for external configuration files on a socket server. However, portions of the configuration passed through the `eval()` function, making it susceptible to code injection. + +Vulnerable code example: + +[source,python] +---- +import logging.config + +logging.config.listen(('localhost', 8080)) +---- + +In the above code, the `logging.config.listen()` function is called without proper validation or sanitization of the input. This can allow malicious code to be injected through the socket connection, leading to potential security risks. + +=== Fix - Buildtime + +To fix this issue, you should avoid using the `logging.config.listen()` function or ensure that the input passed to it is properly validated and sanitized. Instead, consider using a more secure method for external configuration. + +Secure code example: + +[source,python] +---- +import logging.config + +# Validate and sanitize the input before passing it to logging.config.listen() +socket_address = ('localhost', 8080) +logging.config.listen(socket_address, verify=True, encryption=True) +---- + +In the secure code example, we explicitly validate and sanitize the input before passing it to the `logging.config.listen()` function. Additionally, we use the `verify` and `encryption` parameters to enhance the security of the socket connection, providing integrity checks and encryption/decryption capabilities. + +By properly validating and sanitizing the input and using additional security measures, the potential for code injection vulnerabilities is significantly reduced. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-169.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-169.adoc new file mode 100644 index 000000000..29ad721bb --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-169.adoc @@ -0,0 +1,69 @@ + +== Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_169 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This policy detects instances where the `tarfile.extractall` method is used without any validation, which can lead to a Path Traversal vulnerability. + +Vulnerable code example: + +[source,python] +---- +import tarfile + +tar = tarfile.open('archive.tar') +tar.extractall('/path/to/extract/directory') +tar.close() +---- + +The above code is vulnerable because it extracts all files from the `archive.tar` file into the `/path/to/extract/directory` without validating the paths of the files being extracted. This can allow an attacker to specify paths that traverse outside of the intended directory and potentially overwrite or access sensitive files on the system. + +=== Fix - Buildtime + +To fix this issue, you should validate and sanitize the paths of the files being extracted from the tar archive. One way to do this is by using the `getnames()` method of the `TarFile` object to obtain a list of all member names and comparing them against a whitelist of allowed paths. + +Secure code example: + +[source,python] +---- +import tarfile + +tar = tarfile.open('archive.tar') +allowed_paths = ['/path/to/extract/directory', '/path/to/other/allowed/directory'] +for member in tar.getmembers(): + if member.name.startswith('/') and not any(member.name.startswith(allowed_path) for allowed_path in allowed_paths): + raise Exception("Invalid file path: {}".format(member.name)) +tar.extractall('/path/to/extract/directory') +tar.close() +---- + +In the secure code example, a whitelist of allowed paths (`allowed_paths`) is defined, and each member name from the tar archive is checked against this whitelist before extracting the files. If a member has a path that does not start with any of the allowed paths, an exception is raised. This ensures that only files within the specified directories are extracted and prevents path traversal vulnerabilities. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-170.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-170.adoc new file mode 100644 index 000000000..edea16b54 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-170.adoc @@ -0,0 +1,68 @@ + +== Improper Neutralization of Wildcards or Matching Symbols + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_170 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/155.html[CWE-155: Improper Neutralization of Wildcards or Matching Symbols] + + +|=== + +=== Description + +This policy detects the use of the wildcard character in a system call that spawns a shell. When a wildcard is used in a system call, it is subject to normal shell expansion, which can have unintended consequences if there exist any non-standard file names. + +Vulnerable code example: + +[source,python] +---- +import os + +command = "ls " + user_input + "/*.txt" +os.system(command) +---- + +In the above code, the user input is directly concatenated with a command to list all files with a .txt extension using the wildcard character *. This code is vulnerable because the user can provide a malicious input that contains special characters or parameters that can manipulate the shell behavior. + +=== Fix - Buildtime + +To fix this issue, you should properly sanitize and validate the user input before using it in any system call. Use strict input validation to ensure that the user-provided input does not contain any special characters or malicious parameters. + +Secure code example: + +[source,python] +---- +import os +import re + +user_input = input("Enter a directory: ") +if re.match("^[a-zA-Z0-9/]*$", user_input): + command = "ls " + user_input + "/*.txt" + os.system(command) +else: + print("Invalid directory input.") +---- + +In the secure code example, the user input is validated using a regular expression that allows only alphanumeric characters and slashes (/). If the input passes the validation, it is safe to use in the system call. Otherwise, an error message is displayed indicating invalid directory input. + +By properly validating the user input, the wildcard character is no longer vulnerable to shell expansion and unintended consequences. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-2.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-2.adoc new file mode 100644 index 000000000..7bb400f05 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-2.adoc @@ -0,0 +1,76 @@ +== Unsafe use of 'exec' command + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_2 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/78.html[CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + + + +=== Description + +The `exec()` function in Python is a built-in function that is used to execute dynamically created program, which can be a string or object code. Using `exec()` can make your code susceptible to a number of security risks: + +1. Code Injection: The most significant risk with `exec()` is that it can execute arbitrary code. This opens up the possibility for an attacker to inject malicious code into your program. + +2. Debugging: Debugging issues can become difficult because the behaviour of `exec()` can depend on the runtime environment and the exact input being executed. + +3. Performance: The `exec()` function is slow as it needs to parse and compile the code each time it's called. + +Here's an example of code that might trigger this warning: + +[source,python] +---- +command = input("Enter a command: ") +exec(command) +---- + +In this example, an attacker could input Python code that deletes files, accesses sensitive data, or makes network requests. + +=== Fix - Buildtime + +To fix it, it's often possible to replace the use of `exec()` with other techniques. If you're using `exec()` to call functions, you can replace it with a dictionary of functions. If you're using it for expressions, you might be able to use `eval()` (but be aware that `eval()` has its own security implications and should also be used very carefully). + +For example, if you want to call a function based on a string, you can do it like this: + +[source,python] +---- +def func1(): + print("Function 1 was called") + +def func2(): + print("Function 2 was called") + +functions = {"func1": func1, "func2": func2} + +command = input("Enter a command: ") + +if command in functions: + functions[command]() +---- + +This way, the program only allows specific, pre-determined commands, which reduces the risk of arbitrary code execution. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-3.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-3.adoc new file mode 100644 index 000000000..06369d9c1 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-3.adoc @@ -0,0 +1,57 @@ +== chmod sets a permissive mask on file + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_3 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/732.html[CWE-732: Incorrect Permission Assignment for Critical Resource] + +|=== + + + +=== Description + +The `os.chmod()` function in Python is used to change the permissions of a file or directory. The permissions determine who can read, write, and execute the file or directory. + +`os.chmod()` is being used to set a permissive mask on a file. This means that the file permissions are being set in a way that allows potentially unsafe access to the file. For example, setting the permissions to allow any user to write to or execute the file would be considered permissive. + +Here's an example of violating code: + +[source,python] +---- +import os +os.chmod('sensitive_file.txt', 0o777) # Insecure: allows read, write, and execute access to all users +---- + +In this example, `os.chmod()` is setting the permissions for 'sensitive_file.txt' to '777' in octal notation, which corresponds to full read, write, and execute permissions for the owner, group, and others (i.e., all users). This is considered permissive and insecure because any user on the system can read, modify, or execute the file. + +=== Fix - Buildtime + +To fix this issue, you should set more restrictive permissions. It's common to give the owner of the file read and write permissions, and only read permissions to the group and others: + +[source,python] +---- +import os +os.chmod('sensitive_file.txt', 0o644) # More secure: owner can read and write, others can only read +---- + +In this fixed code, '644' in octal notation corresponds to read and write permissions for the owner, and read-only permissions for the group and others. Always aim to set the least permissive access controls that will still allow your application to function correctly. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-37.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-37.adoc new file mode 100644 index 000000000..4800223dd --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-37.adoc @@ -0,0 +1,61 @@ +== Use of insecure IPMI-related modules + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_37 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/310.html[CWE-310: Cryptographic Issues] + + +|=== + +=== Description + +This policy detects the import and usage of modules related to IPMI (Intelligent Platform Management Interface) in Python. IPMI is considered insecure due to potential cryptographic vulnerabilities, and it's recommended to use an encrypted protocol in its place. + +Specifically, the policy checks for the import of modules such as: +- pyghmi +- pyIPMI +- freeIPMI +- ipmi-utils +- pyIPMItool +- python-ipmi +- ipmi + +Example of violating code: + +[source,python] +---- +import pyghmi.session +---- + +or + +[source,python] +---- +from pyIPMI import session +---- + +=== Fix - Buildtime + +To address this issue, refrain from using IPMI-related modules in your codebase. Instead, opt for secure and encrypted protocols or libraries that offer a higher level of security. + +Consider researching and identifying an appropriate encrypted alternative that fits your application's requirements. + diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-4.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-4.adoc new file mode 100644 index 000000000..9ec515624 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-4.adoc @@ -0,0 +1,63 @@ +== Improper handling of checking for unusual or exceptional conditions + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_4 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/754.html[CWE-754: Improper Check for Unusual or Exceptional Conditions] + +|=== + + + +=== Description + +The `assert` statement in Python is used for debugging purposes. It lets you test if a certain condition is met, and if not, the program will raise an `AssertionError` exception. + +The main problem with `assert` is that it can be globally disabled with the `-O` (optimize) option in Python, or by setting the environment variable `PYTHONOPTIMIZE` to a non-empty string. This means that when Python code is run in optimized mode, all `assert` statements are ignored. + +Therefore, if you're using `assert` to check for conditions that should prevent the program from continuing (for example, validating user input or checking configuration files), those checks will be skipped in optimized mode, which could lead to incorrect program behavior or even security vulnerabilities. + +Here is an example of problematic code: + +[source,python] +---- +def process_data(data): + assert data is not None, "Data must not be None" + # Continue with processing... +---- + +In this code, if Python is run with optimization enabled, the `assert` statement will be ignored, and the `process_data` function will proceed even if `data` is `None`, which could cause errors later on. + +=== Fix - Buildtime + +To fix this issue, you should replace `assert` statements with proper error handling using exceptions: + +[source,python] +---- +def process_data(data): + if data is None: + raise ValueError("Data must not be None") + # Continue with processing... +---- + +In this revised code, a `ValueError` will be raised if `data` is `None`, regardless of whether Python is running in optimized mode or not. The `ValueError` exception cannot be disabled or ignored in the same way as `assert` statements. This makes your program safer and more predictable. + diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-48.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-48.adoc new file mode 100644 index 000000000..24956c4a5 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-48.adoc @@ -0,0 +1,64 @@ + +== Unsanitized input from data from a remote resource flows into os.system + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_48 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/78.html[CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects when unsanitized input from a remote resource is used as a command in `os.system` in Python code, which can lead to a Command Injection vulnerability. + +Vulnerable code example: + +[source,python] +---- +import os +data = request.args.get("input") +os.system(data) +---- + +The above code is vulnerable because it takes user input from the `request.args.get()` function and directly passes it to `os.system`, without any sanitization or validation. An attacker can manipulate the input to execute arbitrary commands on the underlying system. + +=== Fix - Buildtime + +To fix the issue, it is recommended to properly validate and sanitize the input before using it as a shell command. One way to achieve this is by using a dedicated command execution function that allows you to pass the command and arguments separately. + +Secure code example: + +[source,python] +---- +import os +import shlex + +data = request.args.get("input") +command = "echo " + shlex.quote(data) +os.system(command) +---- + +In the secure code example, the input is properly sanitized using the `shlex.quote()` function, which ensures that any special characters or spaces are properly escaped. The command is constructed separately from the input, reducing the risk of command injection. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-5.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-5.adoc new file mode 100644 index 000000000..74aa42e60 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-5.adoc @@ -0,0 +1,71 @@ +== Publicly exposed servers + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_5 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/200.html[CWE-200: Exposure of Sensitive Information to an Unauthorized Actor] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + + + +=== Description + +Binding a server to "0.0.0.0", "::", or an empty string using Python's `socket.bind` means that the server will accept connections on all available network interfaces. This includes not only the localhost interface, but also any other network interfaces that your machine may have. + +In other words, binding to these addresses could expose your server to the internet, which can be a significant security risk if your server is not designed to be exposed to the public internet, or if it has not been properly secured. This could allow unauthorized users to interact with your server, potentially leading to a range of security issues. + +Here is an example of code that would violate this policy: + +[source,python] +---- +import socket + +s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) +s.bind(('0.0.0.0', 8000)) +s.listen() +---- + +In this code, the socket is bound to '0.0.0.0' on port 8000, which means it will accept connections from any network interface on port 8000. + +=== Fix - Buildtime + +To fix this issue, bind the socket to 'localhost' or '127.0.0.1' if you only want the server to be accessible on the same machine, or retrieve the address from a configuration file or environment variable that can be properly managed and secured: + +[source,python] +---- +import socket +import os + +address = os.getenv('SERVER_ADDRESS', 'localhost') +port = os.getenv('SERVER_PORT', 8000) + +s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) +s.bind((address, port)) +s.listen() +---- + +In this revised code, the server address and port are read from environment variables. If the variables are not set, the server defaults to 'localhost' on port 8000, which means it will only accept connections from the same machine. + diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-50.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-50.adoc new file mode 100644 index 000000000..cfb52c56b --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-50.adoc @@ -0,0 +1,83 @@ +== XML Parsers exposed to XXE Vulnerabilities + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_50 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/611.html[CWE-611: Information Exposure Through XML External Entity Reference] + +|OWASP Categories +|https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +XML External Entity (XXE) attacks exploit the vulnerability of an application that parses XML input containing reference to an external entity. The attack may lead to unauthorized access to data, denial of service, or possibly server-side request forgery. This policy specifically identifies configurations of the lxml library in Python where the XML parsers are susceptible to XXE attacks. + +Code patterns under scrutiny include: +- Direct usage of lxml.etree.XMLParser without appropriate configurations. +- Specific configurations of lxml.etree.XSLTAccessControl that enable `read_network`. +- Certain SAX parser configurations. + +Examples of potentially vulnerable code: + +[source,python] +---- +from lxml import etree +parser = etree.XMLParser() +# ... + +parser = etree.XMLParser(resolve_entities=True) +# ... + +control = etree.XSLTAccessControl(read_network=True) +# ... + +import xml.sax +parser = xml.sax.make_parser() +parser.setFeature(xml.sax.handler.feature_external_ges, True) +---- + +=== Fix - Buildtime + +To prevent XXE attacks: + +1. Configure the XML parser to explicitly disable external entities. For lxml.etree.XMLParser, set `resolve_entities` to `False`. +2. Avoid using configurations that enable `read_network` in lxml.etree.XSLTAccessControl. Set `read_network` to `False`. +3. For SAX parsers, disable the feature that allows external general entities. + +Example of a safer configuration: + +[source,python] +---- +from lxml import etree +parser = etree.XMLParser(resolve_entities=False) +# ... + +control = etree.XSLTAccessControl(read_network=False) +# ... + +import xml.sax +parser = xml.sax.make_parser() +parser.setFeature(xml.sax.handler.feature_external_ges, False) +---- + +Following these guidelines ensures that the XML parsers in your application are not susceptible to XXE attacks. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-51.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-51.adoc new file mode 100644 index 000000000..8f9d376c2 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-51.adoc @@ -0,0 +1,74 @@ +== Request exposed to SQL injection + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_51 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/89.html[CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +SQL injection is a code injection technique, which can result in unauthorized viewing of data, corrupting or deleting data, and in some cases can lead to complete host takeover. This policy identifies patterns where user input might be improperly integrated into SQL queries, making the application susceptible to SQL injection attacks. + +Examples of potentially vulnerable code: + +[source,python] +---- +user_input = input("Enter your username: ") +query = "SELECT * FROM users WHERE username = '" + user_input + "'" +db.execute(query) +# ... + +id = request.args.get('id') +query = f"DELETE FROM items WHERE item_id = {id}" +db.execute(query) +# ... + +# And other similar patterns +---- + +=== Fix - Buildtime + +To protect against SQL injection: + +1. Avoid constructing SQL queries using string concatenation, formatting, or interpolation. +2. Always use parameterized queries or prepared statements. This ensures that user input is always treated as data and not executable code. + +Example of a safe approach: + +[source,python] +---- +user_input = input("Enter your username: ") +query = "SELECT * FROM users WHERE username = ?" +db.execute(query, (user_input,)) +# ... + +id = request.args.get('id') +query = "DELETE FROM items WHERE item_id = ?" +db.execute(query, (id,)) +# ... +---- + +By following these guidelines, you ensure that your application is resilient against SQL injection attacks. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-52.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-52.adoc new file mode 100644 index 000000000..38bb09d44 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-52.adoc @@ -0,0 +1,62 @@ +== User input not protected against NoSQL injection + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_52 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/943.html[CWE-943: Improper Neutralization of Special Elements in Data Query Logic] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A1_2017-Injection[A1:2017 - Sensitive Data Exposure] + +|=== + +=== Description + +NoSQL databases provide flexible schema and scalability, but they aren't immune to injection attacks. This policy detects patterns where queries to a NoSQL database might be vulnerable to injection attacks. + +Example of a potentially vulnerable code: + +[source,python] +---- +user_input = request.args.get('id') +items = db.scan(f"SELECT * FROM data WHERE id = {user_input}") +# ... + +# Without the use of ExpressionAttributeValues +---- + +=== Fix - Buildtime + +To protect against NoSQL injection: + +1. Always avoid using raw input directly in queries. Instead, use parameterized queries or other mechanisms provided by the NoSQL library. +2. Always use `ExpressionAttributeValues` or similar constructs to safely pass user input to queries. + +Example of a safe approach: + +[source,python] +---- +user_input = request.args.get('id') +items = db.scan("SELECT * FROM data WHERE id = :id", ExpressionAttributeValues={":id": user_input}) +# ... +---- + +By following these guidelines, you ensure that your application is resilient against NoSQL injection attacks. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-53.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-53.adoc new file mode 100644 index 000000000..65c64d4b5 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-53.adoc @@ -0,0 +1,57 @@ +== Not using HttpOnly flag when setting cookies + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_53 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/1004.html[CWE-1004: Sensitive Cookie Without 'HttpOnly' Flag] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control[A05:2021 - Security Misconfiguration] + +|=== + +=== Description + +Setting the `HttpOnly` flag for cookies is crucial for security. This flag ensures that cookies are inaccessible to JavaScript, preventing potential cross-site scripting (XSS) attacks from stealing cookies. This policy detects scenarios where cookies are set without the `HttpOnly` flag, which makes them vulnerable to theft or manipulation. + +Example of a potentially vulnerable code: + +[source,python] +---- +response = flask.Response() +# ... other code ... +response.set_cookie('session', 'value123') +---- + +=== Fix - Buildtime + +To secure cookies always set the `HttpOnly` flag when setting cookies. This restricts cookies from being accessed via JavaScript. + +Example of a secure approach: + +[source,python] +---- +response = flask.Response() +# ... other code ... +response.set_cookie('session', 'value123', httponly=True) +---- + +By following this guideline, you safeguard your cookies from potential theft or manipulation by malicious scripts. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-54.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-54.adoc new file mode 100644 index 000000000..1d63cb0a7 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-54.adoc @@ -0,0 +1,72 @@ +== JWTs are not properly verified before decoding + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_54 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +a|https://cwe.mitre.org/data/definitions/347.html[CWE-347: Improper Verification of Cryptographic Signature] + +https://cwe.mitre.org/data/definitions/602.html[CWE-602: Client-Side Enforcement of Server-Side Security] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration[A02:2021 - Cryptographic Failures] + +https://owasp.org/www-project-top-ten/2017/A4_2017-XML_External_Entities_(XXE)[A04:2021 - Insecure Design] + +|=== + +=== Description + +A potential vulnerability has been identified where JSON Web Tokens (JWTs) are being decoded or processed without proper verification of their signatures. JWTs are a compact URL-safe means of representing claims to be transferred between two parties. Ensuring the signature of a JWT is verified is critical for the integrity and authenticity of the token. + +When JWTs are not verified, it can lead to: + +1. Unauthorized actions. +2. Data breaches. +3. Spoofed identities. +4. Exploitation of other security vulnerabilities. + +In the provided codebase, JWTs are being processed using methods that explicitly disable verification or do not verify the JWT's signature before decoding its content. This is a severe security misconfiguration that can lead to potential security risks and breaches. + +For example, avoid practices such as: + +[source,python] +---- +# Vulnerable way of decoding JWT without verification +decoded_jwt = jwt.decode(token, verify=False) +---- + +=== Fix - Buildtime + +To address this: + +1. Always verify the JWT's signature before decoding or processing its content. +2. Avoid using configurations that disable signature verification. +3. Regularly review and update libraries or methods that deal with JWTs to ensure they follow best security practices. + +For example: + +[source,python] +---- +# Correct way to decode a JWT with verification +decoded_jwt = jwt.decode(token, key, algorithms=["HS256"]) +---- + +Always ensure you are providing the correct secret or public key and specifying the algorithms you trust for decoding to prevent potential attacks. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-55.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-55.adoc new file mode 100644 index 000000000..58056a4c2 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-55.adoc @@ -0,0 +1,69 @@ +== Weak cryptographic algorithm used + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_55 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +Utilizing weak or deprecated cryptographic algorithms poses a threat by exposing sensitive information to unnecessary vulnerabilities. This policy pinpoints the uses of outdated or insecure cryptographic algorithms that are considered unsafe and thus not recommended. + +When weak algorithms are in play, it can result in: + +1. Exposed sensitive information. +2. Greater susceptibility to brute-force attacks. +3. The potential for revealing system configurations or secrets. + +In the observed codebase, cryptography is performed with algorithms that are deprecated or considered as risky. Leveraging these algorithms is a crucial security misconfiguration that can expose applications to threats. + +Avoid practices like: + +[source,python] +---- +# Using Cryptodome library with DES (not recommended) +import Cryptodome.Cipher.DES as DES +cipher = DES.new(YOUR_KEY) +---- + +=== Fix - Buildtime + +To mitigate this: + +1. Transition to cryptographic algorithms that have been approved and are recognized as secure. +2. Avoid the use of deprecated or known insecure cryptographic algorithms. +3. Regularly audit and update cryptographic libraries and methods to follow the best and updated security practices. + +For instance: + +[source,python] +---- +# Using Cryptodome library with AES (recommended) +from Cryptodome.Cipher import AES +cipher = AES.new(YOUR_KEY) +---- + +Always remain updated with the advancements in cryptography to combat potential risks. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-56.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-56.adoc new file mode 100644 index 000000000..dd51fdf1e --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-56.adoc @@ -0,0 +1,72 @@ +== CSRF protections disabled + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_56 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/352.html[CWE-352: Cross-Site Request Forgery (CSRF)] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A1_2017-Injection[A01:2021 - Broken Access Control] + +|=== + +=== Description + +Cross-Site Request Forgery (CSRF) is an attack that forces a victim to execute unwanted actions on a web application they are authenticated with. By disabling CSRF protections, applications expose themselves to a serious security risk. This policy has identified instances where CSRF protections are disabled or not correctly implemented. + +When CSRF protections are disabled, it can lead to: + +1. Unauthorized actions performed on behalf of an authenticated user. +2. Data breaches. +3. Account hijacking. +4. Exploitation of the trust a user has with a specific site. + +In the analyzed codebase, instances were detected where the CSRF protections were explicitly turned off. Such configurations increase the application's vulnerability to CSRF attacks. + +For example, avoiding practices like: + +[source,python] +---- +# Disabling CSRF protection in Flask-WTF +class MyForm(flask_wtf.FlaskForm): + class Meta: + csrf = False +---- + +=== Fix - Buildtime + +To ensure the security of your application: + +1. Always enable CSRF protections in web applications, especially in forms, API endpoints, and other user-facing components. +2. Never turn off CSRF protections in configurations or use decorators that bypass them. +3. Regularly update and review libraries that handle CSRF protections to follow best security practices. + +For instance, implementing CSRF protection in a Flask application: + +[source,python] +---- +from flask_wtf.csrf import CSRFProtect + +app = flask.Flask(__name__) +csrf = CSRFProtect(app) +---- + +This approach ensures that CSRF tokens are generated and checked on every request, safeguarding against potential attacks. Ensure that all parts of your application use and enforce CSRF tokens and that protections are not mistakenly disabled. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-57.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-57.adoc new file mode 100644 index 000000000..9efc92163 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-57.adoc @@ -0,0 +1,78 @@ +== Improper logger configuration + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_57 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +a|https://cwe.mitre.org/data/definitions/117.html[CWE-117: Improper Output Neutralization for Logs] + +https://cwe.mitre.org/data/definitions/532.html[CWE-532: Insertion of Sensitive Information into Log File] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/A09_2017-Using_Components_with_Known_Vulnerabilities[A09:2021 - Security Logging and Monitoring Failures] + +|=== + +=== Description + +Loggers, when configured improperly, can pose several security risks. These risks include the unintentional logging of sensitive data, uncontrolled log data growth which might be exploited for a Denial of Service (DoS) attack, and even log forging. A logger, essentially, is a double-edged sword, which, if used properly, can serve as an invaluable tool for monitoring and diagnosing issues but, if misused, can lead to security vulnerabilities. + +When logging configurations are mismanaged: + +1. Sensitive information can be unintentionally logged, exposing passwords, API keys, or PII. +2. Log forging can occur, where attackers insert malicious log entries. +3. Logs can be disabled, preventing the capture of critical security events. + +The observed codebase shows instances where loggers are potentially misconfigured or utilized in a way that could introduce security vulnerabilities. + +For example, care should be taken with: + +[source,python] +---- +# Avoid disabling logging entirely +logging.disable() + +# Be cautious when configuring basic logging without proper format and level +logging.basicConfig() +---- + +=== Fix - Buildtime + +To maintain secure and effective logging: + +1. Always define a logging format that doesn't expose sensitive information. +2. Ensure the logging level is set to an appropriate level for the environment (e.g., `DEBUG` might be suitable for development, but not production). +3. Avoid disabling logging entirely; it's crucial for detecting and responding to security incidents. +4. Regularly review logging configurations and custom logging classes, handlers, or filters to ensure they align with security best practices. + +For a robust logging configuration in a Python application: + +[source,python] +---- +import logging + +logging.basicConfig(level=logging.INFO, + format='%(asctime)s - %(name)s - %(levelname)s - %(message)s') + +# Create and configure a logger instance +logger = logging.getLogger(__name__) +---- + +This setup ensures that logs include essential metadata and don't inadvertently expose sensitive information. Properly configured logs are a critical component of a robust security posture. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-58.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-58.adoc new file mode 100644 index 000000000..7400692c2 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-58.adoc @@ -0,0 +1,70 @@ +== Untrusted data unsafely deserialized + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_58 + +|Severity +|CRITICAL + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/502.html[CWE-502: Deserialization of Untrusted Data] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/A08_2017-Insecure_Deserialization[A08:2021 - Software and Data Integrity Failures] + +|=== + +=== Description + +Unsafe deserialization of untrusted data can introduce critical vulnerabilities. Specifically, using certain Python modules like `pickle` can lead to Arbitrary Code Execution (ACE) if an attacker manipulates the serialized data. When deserializing data from untrusted sources, you must be extremely careful about the method and library you use. + +For instance: + +[source,python] +---- +# Vulnerable usage of pickle +import pickle +data = pickle.load(request_input) + +# Vulnerable usage of yaml +import yaml +data = yaml.load(request_input, Loader=yaml.Loader) +---- + +=== Fix - Buildtime + +To prevent potential deserialization vulnerabilities: + +1. Never use `pickle` for deserializing untrusted data. Regardless of the source, it's a best practice to avoid `pickle` entirely due to its inherent security risks. +2. For YAML deserialization, do not use unsafe loaders such as `yaml.Loader` or `yaml.UnsafeLoader`. +3. Consider safer serialization/deserialization methods like JSON, which doesn't execute code during deserialization. + +For safe deserialization in a Python application: + +[source,python] +---- +import json + +# Safe usage of JSON for deserialization +data = json.loads(request_input) + +# Safe usage of yaml +import yaml +data = yaml.load(request_input, Loader=yaml.SafeLoader) +---- + +Always ensure you're deserializing data in a manner that doesn't expose your application to security vulnerabilities. Properly handling deserialization is crucial for maintaining the security of your applications. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-59.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-59.adoc new file mode 100644 index 000000000..44b617973 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-59.adoc @@ -0,0 +1,65 @@ +== Encryption algorithms used with an insecure mode or padding + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_59 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration[A02:2021 - Cryptographic Failures] + +|=== + +=== Description + +Ensuring robust encryption is crucial to maintain data confidentiality. This policy highlights instances where vulnerable encryption algorithms are employed. Specifically, the use of algorithms like RC2 and DES is discouraged due to their inherent vulnerabilities and diminishing strength against modern computational power. + +For example: + +[source,python] +---- +# Vulnerable usage of Cryptodome's ARC2 +from Cryptodome.Cipher import ARC2 +cipher = ARC2.new(YOUR_KEY) + +# Vulnerable usage of DES +from Crypto.Cipher import DES +cipher = DES.new(YOUR_KEY) +---- + +=== Fix - Buildtime + +To prevent potential cryptographic vulnerabilities: + +1. Refrain from using deprecated or insecure cryptographic algorithms, such as RC2 and DES. +2. Migrate to secure algorithms like AES, which offers superior encryption strength and is widely adopted as an industry standard. +3. Regularly audit and update cryptographic libraries and methods to align with updated security practices and recommendations. + +Here's how you can transition to a more secure encryption algorithm: + +[source,python] +---- +# Recommended usage of AES +from Cryptodome.Cipher import AES +cipher = AES.new(YOUR_KEY) +---- + +Properly employing encryption is paramount for ensuring the integrity and confidentiality of data. Stay vigilant and regularly update cryptographic practices in accordance with modern security standards. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-6.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-6.adoc new file mode 100644 index 000000000..d1871c618 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-6.adoc @@ -0,0 +1,66 @@ +== Use of hardcoded passwords in Python code + + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_6 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/259.html[CWE-259: Use of Hard-coded Password] + +|OWASP Categories +|https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[A07:2021 - Identification and Authentication Failures] + +|=== + + + +=== Description + +Hardcoding passwords directly into code is a very serious security concern. These hardcoded credentials can be easily exposed if the source code is ever leaked or inspected by unauthorized individuals. Also, they are typically shared among multiple people and are seldom rotated, which is a bad practice from a security standpoint. + +Hardcoding a password as a default argument in a function could lead to situations where the hardcoded password is used in production if a real password is not supplied. This is a serious issue, as an attacker who knows or discovers the hardcoded password could then potentially authenticate with whatever system the password is used for. + +Here's an example of violating code: + +[source,python] +---- +def connect_to_db(username="admin", password="password123"): + # Code to connect to the database + pass +---- + +In this code, the function connect_to_db has default arguments for username and password. If no arguments are supplied when this function is called, the hardcoded credentials will be used. + +=== Fix - Buildtime + +To fix this issue, you should remove the hardcoded password. If you need to supply a default password for testing or development, it should be loaded from a secure location, like an environment variable: + +[source,python] +---- +import os + +def connect_to_db(username=None, password=None): + username = username or os.getenv('DB_USERNAME') + password = password or os.getenv('DB_PASSWORD') + # Code to connect to the database + pass +---- + +In this revised code, if no arguments are supplied when connect_to_db is called, the function will try to get the credentials from environment variables. This approach keeps the credentials out of the source code. In production, always use secure methods of managing credentials, like secret management services. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-60.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-60.adoc new file mode 100644 index 000000000..54e58d4c0 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-60.adoc @@ -0,0 +1,63 @@ +== HTML Autoescape Mechanism Should Not Be Globally Disabled + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_60 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/80.html[CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A3_2017-Cross-Site_Scripting_(XSS)[A03:2021 - Injection] + +|=== + +=== Description + +The autoescaping mechanism in Jinja2 is a critical component to prevent Cross-Site Scripting (XSS) attacks. By default, Jinja2 sets autoescaping to `True`, ensuring that all variable content gets escaped. Disabling this mechanism globally can lead to vulnerabilities where untrusted data gets rendered as-is, potentially leading to XSS vulnerabilities. + +Example of vulnerable configuration: + +[source,python] +---- +from jinja2 import Environment + +# Vulnerable configuration with autoescaping disabled +env = Environment(autoescape=False) +---- + +=== Fix - Buildtime + +To mitigate potential XSS risks: + +1. Ensure that the autoescape mechanism is not disabled globally. +2. If autoescaping needs to be turned off for specific use cases, do so cautiously and locally. Always validate and sanitize untrusted input. +3. Regularly review and audit the configurations and templates to ensure best security practices are being followed. + +The following shows the recommended approach: + +[source,python] +---- +from jinja2 import Environment + +# Safe configuration with autoescaping enabled +env = Environment(autoescape=True) +---- + +Autoescaping plays a pivotal role in ensuring web application security. Ensure to maintain it enabled to protect against potential XSS attacks. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-61.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-61.adoc new file mode 100644 index 000000000..b3694b666 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-61.adoc @@ -0,0 +1,76 @@ +== LDAP Queries Should Not Be Vulnerable to Injection Attacks + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_61 + +|Severity +|CRITICAL + +|Subtype +|Build + +|Language +|Python + +|CWEs +a|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +https://cwe.mitre.org/data/definitions/90.html[CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2017/A1_2017-Injection[A1:2017-Injection] + +https://owasp.org/www-project-top-ten/2017/A1_2017-Injection[A03:2021 - Injection] + +|=== + +=== Description + +LDAP injection is a type of application vulnerability, akin to SQL injection, used to exploit applications that construct LDAP statements from user-supplied input. It can occur when an application fails to properly sanitize user input before it's used as part of an LDAP query. Attackers can manipulate the queries to gain unauthorized access, retrieve sensitive data, or perform privileged actions. + +The provided policy identifies instances in the code where user-supplied data from HTTP requests may be used unsafely in an LDAP search operation, posing a risk of LDAP injection. + +Example of vulnerable code: + +[source,python] +---- +from flask import request +import ldap + +conn = ldap.initialize("ldap://localhost") +user_input = request.args.get("user") +conn.search_s('ou=users,dc=example,dc=com', ldap.SCOPE_SUBTREE, f"(uid={user_input})") +---- + +=== Fix - Buildtime + +To mitigate potential risks: + +1. Always validate and sanitize user inputs before they are used in LDAP queries. +2. Use parameterized LDAP queries or prepared statements to avoid injection risks. +3. Avoid string concatenation when constructing LDAP queries. +4. Employ LDAP libraries that offer protection against injection attacks. + +For a safer approach: + +[source,python] +---- +from flask import request +import ldap + +conn = ldap.initialize("ldap://localhost") +user_input = request.args.get("user") +# Using safe input practices +filter_str = ldap.filter.filter_format('(uid=%s)', (user_input,)) +conn.search_s('ou=users,dc=example,dc=com', ldap.SCOPE_SUBTREE, filter_str) +---- + +Always prioritize security measures to ensure the integrity of your LDAP operations and the protection of sensitive data. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-62.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-62.adoc new file mode 100644 index 000000000..0b3efefa5 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-62.adoc @@ -0,0 +1,75 @@ +== Logging Should Not Be Vulnerable to Injection Attacks + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_62 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +a|https://cwe.mitre.org/data/definitions/117.html[CWE-117: Improper Output Neutralization for Logs] + +https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A1_2017-Injection[A03:2021 - Injection] + +|=== + +=== Description + +Logging is an essential aspect of any application, providing invaluable insights and monitoring capabilities. However, it's crucial that logging does not become an avenue for injection attacks, which could lead to the exploitation of application vulnerabilities or sensitive data leakage. + +The identified policy detects potential vulnerabilities where user input from HTTP requests or parameters could be injected unsafely into log messages. When malicious user input is directly logged without proper sanitization, it poses a risk of log injection. An attacker can insert malicious data or code into the logs, leading to data corruption, misinformation, or other unexpected behaviors. + +A vulnerable code snippet might look like: + +[source,python] +---- +from flask import Flask, request +app = Flask(__name__) + +@app.route('/data') +def data_endpoint(): + data = request.args.get("data") + app.logger.info(f"Received data: {data}") +---- + +=== Fix - Buildtime + +To safeguard against potential log injection attacks: + +1. Always validate and sanitize user inputs before logging them. +2. Avoid using direct string interpolation or concatenation with user inputs for logging. +3. Implement strict log format schemes that can effectively neutralize malicious inputs. +4. Use logging libraries or frameworks that automatically handle sanitization. + +A safer approach would be: + +[source,python] +---- +from flask import Flask, request +app = Flask(__name__) + +@app.route('/data') +def data_endpoint(): + data = request.args.get("data") + # Avoid direct interpolation with user input + app.logger.info("Received data: %s", data) +---- + +Prioritize the security of your logging mechanisms to ensure the protection of sensitive information and the integrity of your application logs. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-63.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-63.adoc new file mode 100644 index 000000000..5c8d7e53b --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-63.adoc @@ -0,0 +1,80 @@ +== Sending Emails is Security-Sensitive + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_63 + +|Severity +|LOW + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/200.html[CWE-200: Exposure of Sensitive Information to an Unauthorized Actor] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A1_2017-Injection[A03:2021 - Injection] + +|=== + +=== Description + +Sending emails from applications is a common functionality, whether for notifications, authentication processes, or various other reasons. However, it's crucial to handle email sending securely. Emails can contain sensitive information, and any misconfiguration or oversight can expose that data to unauthorized actors. + +The identified policy points out potential security-sensitive operations where emails are sent from the application. This includes, but is not limited to: + +1. Using Django's `send_mail` function. +2. Using the `smtplib` module for sending emails via SMTP. +3. Using Flask's `Mail` module to send messages. + +An example of potentially insecure email sending might look like: + +[source,python] +---- +import smtplib +from email.message import EmailMessage + +msg = EmailMessage() +msg.set_content('Sensitive information here') +server = smtplib.SMTP('smtp.example.com') +server.sendmail(sender, recipient, msg) +server.quit() +---- + +=== Fix - Buildtime + +To securely handle email sending: + +1. Always use secure connections (e.g., SMTP over SSL/TLS) when sending emails. +2. Sanitize and validate any dynamic content added to the email body or subject. +3. Avoid sending sensitive information in emails unless it's encrypted. +4. Make sure to handle errors gracefully, ensuring that they don't expose sensitive details. +5. Regularly review third-party email libraries or services for updates and best practices. + +A safer approach for sending emails might be: + +[source,python] +---- +import smtplib +from email.message import EmailMessage + +msg = EmailMessage() +msg.set_content('General information here') +server = smtplib.SMTP_SSL('smtp.example.com', 465) # Use SMTP over SSL +server.login(sender_email, password) +server.sendmail(sender, recipient, msg.as_string()) +server.quit() +---- + +Always prioritize the security and privacy of the recipients when sending emails from your application. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-64.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-64.adoc new file mode 100644 index 000000000..394ba0819 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-64.adoc @@ -0,0 +1,72 @@ +== Server Hostnames Should not verified during SSL/TLS connections + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_64 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/295.html[CWE-295: Improper Certificate Validation] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication[A07:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +SSL/TLS connections are vital for ensuring secure communication over a computer network. One critical aspect of these connections is the validation of server certificates. Without proper server hostname verification, a man-in-the-middle attack becomes feasible, allowing attackers to intercept and decrypt communications or even impersonate a trusted server. + +The identified policy pinpoints instances where the application disables or does not correctly implement server hostname verification when establishing SSL/TLS connections. In specific, the policy focuses on instances where Python's SSL module creates an unverified or standard library context without enforcing hostname verification. + +For instance: + +[source,python] +---- +import ssl +context = ssl._create_unverified_context() +# Vulnerable since hostnames are not verified +---- + +=== Fix - Buildtime + +Ensure all SSL/TLS connections have hostname verification enabled. Here's how you can do it: + +1. Avoid using functions like `_create_unverified_context()`, which are intended for specific scenarios where verification isn't necessary (e.g., local testing). +2. When creating SSL contexts, ensure that the `check_hostname` attribute is set to `True`. +3. Regularly review and update SSL/TLS handling libraries and configurations to ensure they align with best security practices. + +An example of the correct approach would be: + +[source,python] +---- +import ssl +context = ssl.create_default_context() # This context checks hostnames by default +# Further configurations can be added +---- + +Or, if you must use `_create_stdlib_context()` or `_create_unverified_context()`, ensure that hostname checking is explicitly turned on: + +[source,python] +---- +import ssl +context = ssl._create_stdlib_context() +context.check_hostname = True +---- + +Ensuring server hostname verification will safeguard your application against potential man-in-the-middle attacks and uphold the security and privacy of the data being communicated. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-65.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-65.adoc new file mode 100644 index 000000000..d15bf138a --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-65.adoc @@ -0,0 +1,62 @@ +== Inadequate Encryption Strength + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_65 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/326.html[CWE-326: Inadequate Encryption Strength] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[A3:2017-Sensitive Data Exposure] + +|=== + +=== Description + +Encryption is a critical component in securing data in transit. However, not all encryption mechanisms are created equal. Over time, encryption algorithms and protocols can become vulnerable due to various reasons like advances in computing power and cryptographic attacks. As such, old and insecure protocols should be abandoned in favor of more secure ones. + +This policy identifies the use of deprecated or weak SSL/TLS versions in your Python codebase. Specifically, SSL versions and early versions of TLS (up to TLS 1.1) are no longer considered secure and should not be used in modern applications. + +For instance: + +[source,python] +---- +import ssl +context = ssl.SSLContext(ssl.PROTOCOL_SSLv3) # Vulnerable due to use of SSLv3 +---- + +=== Fix - Buildtime + +Adopt best practices in encryption to ensure your application's security: + +1. Do not use SSL protocols; they are outdated and have known vulnerabilities. +2. Avoid using TLS versions 1.0 and 1.1, as they are considered weak and are deprecated. +3. Upgrade to using TLS version 1.2 or higher, which provides strong encryption and is widely supported. +4. Regularly review and update your encryption protocols and libraries. + +The recommended way to initialize an SSL context is: + +[source,python] +---- +import ssl +context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2) # Use TLSv1.2 or higher +---- + +By ensuring the use of strong and updated encryption protocols, you reduce the risk of man-in-the-middle attacks and data breaches, ensuring the confidentiality and integrity of your data. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-66.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-66.adoc new file mode 100644 index 000000000..bee8ccd6c --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-66.adoc @@ -0,0 +1,63 @@ +== LDAP anonymous binds are used + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_66 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/521.html[CWE-521: Weak Password Requirements] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A7_2017-Identification_and_Authentication_Failures[A7:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +Lightweight Directory Access Protocol (LDAP) is a protocol used for accessing and managing directory information. However, using anonymous or unauthenticated binds in LDAP can pose a security risk. These binds allow access to information in the LDAP directory without the requirement of providing a password, potentially exposing sensitive information or allowing unauthorized actions. + +In the examined codebase, there are instances where LDAP binds are being used without any authentication. This poses a risk as it can lead to unintended information disclosure or unauthorized actions within the directory. + +For instance: + +[source,python] +---- +import ldap +l = ldap.initialize('ldap://ldap.server') +l.simple_bind_s('cn=Manager,dc=example,dc=com') # Vulnerable usage +---- + +=== Fix - Buildtime + +To secure your LDAP connections: + +1. Always use authenticated binds. Avoid the use of anonymous or unauthenticated binds in your LDAP configurations. +2. Regularly review your LDAP configurations and access controls to ensure only authenticated and authorized users can perform binds. +3. Consider implementing additional security measures, such as LDAP over SSL (LDAPS) or StartTLS, to further secure the connection. + +A more secure way to bind would be: + +[source,python] +---- +import ldap +l = ldap.initialize('ldap://ldap.server') +l.simple_bind_s('cn=Manager,dc=example,dc=com', 'password123') # Use with authentication +---- + +By ensuring the use of authenticated binds, you reduce the risk of unauthorized access and maintain the integrity and confidentiality of your directory information. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-67.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-67.adoc new file mode 100644 index 000000000..8f3cb6608 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-67.adoc @@ -0,0 +1,70 @@ +== Weak SSL/TLS protocol used + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_67 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +a|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Inadequate Encryption Strength] + +https://cwe.mitre.org/data/definitions/326.html[CWE-326: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2017/A2_2017-Security_Misconfiguration[A2:2021 - Cryptographic Failures] + +https://owasp.org/www-project-top-ten/2017/A7_2017-Identification_and_Authentication_Failures[A7:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +Secure Transport Layer Security (TLS) protocol versions are crucial for encrypting communications over networks. However, not all versions of the protocol maintain a high level of security. The use of insecure TLS protocol versions can leave applications vulnerable to various types of attacks, such as man-in-the-middle attacks, where attackers can intercept and decipher the communication. + +In the analyzed codebase, configurations were discovered that make use of insecure or outdated TLS protocol versions. Leveraging these older versions poses security risks and can expose sensitive data. + +For example: + +[source,python] +---- +# Using OpenSSL with SSLv3 (not recommended) +import OpenSSL +context = OpenSSL.SSL.Context(OpenSSL.SSL.SSLv3_METHOD) +---- + +=== Fix - Buildtime + +To ensure robust encryption: + +1. Transition to using secure TLS protocol versions such as TLSv1.2 or TLSv1.3. +2. Ensure that any third-party libraries or services also use secure protocol versions. +3. Regularly review and update configurations to reflect the latest security standards and practices. + +A safer configuration example: + +[source,python] +---- +# Using AWS CDK for OpenSearchService with a secure TLS policy +import aws_cdk.aws_opensearchservice as oss +domain = oss.CfnDomain( + <...>, + domain_endpoint_options=oss.CfnDomain.DomainEndpointOptionsProperty(tls_security_policy="Policy-Min-TLS-1-2-2019-07") +) +---- + +Maintaining updated and secure TLS configurations ensures encrypted communications remain confidential and are not vulnerable to interception or tampering. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-68.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-68.adoc new file mode 100644 index 000000000..c33b8e351 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-68.adoc @@ -0,0 +1,71 @@ +== Weak SSL/TLS protocol used + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_68 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|Python + +|CWEs +a|https://cwe.mitre.org/data/definitions/327.html[CWE-327: Inadequate Encryption Strength] + +https://cwe.mitre.org/data/definitions/326.html[CWE-326: Use of a Broken or Risky Cryptographic Algorithm] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2017/A2_2017-Security_Misconfiguration[A2:2021 - Cryptographic Failures] + +https://owasp.org/www-project-top-ten/2017/A7_2017-Identification_and_Authentication_Failures[A7:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +Robust encryption and decryption mechanisms are critical to ensuring data confidentiality and preventing unauthorized access. However, the use of insecure or outdated encryption algorithms can jeopardize these security goals. Specifically, the use of insecure TLS protocol versions exposes encrypted data to several risks and vulnerabilities. + +In the codebase under scrutiny, configurations using insecure or deprecated encryption algorithms have been observed. These practices compromise the security of encrypted data, potentially making it susceptible to decryption by malicious actors. + +For instance: + +[source,python] +---- +# Utilizing cryptography with insecure configurations +from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes +vector = b'0' * 16 +cipher = Cipher(algorithms.AES(b'YourKey'), modes.CBC(vector)) +cipher.encryptor() +---- + +=== Fix - Buildtime + +To ensure that encryption remains secure: + +1. Shift to using secure and updated encryption algorithms. +2. Do not use insecure configurations such as ECB mode or insecure initial vector patterns. +3. Frequently review and update your encryption configurations to align with modern security best practices. + +A recommended configuration: + +[source,python] +---- +# Use cryptography with AES in a more secure configuration +from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes +vector = os.urandom(16) # Generate a random initialization vector +cipher = Cipher(algorithms.AES(b'YourKey'), modes.CBC(vector)) +cipher.encryptor() +---- + +Always ensure the confidentiality and security of encrypted data by adopting up-to-date encryption methodologies and algorithms. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-69.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-69.adoc new file mode 100644 index 000000000..7e76bcddb --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-69.adoc @@ -0,0 +1,73 @@ +== Files and directories are assigned loose permissions + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_69 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +a|https://cwe.mitre.org/data/definitions/732.html[CWE-732: Incorrect Permission Assignment for Critical Resource] + +https://cwe.mitre.org/data/definitions/266.html[CWE-266: Incorrect Privilege Assignment] + +|OWASP Categories +a|https://owasp.org/www-project-top-ten/2017/A1_2017-Injection[A1:2021 - Broken Access Control] + +https://owasp.org/www-project-top-ten/2017/A4_2017-XML_External_Entities_(XXE)[A4:2021 - Insecure Design] + +|=== + +=== Description + +Assigning overly permissive privileges to files and directories can lead to potential unauthorized access, data breaches, and system compromises. Ensuring that only the minimum required permissions are set is critical for the security and integrity of the system. + +In the observed codebase, instances were found where files and directories were granted excessively permissive rights, which can expose them to malicious actors. Leveraging these permissions, attackers could modify, delete, or exploit these resources. + +For example: + +[source,python] +---- +# Unsafe permission setting +import os +import stat + +os.umask(0) +os.chmod('some_file', stat.S_IRWXO) +---- + +=== Fix - Buildtime + +To safeguard your files and directories: + +1. Always use the most restrictive permissions that still allow your application to function properly. +2. Avoid setting permissions that give everyone access to critical resources. +3. Regularly audit your code and filesystem to ensure permissions are set correctly. + +A safer approach: + +[source,python] +---- +# Securely setting permissions +import os +import stat + +os.umask(0o077) # Set default permissions to prevent others from reading/writing +os.chmod('some_file', stat.S_IRUSR | stat.S_IWUSR) # Only grant read/write permissions to the owner +---- + +It is essential to maintain the principle of least privilege to prevent unauthorized access and modifications to your resources. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-70.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-70.adoc new file mode 100644 index 000000000..ae900e4e3 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-70.adoc @@ -0,0 +1,68 @@ +== Improper Authorization in Handler for Custom URL Scheme + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_70 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/939.html[CWE-939: Improper Authorization in Handler for Custom URL Scheme] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control[A5:2017-Broken Access Control] + +|=== + +=== Description + +The `urllib` module in Python provides a way to work with URLs. However, when used improperly, it can introduce security vulnerabilities, especially when handling URLs that may be controlled or manipulated by malicious actors. + +Our analysis has detected the use of `urllib` or its variants with dynamic values. The problem with this is that `urllib` inherently supports the `file://` scheme. This means a malicious actor can craft URLs that could potentially allow them to read arbitrary files on the server. This behavior exposes the system to a range of security threats, including information disclosure. + +For example: + +[source,python] +---- +# Vulnerable code snippet +import urllib + +url = get_dynamic_value_from_user() +content = urllib.urlopen(url).read() +---- + +=== Fix - Buildtime + +To address this vulnerability: + +1. Audit the uses of `urllib` or related calls to ensure no user data can influence or control the URLs being accessed. +2. Consider avoiding the use of `urllib` for URLs that might be influenced by user data. Instead, prefer using the more robust `requests` library in Python. +3. If you continue using `urllib`, ensure proper validation and sanitization mechanisms are in place to prevent malicious URL crafting. + +A safer approach: + +[source,python] +---- +# Recommended code snippet +import requests + +url = get_dynamic_value_from_user() +response = requests.get(url) +content = response.text +---- + +Being vigilant about the libraries and functions you use and ensuring you are always following best practices can go a long way in maintaining the security and integrity of your applications. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-71.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-71.adoc new file mode 100644 index 000000000..98a4a6477 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-71.adoc @@ -0,0 +1,67 @@ +== Insecure use of no password or weak password when connecting to a database + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_71 + +|Severity +|CRITICAL + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/521.html[CWE-521: Weak Password Requirements] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A7_2017-Identification_and_Authentication_Failures[A7:2021 - Identification and Authentication Failures] + +|=== + +=== Description + +Database connections should always be secured with robust authentication mechanisms. When connecting to databases, applications must use strong and unique passwords to prevent unauthorized access. Our analysis detected database connections that either misuse a password or use an empty password. This practice is highly insecure and can expose sensitive data to potential attackers. + +For example: + +[source,python] +---- +# Vulnerable code snippet +import mysql.connector + +connection = mysql.connector.connection.MySQLConnection(user='admin', password='') +---- + +=== Fix - Buildtime + +To remediate this issue: + +1. Always use strong, unique passwords when connecting to databases. Do not rely on default or easily guessable passwords. +2. Do not hard-code database passwords in your source code. Use environment variables, secrets management tools, or encrypted configuration files to handle database credentials. +3. Periodically rotate database passwords to minimize risks associated with password leaks or breaches. + +A safer approach: + +[source,python] +---- +# Recommended code snippet +import os +import mysql.connector + +# Get database password from an environment variable or secure config +DB_PASSWORD = os.environ.get('DB_PASSWORD') + +connection = mysql.connector.connection.MySQLConnection(user='admin', password=DB_PASSWORD) +---- + +Ensuring strong authentication for database connections is a fundamental step in maintaining the security of both the application and the underlying data. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-72.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-72.adoc new file mode 100644 index 000000000..1389fe96e --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-72.adoc @@ -0,0 +1,68 @@ +== Hash functions used without an unpredictable salt + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_72 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +a|https://cwe.mitre.org/data/definitions/759.html[CWE-759: Use of a One-Way Hash without a Salt] + +https://cwe.mitre.org/data/definitions/760.html[CWE-760: Use of a One-Way Hash with a Predictable Salt] + +|OWASP Categories +|https://owasp.org/www-project-top-ten/2017/A2_2017-Cryptographic_Failures[A2:2021 - Cryptographic Failures] + +|=== + +=== Description + +Using hash functions without unpredictable salts makes hashed values susceptible to rainbow table attacks, where precomputed hash values are looked up to determine the original input. Our analysis has detected instances where hash functions are being used without unpredictable salts or with predictable ones. This undermines the security of the hashing process. + +For instance: + +[source,python] +---- +# Vulnerable usage +import hashlib +password_hash = hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), 'known_salt'.encode('utf-8'), 100000) +---- + +=== Fix - Buildtime + +To address this vulnerability: + +1. Always use a unique and unpredictable salt for each user or data record. +2. Do not rely on hardcoded or easily guessable salts. +3. Store salts securely, ideally separately from the hashed values. +4. Regularly review hashing methods and update them as needed. + +A safer approach: + +[source,python] +---- +# Recommended code snippet +import os +import hashlib + +# Generate a random salt for each hash operation +salt = os.urandom(16) +password_hash = hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), salt, 100000) +---- + +By ensuring the unpredictability of the salt used in the hashing process, you significantly enhance the security and integrity of the hashed values. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-73.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-73.adoc new file mode 100644 index 000000000..f409b6876 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-73.adoc @@ -0,0 +1,63 @@ +== None attributes accessed + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_73 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|Python + +|CWEs +|https://cwe.mitre.org/data/definitions/476.html[CWE-476: NULL Pointer Dereference] + + +|=== + +=== Description + +In Python, `None` represents the absence of a value or a null pointer. Attempting to access an attribute of a `None` object will result in an `AttributeError`. If not handled correctly, this error can lead to unexpected behaviors in your code, and potentially expose sensitive debugging information that can be leveraged by attackers to better understand your application's internals. + +For instance: + +[source,python] +---- +# Vulnerable usage +if user is None: + print(user.username) +---- + +This code will raise an `AttributeError` when trying to access the `username` attribute of a `None` object, leading to unexpected application behavior. + +=== Fix - Buildtime + +To mitigate this vulnerability: + +1. Always check if an object is `None` before attempting to access its attributes. +2. Utilize appropriate error handling mechanisms to ensure that `AttributeError` or any other unexpected errors do not propagate sensitive information to the end-user. +3. Ensure thorough code reviews are done to catch instances where `None` values might be improperly accessed. + +A safer approach: + +[source,python] +---- +# Recommended code snippet +if user: + print(user.username) +else: + print("User not found.") +---- + +By being diligent in checking for `None` before accessing attributes and employing robust error handling, you can prevent potential crashes, ensure a smoother user experience, and prevent exposure of sensitive information. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-82.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-82.adoc new file mode 100644 index 000000000..19fdcab33 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-82.adoc @@ -0,0 +1,69 @@ + +== Writing unvalidated input into JSON + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_82 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|python + +|CWEs +a|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +https://cwe.mitre.org/data/definitions/74.html[CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component] + +https://cwe.mitre.org/data/definitions/116.html[CWE-116: Improper Encoding or Escaping of Output] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects instances where unvalidated user input is written into a JSON object. Writing unvalidated input into JSON can enable attackers to inject malicious elements, potentially leading to security breaches, data corruption, and unauthorized access. + +Vulnerable code example: + +[source,python] +---- +import json + +user_input = input("Enter your name: ") +data = {'name': user_input} + +json.dump(data) +---- + +=== Fix - Buildtime + +To fix this issue, you should validate and sanitize any user input before writing it into a JSON object. This involves ensuring that the input follows expected format and does not contain any malicious elements. + +Secure code example: + +[source,python] +---- +import json + +user_input = input("Enter your name: ") +sanitized_input = user_input.strip() # Sanitize input by removing leading/trailing white spaces + +data = {'name': sanitized_input} + +json.dump(data) +---- + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-86.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-86.adoc new file mode 100644 index 000000000..0c5dc137b --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-86.adoc @@ -0,0 +1,65 @@ +== Path injection + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_86 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|python + +|CWEs +a|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +https://cwe.mitre.org/data/definitions/22.html[CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] + +|OWASP Categories +a|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +The SAST policy detects a vulnerability known as "Path injection." Path injection occurs when untrusted user input is used to construct paths that are passed into functions responsible for file or resource access, such as the `send_file()` function. An attacker can exploit this vulnerability to perform unauthorized access to sensitive files or directories. + +Vulnerable code example: + +[source,python] +---- +filename = request.args['filename'] +send_file('/var/www/uploads/' + filename) +---- + +In the above code, the `filename` parameter is directly concatenated with the path `/var/www/uploads/` and passed as an argument to the `send_file()` function. This allows an attacker to manipulate the `filename` parameter to access arbitrary files on the server. + +=== Fix - Buildtime + +To fix the issue, you should sanitize the input and validate that the requested file is within an acceptable range of locations. One possible solution is to use a whitelist approach, where you define a set of allowed filenames or directories and check the user input against this whitelist. + +Secure code example: + +[source,python] +---- +filename = request.args['filename'] +allowed_files = ['file1.txt', 'file2.txt', 'file3.txt'] +if filename in allowed_files: + send_file('/var/www/uploads/' + filename) +else: + # Handle invalid file request + abort(404) +---- + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-87.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-87.adoc new file mode 100644 index 000000000..8eba385e7 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-87.adoc @@ -0,0 +1,62 @@ +== Dynamic code execution (vulnerable to injection attacks) + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_87 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|python + +|CWEs +a|https://cwe.mitre.org/data/definitions/95.html[CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')] + +https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 – Injection] + +|=== + +=== Description + +This policy detects dynamic code execution vulnerabilities in Python code. + +Vulnerable code example: + +[source,python] +---- +user_input = request.args.get('input') +result = eval(user_input) +---- + +The above code is vulnerable because it directly passes user input to the `eval()` function, which can execute arbitrary code. This can lead to an injection attack where an attacker can execute malicious code and gain unauthorized access or manipulate the application. + +=== Fix - Buildtime + +To fix the issue, you should avoid using the `eval()` function with user input. Instead, you should validate and sanitize the input before using it. + +Secure code example: + +[source,python] +---- +user_input = request.args.get('input') +# Validate and sanitize the user input +if set(user_input).issubset('abcdefghijklmnopqrstuvwxyz'): + result = eval(user_input) +else: + result = "Invalid input" +---- + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-88.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-88.adoc new file mode 100644 index 000000000..7defcc971 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-88.adoc @@ -0,0 +1,82 @@ +== HTTP response headers should not be vulnerable to injection attacks + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_88 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|python + +|CWEs +a|https://cwe.mitre.org/data/definitions/20.html[CWE-20: Improper Input Validation] + +https://cwe.mitre.org/data/definitions/113.html[CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +HTTP headers are an essential part of the HTTP response, and their values dictate various browser behaviors. If an attacker can inject malicious data into the HTTP response headers, it can lead to several types of attacks, most notably HTTP response splitting. This occurs when there's a lack of validation or encoding of data that is written to HTTP headers. + +A malicious actor can leverage this vulnerability to insert new HTTP headers and/or payloads into the response, potentially leading to a wide range of malicious scenarios, such as cross-site scripting (XSS), session fixation, cross-user defacement, cache poisoning, and others. + +Vulnerable code might look like: + +[source,python] +---- +from flask import Flask, request +app = Flask(__name__) + +@app.route('/') +def hello(): + value = request.args.get('header_value') + response = make_response("Hello World!") + response.headers.add("X-Custom-Header", value) + return response +---- + +In the above code, the header value is being directly fetched from the request arguments and added to the HTTP response without validation. + +=== Fix - Buildtime + +To mitigate this vulnerability: + +1. Always validate and sanitize user inputs before processing them or using them in any context, especially HTTP headers. +2. Use built-in methods or libraries that handle the validation and sanitization for you, ensuring that malicious payloads are neutralized. +3. Avoid adding user-controllable data to HTTP headers directly. If unavoidable, ensure rigorous validation and sanitization. + +A safer version of the earlier example might look like: + +[source,python] +---- +from flask import Flask, request +app = Flask(__name__) + +@app.route('/') +def hello(): + value = request.args.get('header_value') + # Add validation here to ensure `value` contains only safe characters + if validate(value): + response = make_response("Hello World!") + response.headers.add("X-Custom-Header", sanitize(value)) + return response + return "Invalid header value", 400 +---- + +The key is to ensure user input does not reach sensitive sinks like HTTP headers without proper validation and sanitization. diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-89.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-89.adoc new file mode 100644 index 000000000..b8e5441d6 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-89.adoc @@ -0,0 +1,59 @@ +== Cross-site scripting (XSS) exposure + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_89 + +|Severity +|CRITICAL + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/79.html[CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')] + +|OWASP Categories +|https://owasp.org/Top10/A03_2021-Injection/[A03:2021 - Injection] + +|=== + +=== Description + +This policy detects potential Cross-Site Scripting (XSS) vulnerability in Python code where the HTTP response contains user-provided code. + +Vulnerable code example: + +[source,python] +---- +user_input = request.GET.get('input') +return HttpResponse(user_input) +---- + +The vulnerable code above takes user input from the `request.GET` object and returns it in the HTTP response without proper sanitization or output encoding. This can allow an attacker to inject malicious code into the response and potentially execute it when other users visit the page. + +=== Fix - Buildtime + +To fix the vulnerability, you should properly sanitize and encode the user input before returning it in the HTTP response. This can be done using functions or libraries that provide output encoding, such as `escape()` or `html.escape()`. + +Secure code example: + +[source,python] +---- +import html + +user_input = request.GET.get('input') +sanitized_input = html.escape(user_input) +return HttpResponse(sanitized_input) +---- + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-90.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-90.adoc new file mode 100644 index 000000000..c505fd8ff --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-90.adoc @@ -0,0 +1,59 @@ + +== Improper Restriction of XML External Entity Reference + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_90 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/611.html[CWE-611] + + +|=== + +=== Description + +This SAST policy detects improper restriction of XML external entity reference vulnerabilities in Python code that uses the native XML libraries. + +Vulnerable code example: + +[source,python] +---- +import xml.etree.ElementTree as ET + +tree = ET.parse('file.xml') +root = tree.getroot() +---- + +The above code is vulnerable because it uses the `ET.parse()` method from the `xml.etree.ElementTree` module without proper restriction of XML external entities. This can allow an attacker to read arbitrary files on the server. + +=== Fix - Buildtime + +To fix this issue, it is recommended to use the `defusedxml` library instead of the native Python XML libraries. The `defusedxml` library is specifically designed to mitigate XML external entity attacks. + +Secure code example: + +[source,python] +---- +import defusedxml.ElementTree as ET + +tree = ET.parse('file.xml') +root = tree.getroot() +---- + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-91.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-91.adoc new file mode 100644 index 000000000..11a3c4bc3 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-91.adoc @@ -0,0 +1,58 @@ + +== Uncontrolled Resource Consumption + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_91 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/400.html[CWE-400: Uncontrolled Resource Consumption] + +|=== + +=== Description + +This SAST policy detects uncontrolled resource consumption vulnerabilities in Python code. It specifically looks for instances where the `requests` library is used without a timeout parameter, or with a default timeout value set to `None`. This can cause the program to hang indefinitely if the request takes an unexpectedly long time to complete. + +Vulnerable code example: + +[source,python] +---- +import requests + +response = requests.get('https://api.example.com/data') +---- + +In the above example, the `requests.get()` function is called without specifying a timeout. This means that if the request takes a long time to complete or encounters an error, the program will wait indefinitely without timing out. + +=== Fix - Buildtime + +To fix this issue, you should always include a reasonable timeout value when making requests. This ensures that the program doesn't hang indefinitely and can handle unexpected delays. Here's an example of how to securely make the request: + +Secure code example: + +[source,python] +---- +import requests + +response = requests.get('https://api.example.com/data', timeout=5) +---- + +In the secure code example, a timeout value of 5 seconds is specified for the `requests.get()` function call. This means that if the request takes longer than 5 seconds to complete, an exception will be raised and the program will continue executing. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-93.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-93.adoc new file mode 100644 index 000000000..237ef9a7d --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-93.adoc @@ -0,0 +1,68 @@ + +== Cleartext Transmission of Sensitive Information + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_93 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/319.html[CWE-319: Cleartext Transmission of Sensitive Information] + + +|=== + +=== Description + +This policy detects the usage of the ftplib.FTP and telnetlib.Telnet functions in Python, which can lead to cleartext transmission of sensitive information. These functions do not encrypt communications by default, which can expose sensitive data. + +Vulnerable code example: + +[source,python] +---- +import ftplib + +ftp = ftplib.FTP('ftp.example.com') +ftp.login('username', 'password') +ftp.storbinary('STOR file.txt', open('file.txt', 'rb')) +ftp.quit() +---- + +The above code is vulnerable because it uses the ftplib.FTP function to establish an FTP connection without encrypting the communication. This can lead to the transmission of sensitive information, such as usernames and passwords, in cleartext. + +=== Fix - Buildtime + +To fix the issue, you should avoid using FTP or Telnet for transmitting sensitive information and instead use a secure protocol such as SSH, SFTP, or SCP. These protocols encrypt the communication. + +Secure code example: + +[source,python] +---- +import paramiko + +ssh = paramiko.SSHClient() +ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) +ssh.connect('ftp.example.com', username='username', password='password') +sftp = ssh.open_sftp() +sftp.put('file.txt', '/path/to/file.txt') +sftp.close() +ssh.close() +---- + +The above code is no longer vulnerable because it uses the paramiko library to establish an SSH connection and then uses SFTP to securely transmit the file. This ensures that the sensitive information is encrypted during transmission. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-94.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-94.adoc new file mode 100644 index 000000000..c279f9279 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-94.adoc @@ -0,0 +1,55 @@ + +== Improper Certificate Validation + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_94 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/319.html[CWE-319: Cleartext Transmission of Sensitive Information] + + +|=== + +=== Description + +This SAST policy detects instances where improper certificate validation is being performed in Python code. Improper certificate validation can lead to sensitive information being transmitted in clear text, which can expose it to unauthorized access. + +Vulnerable code example: + +[source,python] +---- +requests.get(url, verify=False) +---- + +In the above code, the `verify=False` parameter is used when making a request with the `requests` library. This disables the verification of SSL certificates, allowing for potential man-in-the-middle attacks and exposing sensitive information. + +=== Fix - Buildtime + +To fix this issue, you should enable SSL certificate verification when making requests. This can be done by removing the `verify=False` parameter or setting it to `True`. + +Secure code example: + +[source,python] +---- +requests.get(url, verify=True) +---- + +By setting `verify=True`, the SSL certificate will be validated, ensuring secure communication and preventing sensitive data exposure. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-96.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-96.adoc new file mode 100644 index 000000000..126893698 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-96.adoc @@ -0,0 +1,60 @@ + +== Insecure active debug code + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_96 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/489.html[CWE-489: Active Debug Code] + + +|=== + +=== Description + +This policy detects Flask applications with the `debug=True` flag enabled. Enabling this flag in production can lead to information disclosure and is considered a security misconfiguration. + +Vulnerable code example: + +[source,python] +---- +app = flask.Flask(__name__) +app.run(host='0.0.0.0', port=5000, debug=True) +---- + +In the above code, the `debug=True` flag is enabled when running the Flask application. This means that detailed error messages and debugging information will be displayed to the user, potentially leaking sensitive information. + +=== Fix - Buildtime + +To fix this issue, you should avoid enabling the `debug` flag in production. Instead, consider using Flask configuration variables or setting `debug` using system environment variables. + +Secure code example: + +[source,python] +---- +app = flask.Flask(__name__) +app.config['DEBUG'] = False +app.run(host='0.0.0.0', port=5000) +---- + +In the secure version of the code, the `DEBUG` configuration variable is set to `False` to disable the debug mode. This ensures that sensitive information is not leaked to the user. + +By disabling the debug mode, the secure code version prevents the detailed error messages and debugging information from being displayed to the user, protecting sensitive information. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-97.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-97.adoc new file mode 100644 index 000000000..afa48c964 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-97.adoc @@ -0,0 +1,64 @@ +== Improper access control + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_97 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/284.html[CWE-284: Improper Access Control] + +|OWASP Categories +| + +|=== + +=== Description + +This policy detects the use of vulnerable functions in Python code that can lead to improper access control. The specific vulnerable functions it looks for are `wsgiref.handlers.CGIHandler` and `twisted.web.twcgi.CGIDirectory`. + +Vulnerable code example: + +[source,python] +---- +import wsgiref.handlers + +def some_function(): + handler = wsgiref.handlers.CGIHandler() # This code violates the policy + # Rest of the code +---- + +The above code is vulnerable because it uses the `wsgiref.handlers.CGIHandler` function, which is susceptible to improper access control issues. + +=== Fix - Buildtime + +To fix the issue, you should avoid using the vulnerable functions and instead use secure alternatives or implement proper access control mechanisms. + +Secure code example: + +[source,python] +---- +import http.server + +def some_function(): + handler = http.server.SimpleHTTPRequestHandler() # This code is no longer vulnerable + # Rest of the code +---- + +The above code is no longer vulnerable because it uses the secure `http.server.SimpleHTTPRequestHandler` function instead of the vulnerable `wsgiref.handlers.CGIHandler`. This ensures proper access control and reduces the risk of security implications. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-98.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-98.adoc new file mode 100644 index 000000000..013aa7aad --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-98.adoc @@ -0,0 +1,61 @@ + +== Key Exchange without Entity Authentication + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_98 + +|Severity +|HIGH + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/322.html[CWE-322: Key Exchange without Entity Authentication] + + +|=== + +=== Description + +This SAST policy detects the usage of the `paramiko.client.AutoAddPolicy` with any value passed to `set_missing_host_key_policy()`. This is a vulnerability as it allows for key exchange without entity authentication, potentially allowing connections to malicious servers. + +Vulnerable code example: + +[source,python] +---- +import paramiko + +client = paramiko.SSHClient() +client.set_missing_host_key_policy(paramiko.client.AutoAddPolicy()) +---- + +The above code is vulnerable because it sets the host key policy to `AutoAddPolicy()`, which implicitly trusts a server's host key without verifying it, allowing connections to malicious servers. + +=== Fix - Buildtime + +To fix this issue, you should use a more secure host key policy, such as `paramiko.client.RejectPolicy()` or a custom subclass. This policy will reject connections to servers with unknown or untrusted host keys. + +Secure code example: + +[source,python] +---- +import paramiko + +client = paramiko.SSHClient() +client.set_missing_host_key_policy(paramiko.client.RejectPolicy()) +---- + +The above code is no longer vulnerable because it sets the host key policy to `RejectPolicy()`, which rejects connections to servers with unknown or untrusted host keys, preventing connections to malicious servers. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-policy-99.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-policy-99.adoc new file mode 100644 index 000000000..4f277c627 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-policy-99.adoc @@ -0,0 +1,66 @@ + +== Insecure temporary file + +=== Policy Details + +[width=45%] +[cols="1,1"] +|=== +|Prisma Cloud Policy ID +| TBD + +|Checkov ID +|CKV3_SAST_99 + +|Severity +|MEDIUM + +|Subtype +|Build + +|Language +|python + +|CWEs +|https://cwe.mitre.org/data/definitions/377.html[CWE-377: Insecure Temporary File] +|https://cwe.mitre.org/data/definitions/379.html[CWE-379: Creation of Temporary File in Directory with Insecure Permissions] + +|OWASP Categories +|https://owasp.org/Top10/A01_2021-Broken_Access_Control/[A01:2021 - Broken Access Control] + +|=== + +=== Description + +This SAST policy detects the usage of insecure temporary files in Python code. Specifically, it looks for the usage of the `os.tempnam`, `os.tmpnam`, `tempfile.mktemp`, and `open` functions with a file path starting with "/tmp". + +Vulnerable code example: + +[source,python] +---- +import os + +def create_temp_file(): + temp_file = os.tempnam("/tmp") + # Perform operations on the temporary file +---- + +The above code is vulnerable because it uses the `os.tempnam` function to create a temporary file in the `/tmp` directory. This can be exploited through symlink attacks or if the `/tmp` directory has insecure permissions. + +=== Fix - Buildtime + +To fix the issue, use the `tempfile` module to create secure temporary files. The `tempfile.TemporaryFile` function provides a safer way to create temporary files. + +Secure code example: + +[source,python] +---- +import tempfile + +def create_temp_file(): + temp_file = tempfile.TemporaryFile() + # Perform operations on the temporary file +---- + +The above code is no longer vulnerable because it uses the `tempfile.TemporaryFile` function to create a secure temporary file, which avoids the symlink attack and ensures proper handling of temporary files. + \ No newline at end of file diff --git a/application-security/policy-reference/sast-policies/python-policies/sast-python-policy-index.adoc b/application-security/policy-reference/sast-policies/python-policies/sast-python-policy-index.adoc new file mode 100644 index 000000000..1d228fc33 --- /dev/null +++ b/application-security/policy-reference/sast-policies/python-policies/sast-python-policy-index.adoc @@ -0,0 +1,222 @@ +== SAST Python Policy Index + +[width=85%] +[cols="1,1,1"] +|=== +|Policy|Checkov ID| Severity + +|xref:sast-policy-2.adoc[Unsafe use of 'exec' command] +|CKV3_SAST_2 +|HIGH + +|xref:sast-policy-3.adoc[chmod sets a permissive mask on file] +|CKV3_SAST_3 +|HIGH + +|xref:sast-policy-4.adoc[Improper handling of checking for unusual or exceptional conditions] +|CKV3_SAST_4 +|MEDIUM + +|xref:sast-policy-5.adoc[Publicly exposed servers] +|CKV3_SAST_5 +|LOW + +|xref:sast-policy-6.adoc[Use of hardcoded passwords in Python code] +|CKV3_SAST_6 +|HIGH + +|xref:sast-policy-10.adoc[Encryption keys below 2048 bit] +|CKV3_SAST_10 +|MEDIUM + +|xref:sast-policy-11.adoc[Use of module setting superuser port] +|CKV3_SAST_11 +|LOW + +|xref:sast-policy-37.adoc[Use of insecure IPMI-related modules] +|CKV3_SAST_37 +|HIGH + +|xref:sast-policy-48.adoc[Unsanitized input from data from a remote resource flows into os.system] +|CKV3_SAST_48 +|MEDIUM + +|xref:sast-policy-50.adoc[XML Parsers exposed to XXE Vulnerabilities] +|CKV3_SAST_50 +|MEDIUM + +|xref:sast-policy-51.adoc[Request exposed to SQL injection] +|CKV3_SAST_51 +|HIGH + +|xref:sast-policy-52.adoc[User input not protected against NoSQL injection] +|CKV3_SAST_52 +|MEDIUM + +|xref:sast-policy-53.adoc[Not using HttpOnly flag when setting cookies] +|CKV3_SAST_53 +|MEDIUM + +|xref:sast-policy-54.adoc[JWTs are not properly verified before decoding] +|CKV3_SAST_54 +|HIGH + +|xref:sast-policy-55.adoc[Weak cryptographic algorithm used] +|CKV3_SAST_55 +|HIGH + +|xref:sast-policy-56.adoc[CSRF protections disabled] +|CKV3_SAST_56 +|HIGH + +|xref:sast-policy-57.adoc[Improper logger configuration] +|CKV3_SAST_57 +|MEDIUM + +|xref:sast-policy-58.adoc[Untrusted data unsafely deserialized] +|CKV3_SAST_58 +|CRITICAL + +|xref:sast-policy-59.adoc[Encryption algorithms used with an insecure mode or padding] +|CKV3_SAST_59 +|HIGH + +|xref:sast-policy-60.adoc[HTML Autoescape Mechanism Should Not Be Globally Disabled] +|CKV3_SAST_60 +|MEDIUM + +|xref:sast-policy-61.adoc[LDAP Queries Should Not Be Vulnerable to Injection Attacks] +|CKV3_SAST_61 +|CRITICAL + +|xref:sast-policy-62.adoc[Logging Should Not Be Vulnerable to Injection Attacks] +|CKV3_SAST_62 +|MEDIUM + +|xref:sast-policy-63.adoc[Sending Emails is Security-Sensitive] +|CKV3_SAST_63 +|LOW + +|xref:sast-policy-64.adoc[Server Hostnames Should not verified during SSL/TLS connections] +|CKV3_SAST_64 +|MEDIUM + +|xref:sast-policy-65.adoc[Inadequate Encryption Strength] +|CKV3_SAST_65 +|HIGH + +|xref:sast-policy-66.adoc[LDAP anonymous binds are used] +|CKV3_SAST_66 +|MEDIUM + +|xref:sast-policy-67.adoc[Weak SSL/TLS protocol used] +|CKV3_SAST_67 +|HIGH + +|xref:sast-policy-68.adoc[Weak SSL/TLS protocol used] +|CKV3_SAST_68 +|HIGH + +|xref:sast-policy-69.adoc[Files and directories are assigned loose permissions] +|CKV3_SAST_69 +|MEDIUM + +|xref:sast-policy-70.adoc[Improper Authorization in Handler for Custom URL Scheme] +|CKV3_SAST_70 +|MEDIUM + +|xref:sast-policy-71.adoc[Insecure use of no password or weak password when connecting to a database] +|CKV3_SAST_71 +|CRITICAL + +|xref:sast-policy-72.adoc[Hash functions used without an unpredictable salt] +|CKV3_SAST_72 +|MEDIUM + +|xref:sast-policy-73.adoc[None attributes accessed] +|CKV3_SAST_73 +|MEDIUM + +|xref:sast-policy-82.adoc[Writing unvalidated input into JSON] +|CKV3_SAST_82 +|MEDIUM + +|xref:sast-policy-86.adoc[Path injection] +|CKV3_SAST_86 +|HIGH + +|xref:sast-policy-87.adoc[Dynamic code execution (vulnerable to injection attacks)] +|CKV3_SAST_87 +|HIGH + +|xref:sast-policy-88.adoc[HTTP response headers should not be vulnerable to injection attacks] +|CKV3_SAST_88 +|HIGH + +|xref:sast-policy-89.adoc[Cross-site scripting (XSS) exposure] +|CKV3_SAST_89 +|CRITICAL + +|xref:sast-policy-90.adoc[Improper Restriction of XML External Entity Reference] +|CKV3_SAST_90 +|MEDIUM + +|xref:sast-policy-91.adoc[Uncontrolled Resource Consumption] +|CKV3_SAST_91 +|MEDIUM + +|xref:sast-policy-93.adoc[Cleartext Transmission of Sensitive Information] +|CKV3_SAST_93 +|HIGH + +|xref:sast-policy-94.adoc[Improper Certificate Validation] +|CKV3_SAST_94 +|MEDIUM + +|xref:sast-policy-96.adoc[Insecure active debug code] +|CKV3_SAST_96 +|MEDIUM + +|xref:sast-policy-97.adoc[Improper access control] +|CKV3_SAST_97 +|HIGH + +|xref:sast-policy-98.adoc[Key Exchange without Entity Authentication] +|CKV3_SAST_98 +|HIGH + +|xref:sast-policy-99.adoc[Insecure temporary file] +|CKV3_SAST_99 +|MEDIUM + +|xref:sast-policy-100.adoc[Improper Check or Handling of Exceptional Conditions] +|CKV3_SAST_100 +|LOW + +|xref:sast-policy-152.adoc[Hardcoded passwords are being used] +|CKV3_SAST_152 +|HIGH + +|xref:sast-policy-154.adoc[Unsanitized path input from an HTTP parameter is being opened] +|CKV3_SAST_154 +|MEDIUM + +|xref:sast-policy-166.adoc[Improper Check or Handling of Exceptional Conditions] +|CKV3_SAST_166 +|LOW + +|xref:sast-policy-167.adoc[Use of Insufficiently Random Values] +|CKV3_SAST_167 +|LOW + +|xref:sast-policy-168.adoc[Improper Control of Generation of Code ('Code Injection')] +|CKV3_SAST_168 +|MEDIUM + +|xref:sast-policy-169.adoc[Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')] +|CKV3_SAST_169 +|HIGH + +|xref:sast-policy-170.adoc[Improper Neutralization of Wildcards or Matching Symbols] +|CKV3_SAST_170 +|MEDIUM diff --git a/application-security/policy-reference/sast-policies/sast-policies.adoc b/application-security/policy-reference/sast-policies/sast-policies.adoc new file mode 100644 index 000000000..1114216d0 --- /dev/null +++ b/application-security/policy-reference/sast-policies/sast-policies.adoc @@ -0,0 +1,3 @@ +== SAST Policies + +