rules-clojure

Potential Command Injection: Detected string concatenation for commands passed to clojure.java.shell/sh. This is highly vulnerable to command injection if user input is involved. Always pass commands and arguments as a vector (e.g., `(sh ["ls" "-l" user-input])`) to prevent shell metacharacter interpretation and ensure arguments are treated as literal values.

Discouraged Legacy Database Library: Detected usage of `clojure.java.jdbc` without `next.jdbc` also being present. While functional, `next.jdbc` is the modern, recommended library for Clojure database access, offering improved performance, better security features (e.g., built-in parameterization), and a more idiomatic API. Consider using `next.jdbc` for new database interactions to leverage these benefits and reduce potential pitfalls associated with older libraries.

Insecure HTTP Client Configuration: Detected `clj-http.client` call with `:insecure? true`. This disables SSL/TLS certificate validation, making the application vulnerable to Man-in-the-Middle (MITM) attacks by allowing connections to servers with invalid or self-signed certificates. Ensure SSL/TLS verification is enabled for production environments. Remove `:insecure? true` or set it to `false`.

Unsafe Java deserialization via ObjectInputStream detected (CWE-502). Java object deserialization of untrusted data is a critical RCE vector — CVE-2015-4852 (Apache Commons Collections) and many follow-on gadget chains allow arbitrary code execution. Never deserialize data from untrusted sources with the default Java deserializer. Use JSON/EDN/Transit with explicit schemas, or if Java serialization is unavoidable, apply a serialization filter (ObjectInputFilter, Java 9+) that allowlists expected types.

Potential Path Traversal: Detected string concatenation for file paths passed to `java.io.File.` constructor. This can lead to path traversal vulnerabilities if user input is involved, allowing access to arbitrary files on the system. Sanitize and validate all path components, use `java.nio.file.Path` with proper resolution, and canonicalize paths (e.g., `.getCanonicalPath()`) to restrict file access to intended directories.

Potential SQL Injection: Detected string concatenation for SQL queries passed to clojure.java.jdbc/query or next.jdbc/execute!. This is highly vulnerable to SQL injection if user input is involved. Always use parameterized queries (e.g., `(jdbc/query db-spec ["SELECT * FROM users WHERE name = ?" user-input])` or `(next.jdbc/execute! ds ["SELECT * FROM users WHERE name = ?" user-input])`) to prevent malicious input from altering query logic.

Critical Code Execution Vulnerability: Detected usage of `read-string`, `eval`, or `load-string`. These functions can execute arbitrary Clojure code and are extremely dangerous if used with untrusted input, leading to Remote Code Execution (RCE). For reading data, use `clojure.edn/read-string` which is a safer alternative for EDN data. Avoid `eval` and `load-string` in production code, especially when processing dynamic or untrusted input.

Potential XML External Entity (XXE) injection (CWE-611). Clojure's `clojure.xml/parse` and bare `DocumentBuilderFactory` instances process external entities by default, allowing attackers to read local files or trigger SSRF. Use data.xml with external entity expansion disabled, or configure the SAX/DOM parser with setFeature("http://xml.org/sax/features/external-general-entities", false). See OWASP XXE Prevention Cheat Sheet.