Useful regex patterns to find vulnerabilities in a Java code and Java security code review tools

README.md

Useful Regex Patterns to Find Vulnerabilities in Java Code

1. Hardcoded Credentials / Secrets

These patterns look for sensitive information directly embedded in the code.

• Generic Passwords / Secrets / Tokens:

  • Regex:

    (?i)(password|passwd|pwd|secret|token|apikey|api_key|access_key|secret_key|access_token|api_secret|apiSecret|app_secret|application_key|app_key|appkey|auth_token|authsecret)\s*=\s*["'][^"']{4,}["']

  • Explanation: Looks for common keywords associated with credentials/secrets followed by an equals sign and a quoted string of at least 4 characters. The {4,} minimum length helps reduce some noise.
  • Example Matches:

    String dbPassword = "admin123";
    private final String API_TOKEN = "abcd1234";
    String accessKey = "AKIAIOSFODNN7EXAMPLE";
    String authSecret = "myAuthSecretValue";

• AWS Access Key ID:

  • Regex:

    (?i)AKIA[0-9A-Z]{16}

  • Explanation: Identifies the standard pattern for AWS Access Key IDs, which begin with AKIA followed by 16 uppercase alphanumeric characters.
  • Example Match:

    String awsAccessKeyId = "AKIAIOSFODNN7EXAMPLE";

• AWS Secret Access Key:

  • Regex:

    (?i)(?<![A-Za-z0-9])[0-9a-zA-Z/+]{40}(?![A-Za-z0-9])

  • Explanation: A more complex pattern to precisely match 40-character AWS Secret Access Keys. The negative lookarounds ((?<!...) and (?!...)) help ensure it's not part of a larger string.
  • Example Match:

    String awsSecretAccessKey = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY";

• Private Keys (PEM format common for RSA/EC):

  • Regex:

    -----BEGIN\s+(RSA|EC|ENCRYPTED)?\s*PRIVATE\s+KEY-----

  • Explanation: Looks for the standard header of PEM-encoded private keys, indicating a cryptographic private key.
  • Example Match:

    String privateKey = "-----BEGIN RSA PRIVATE KEY-----\n...";

2. Runtime Command Execution (RCE)

These patterns look for direct execution of external commands, which can be vulnerable if input is not sanitized.

• Runtime.getRuntime().exec():
  • Regex:

    Runtime\.getRuntime\(\)\.exec\s*\(

  • Explanation: Identifies calls to Runtime.getRuntime().exec(), a common way to execute system commands.
  • Example Matches:

    Runtime.getRuntime().exec("ls -la");
    Process p = Runtime.getRuntime().exec(userCommand); // Vulnerable if userCommand is from untrusted source

• ProcessBuilder with unvalidated arguments:
  • Regex:

    new\s+ProcessBuilder\s*\([^)]*\brequest\.getParameter\s*\([^)]+\)

  • Explanation: Looks for ProcessBuilder being initialized with arguments directly derived from request.getParameter(), indicating potential command injection.
  • Example Match:

    String[] command = {"sh", "-c", request.getParameter("cmd")};
    ProcessBuilder pb = new ProcessBuilder(command);

3. File Operations (Arbitrary File Write / Read / Traversal)

These patterns highlight file operations that might be vulnerable to arbitrary file write/read or path traversal if paths are derived from untrusted input.

• File Write (e.g., Arbitrary File Write Risk):
  • Regex:

    new\s+FileOutputStream\s*\(\s*.*?\)

  • Explanation: Identifies the instantiation of FileOutputStream, which is used for writing data to files.
  • Example Match:

    new FileOutputStream("output.txt");
    FileOutputStream fos = new FileOutputStream(userControlledPath); // Vulnerable if userControlledPath is from untrusted source

• Unrestricted File Read (Local File Inclusion - LFI Risk):
  • Regex:

    new\s+FileInputStream\s*\(\s*.*?\)

  • Explanation: Identifies the instantiation of FileInputStream, which is used for reading data from files.
  • Example Match:

    new FileInputStream("/etc/passwd");
    FileInputStream fis = new FileInputStream(userControlledFilePath); // Vulnerable if userControlledFilePath is from untrusted source

• File I/O with request.getParameter() (General Path Traversal Risk):
  • Regex:

    (new\s+File|Files\.readAllBytes|Files\.write|BufferedReader|BufferedWriter)\s*\(\s*request\.getParameter\s*\(\s*["'][^"']+["']\s*\)\s*\)

  • Explanation: Flags constructors or methods related to common file operations directly using request parameters, indicating a strong path traversal possibility.
  • Example Match:

    File file = new File(request.getParameter("filename"));
    Files.readAllBytes(Paths.get(request.getParameter("filePath")));

• getResourceAsStream with user input:
  • Regex:

    (getClass\(\)\.getResourceAsStream|ClassLoader\.getSystemResourceAsStream)\s*\(\s*request\.getParameter\s*\(\s*["'][^"']+["']\s*\)\s*\)

  • Explanation: Retrieving resources based on user input without validation, potentially leading to information disclosure or LFI.
  • Example Match:

    InputStream is = getClass().getResourceAsStream(request.getParameter("resourceName"));

4. Insecure HTTP Usage

These patterns look for the use of unencrypted HTTP connections where HTTPS should be used.

• "http://" String Literal:
  • Regex:

    "http://[^\s"]+"

  • Explanation: Matches plain "http://" URLs embedded directly in code.
  • Example Match:

    String apiUrl = "http://example.com/api";

5. Insecure Deserialization

These patterns target the deserialization of untrusted data, which can lead to Remote Code Execution (RCE).

• ObjectInputStream Instantiation:
  • Regex:

    ObjectInputStream\s+\w+\s*=\s*new\s+ObjectInputStream\s*\(.*?

  • Explanation: Flags the creation of an ObjectInputStream, which can deserialize arbitrary Java objects. If the input source is untrusted, this is a major vulnerability.
  • Example Matches:

    ObjectInputStream ois = new ObjectInputStream(input);
    ObjectInputStream in = new ObjectInputStream(new FileInputStream("data.ser"));

• ObjectInputStream.readObject() Call:
  • Regex:

    new\s+ObjectInputStream\s*\(.*?\)\.readObject\(\)

  • Explanation: More specifically targets the readObject() call, which triggers deserialization.
  • Example Match:

    MyObject obj = (MyObject) new ObjectInputStream(inputStream).readObject();

• Libraries known for deserialization vulnerabilities (e.g., XStream, Jackson when misconfigured):
  • Regex (XStream from untrusted source):

    new\s+XStream\(\)\.fromXML\s*\(\s*(new\s+FileReader|new\s+FileInputStream|request\.getParameter).*?\)

  • Explanation: Looking for XStream parsing XML directly from a file or user input without security configurations.
  • Example Match:

    XStream xstream = new XStream();
    Object obj = xstream.fromXML(new FileReader("config.xml"));

6. SQL Injection Prone Statements

These patterns help identify areas where SQL queries might be susceptible to injection.

• Statement Creation:
  • Regex:

    Statement\s+\w+\s*=\s*conn\.createStatement\s*\(\)

  • Explanation: Flags the creation of a java.sql.Statement object. While not directly a vulnerability, Statement objects are often used for dynamic SQL queries that are prone to injection if not handled carefully (unlike PreparedStatement).
  • Example Match:

    Statement stmt = conn.createStatement();

• Direct String Concatenation into Statement.executeQuery() or executeUpdate():
  • Regex:

    (createStatement\(\)\.executeQuery|createStatement\(\)\.executeUpdate|prepareStatement\([^)]+\)\.executeQuery|prepareStatement\([^)]+\)\.executeUpdate)\(\s*".*?"\s*\+\s*[a-zA-Z_][a-zA-Z0-9_]*

  • Explanation: Looks for executeQuery or executeUpdate calls where the SQL string is being built using string concatenation (+) with a variable. This strongly indicates dynamic SQL potentially vulnerable to injection if the variable isn't properly sanitized or parameterized.
  • Example Matches:

    Statement stmt = connection.createStatement();
    ResultSet rs = stmt.executeQuery("SELECT * FROM users WHERE username = '" + username + "'");
    
    PreparedStatement ps = connection.prepareStatement("SELECT * FROM products WHERE category = '" + categoryName + "'"); // This indicates a misused PreparedStatement

• Concatenation with String.format() for SQL:
  • Regex:

    String\.format\s*\(\s*".*?(SELECT|UPDATE|INSERT|DELETE|FROM|WHERE).*?"\s*,\s*.*?

  • Explanation: Flags String.format() calls that explicitly contain SQL keywords in the format string, suggesting dynamic query construction where parameters might not be properly escaped.
  • Example Match:

    String query = String.format("SELECT * FROM items WHERE id = %s", itemId);

7. Insecure Temporary File Creation

These patterns identify the creation of temporary files that might have insecure permissions or predictable names.

• File.createTempFile():
  • Regex:

    File\s+\w+\s*=\s*File\.createTempFile\s*\(

  • Explanation: Flags calls to File.createTempFile(). While useful, these can be insecure if permissions are not set correctly or if the filename is predictable, leading to TOCTOU (Time-of-Check to Time-of-Use) vulnerabilities.
  • Example Match:

    File temp = File.createTempFile("abc", ".tmp");

8. Unsafe Reflection

These patterns look for the use of reflection that could lead to RCE if the class name or method name is derived from untrusted input.

• Class.forName() with string literal (potential for arbitrary class loading):
  • Regex:

    Class\.forName\s*\(\s*".*?"\s*\)

  • Explanation: Matches calls to Class.forName() with a string literal. If this literal is eventually constructed from external input, it can allow an attacker to load arbitrary classes.
  • Example Match:

    Class<?> myClass = Class.forName("com.example.MyClass");

• Class.forName() with request.getParameter() (Direct RCE risk):
  • Regex:

    Class\.forName\s*\(\s*request\.getParameter\s*\([^)]+\)\s*\)

  • Explanation: Directly loading a class name from user input, a critical vulnerability that can lead to RCE.
  • Example Match:

    Class<?> dynamicClass = Class.forName(request.getParameter("className"));

9. Weak Cryptography

These patterns identify the use of outdated or insecure cryptographic algorithms.

• MD5/SHA-1 Hashing Algorithm:
  • Regex:

    MessageDigest\.getInstance\s*\(\s*"(MD5|SHA-1)"\s*\)

  • Explanation: Flags the use of MD5 or SHA-1 in MessageDigest.getInstance(). These algorithms are considered cryptographically weak and should not be used for security-critical operations like password hashing or digital signatures.
  • Example Match:

    MessageDigest.getInstance("MD5");
    MessageDigest.getInstance("SHA-1");

10. Insecure Cookie Settings

These patterns look for cookies that might be missing crucial security flags like HttpOnly or Secure.

• new Cookie() Instantiation (Missing Flags):
  • Regex:

    new\s+Cookie\s*\(\s*".*?"\s*,\s*".*?"\s*\)

  • Explanation: Identifies the creation of a javax.servlet.http.Cookie object. While not a direct vulnerability, this is a flag to check if .setHttpOnly(true) and .setSecure(true) are being called on these cookies to prevent XSS (HttpOnly) and ensure transmission over HTTPS (Secure).
  • Example Match:

    Cookie cookie = new Cookie("sessionId", "abc123"); // Needs further inspection for setHttpOnly/setSecure

11. Unvalidated/Open Redirect

These patterns find code that redirects users to URLs based on unvalidated input.

• response.sendRedirect() with request.getParameter():
  • Regex:

    response\.sendRedirect\s*\(\s*request\.getParameter\s*\([^)]+\)\s*\)

  • Explanation: Flags response.sendRedirect() calls where the redirect URL is directly taken from a request parameter without validation, leading to open redirect vulnerabilities.
  • Example Match:

    response.sendRedirect(request.getParameter("url"));

12. Disabling SSL/TLS Verification (MITM Risk)

These patterns indicate configurations that weaken SSL/TLS security.

• Custom HostnameVerifier that always returns true:
  • Regex:

    HostnameVerifier\s+\w+\s*=\s*new\s+HostnameVerifier\s*\(\)\s*{[\s\S]*?return\s+true;

  • Explanation: Detects custom HostnameVerifier implementations that effectively disable hostname verification by always returning true for verify() method, making the application vulnerable to Man-in-the-Middle (MITM) attacks.
  • Example Match:

    HostnameVerifier allHostsValid = new HostnameVerifier() {
        public boolean verify(String hostname, SSLSession session) {
            return true; // INSECURE
        }
    };

• Trusting All Certificates (e.g., TrustAllCerts):
  • Regex:

    (?i)TrustManager\[\]\s+trustAllCerts\s*=\s*new\s+TrustManager\[\]\s*{\s*new\s+X509TrustManager\(\)\s*{[\s\S]*?checkClientTrusted\s*\(|checkServerTrusted\s*\(|getAcceptedIssuers\(\)

  • Explanation: Looks for implementations of X590TrustManager that might be configured to blindly trust all certificates, circumventing proper certificate validation.
  • Example Match:

    TrustManager[] trustAllCerts = new TrustManager[] {
        new X509TrustManager() {
            public java.security.cert.X509Certificate[] getAcceptedIssuers() { return null; }
            public void checkClientTrusted(X509Certificate[] certs, String authType) { }
            public void checkServerTrusted(X509Certificate[] certs, String authType) { } // INSECURE
        }
    };

13. Weak Random Number Generation

These patterns flag the use of java.util.Random for security-sensitive operations, which is not cryptographically strong.

• new Random() Instantiation:
  • Regex:

    new\s+Random\s*\(

  • Explanation: Identifies the creation of a java.util.Random object. If this is used for generating security-sensitive values (e.g., session IDs, cryptographic keys, tokens), it's a vulnerability because Random is predictable. SecureRandom should be used instead.
  • Example Match:

    Random rand = new Random();

14. Disabling CSRF Protection (Spring Security Specific)

These patterns look for explicit disabling of CSRF protection in Spring Security configurations.

• csrf().disable():
  • Regex:

    csrf\s*\(\)\s*\.disable\s*\(\)

  • Explanation: Specifically targets csrf().disable() in Spring Security configurations, which turns off Cross-Site Request Forgery (CSRF) protection and makes the application vulnerable to CSRF attacks.
  • Example Match:

    http.csrf().disable();

15. Overly Broad Exception Handling (Catch-All)

These patterns identify generic exception handling that can hide underlying issues and prevent proper error logging/response.

• catch (Exception e):
  • Regex:

    catch\s*\(\s*Exception\s+\w+\s*\)

  • Explanation: Flags catch (Exception e) blocks. While not a direct vulnerability, this is often considered a "code smell" in security as it can silently swallow important error information (e.g., SQL errors, path traversal attempts), making debugging and vulnerability detection difficult. It's better to catch specific exceptions.
  • Example Match:

    try {
        // ... some code
    } catch (Exception e) { // Catches all exceptions, potentially masking issues
        // ...
    }

16. Logging Sensitive Information

These patterns look for attempts to log sensitive data, which can lead to information disclosure if logs are compromised.

• Logging Keywords (Password, Secret, Token, Key):
  • Regex:

    logger\.\w+\s*\(\s*".*?(password|secret|token|key|access_key|secret_key|access_token|api_secret|apiSecret|app_secret|application_key|app_key|appkey|auth_token|authsecret).*?"\s*\)

  • Explanation: Flags logging calls (logger.info, logger.debug, etc.) that contain sensitive keywords within the log message, indicating potential sensitive data leakage to logs.
  • Example Match:

    logger.info("User password: " + userPassword);
    logger.debug("API token received: " + apiToken);

17. Cross-Site Scripting (XSS)

These patterns look for unescaped user input being written directly into HTML/JSP outputs.

• Direct Print of Request Parameters in JSP/Servlets:
  • Regex (JSP):

    <%=\s*request\.getParameter\s*\(\s*["'][^"']+["']\s*\)\s*%>

  • Regex (Servlet/Java):

    response\.getWriter\(\)\.print\s*\(\s*request\.getParameter\s*\(\s*["'][^"']+["']\s*\)\s*\)

  • Explanation: Directly printing request.getParameter() without explicit escaping.
  • Example Match:

    // In a JSP:
    <p>Hello, <%= request.getParameter("name") %></p>
    
    // In a Servlet:
    response.getWriter().print("Welcome " + request.getParameter("username"));

• Appending User Input to HTML elements (e.g., in Servlet):
  • Regex:

    (out\.println|append)\s*\(\s*".*?<[^>]+".*?\s*\+\s*request\.getParameter\s*\(\s*["'][^"']+["']\s*\)\s*\)

  • Explanation: Looks for output methods (println, append) where an HTML tag is combined with raw request parameter.
  • Example Match:

    out.println("<h1>Hello " + request.getParameter("name") + "</h1>");

18. XXE (XML External Entity)

These patterns look for XML parsers that are not configured to disable external entities.

• Default DocumentBuilderFactory usage:
  • Regex:

    DocumentBuilderFactory\.newInstance\(\)\.newDocumentBuilder\(\)\.parse\s*\(

  • Explanation: This identifies common XML parsing. You'd then need to manually check if setFeature is used to disable external entities (e.g., XMLConstants.FEATURE_SECURE_PROCESSING).
  • Example Match:

    DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
    DocumentBuilder db = dbf.newDocumentBuilder();
    Document doc = db.parse(new File("input.xml"));

List of Java security code review tools:

Name	Link	Free/Paid	Other Info
SonarQube	https://www.sonarqube.org/	Free (Community Edition) / Paid (Enterprise, Data Center Editions)	A comprehensive platform for continuous code quality and security analysis. Supports over 25 programming languages including Java. Detects bugs, code smells, and security vulnerabilities (OWASP Top 10). Integrates with IDEs (SonarLint) and CI/CD pipelines. Offers quality gates to prevent sub-par code from being merged.
Snyk Code	https://snyk.io/product/snyk-code/	Free (for open-source projects, limited private projects) / Paid	Developer-first SAST tool with AI-powered scanning. Focuses on real-time vulnerability detection in custom code and open-source dependencies. Provides actionable remediation advice and integrates seamlessly into IDEs and CI/CD pipelines. Prioritizes risks with detailed scoring.
Checkmarx	https://checkmarx.com/	Paid	Enterprise-grade SAST solution known for supporting a wide range of languages including Java. Detects various vulnerabilities like SQL injection, XSS. Offers deep integration into CI/CD pipelines and allows for customizable scanning rules. Utilizes data flow analysis.
Veracode	https://www.veracode.com/	Paid	Cloud-based platform providing comprehensive application security, including SAST and DAST (Dynamic Application Security Testing). Offers actionable remediation insights and integrates with various development tools. Suitable for large enterprises.
OpenText SAST (Fortify)	https://www.microfocus.com/en-us/solutions/application-security/static-code-analyzer	Paid	Enterprise-level SAST tool that excels at detecting vulnerabilities across large Java codebases. Supports numerous languages and offers customizable rules. Integrates into CI/CD environments for continuous security monitoring. Comprehensive vulnerability category support (e.g., 1,657 categories).
PMD	https://pmd.github.io/	Free (Open Source)	A static code analyzer that detects common programming mistakes, code style violations, and performance issues. While not solely focused on security, it can identify issues that may lead to vulnerabilities (e.g., empty catch blocks, unused variables). Supports Java and other languages. Integrates with build tools like Maven and Gradle.
SpotBugs	https://spotbugs.github.io/	Free (Open Source)	Successor to FindBugs. A static analysis tool that identifies potential bugs in Java programs by inspecting bytecode for "bug patterns." Includes security detectors and can identify bad coding practices. Offers integration with build tools like Ant, Maven, and Gradle, and various IDEs via third-party plugins (e.g., find-sec-bugs for security).
Checkstyle	https://checkstyle.sourceforge.io/	Free (Open Source)	Primarily a style and formatting checker for Java code, but can also enforce certain coding standards that indirectly contribute to security by promoting readable and maintainable code, reducing the likelihood of errors. Comes with default configurations for popular Java coding conventions. Highly configurable.
Semgrep	https://semgrep.dev/	Free (Open Source) / Paid (Semgrep App)	Lightweight and customizable SAST tool. Allows developers to easily create and apply custom security rules. Supports over 30 programming languages including Java. Known for its speed and flexibility in vulnerability detection. Can be integrated into CI/CD workflows.
CodeQL (GitHub)	https://codeql.github.com/	Free (for open-source projects on GitHub) / Paid (GitHub Enterprise)	A powerful semantic code analysis engine developed by GitHub. Allows users to write custom queries to find security vulnerabilities and bugs. Integrates directly into GitHub Actions and repositories. Requires expertise to write effective queries.
Codacy	https://www.codacy.com/	Free (for open-source projects) / Paid	Cloud-based platform for automated code quality and security analysis. Provides insights into code quality, security, and test coverage. Supports over 40 languages including Java. Integrates with CI/CD pipelines and provides real-time feedback with customizable rules.
DeepSource	https://deepsource.io/	Free (for open-source) / Paid	Automated code review and code health platform. Focuses on finding issues across bug risks, security, anti-patterns, performance, documentation, and style. Offers an "Autofix" feature for some issues. Integrates with popular repositories like GitHub and GitLab.
Klocwork	https://www.perforce.com/products/klocwork	Paid	Robust static analysis tool that focuses on detecting deep vulnerabilities like memory leaks and concurrency issues. Compliant with industry standards like MISRA and CERT, making it suitable for safety-critical environments.
OWASP Dependency-Check	https://owasp.org/www-project-dependency-check/	Free (Open Source)	Specifically focuses on identifying known vulnerable components (libraries, frameworks) used in a project. It's a Software Composition Analysis (SCA) tool rather than a full SAST tool, but crucial for Java security. Integrates with Maven, Gradle, Ant, Jenkins, etc.

Notes:

• No tool is perfect. Manual review is necessary to identify false positives.
• SAST is good for finding vulnerabilities in your own code, while SCA focuses on third-party libraries.
• DAST (Dynamic Application Security Testing) and IAST (Interactive Application Security Testing) are also important but typically run during or after application execution.
• Open-source tools offer a great starting point, while commercial tools often provide more advanced features/support

References:

• https://rules.sonarsource.com/java/type/Vulnerability/RSPEC-2631/
• https://wiki.sei.cmu.edu/confluence/display/java/SEI+CERT+Oracle+Coding+Standard+for+Java
• https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/05-checklist.html