False Negative: Unsafe hostname verification is under-modeled in anonymous classes, lambdas, and API variants.

[Carlson-JLQ]

False Negative: Unsafe hostname verification is under-modeled in anonymous classes, lambdas, and API variants.

Version
codeql 2.24.3

Checker

• Checker id: Security/CWE/CWE-297/UnsafeHostnameVerification.ql
• Checker description: This checker detects hostname verifier implementations that always accept any certificate regardless of hostname mismatch, potentially enabling man-in-the-middle attacks.

Description of the false negative

diff/output marks 10 false negatives for Security/CWE/CWE-297/UnsafeHostnameVerification.ql. Across these samples, the benchmark is still exercising the same underlying bug pattern, but the implementation appears to lose track of it once the source deviates from one canonical shape. The recurring themes are suppression or annotations.

Affected test cases

PosCase1.java

Source: output/sonarqube/VerifiedServerHostnamesCheck/src/main/java/scensct/core/pos/PosCase1.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. The risky pattern is still present in the code, so the absence of a report points to a matching gap rather than a benign variant. That is also how the benchmark classifies the sample: A class implementing HostnameVerifier with verify method returning true should be flagged as insecure.

// A class implementing HostnameVerifier with verify method returning true should be flagged as insecure.
package scensct.core.pos;

import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.SSLSession;

public class PosCase1 implements HostnameVerifier {
    @Override
    public boolean verify(String hostname, SSLSession session) {
        return true; // Scenario 1: verify method body is solely return true; // [REPORTED LINE]
    }
}

PosCase10.java

Source: output/sonarqube/VerifiedServerHostnamesCheck/src/main/java/scensct/core/pos/PosCase10.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. The risky pattern is still present in the code, so the absence of a report points to a matching gap rather than a benign variant. That is also how the benchmark classifies the sample: A Hashtable object invoking put with SSL socket factory key and other put calls on same Hashtable, none with checkserveridentity key, should be flagged as insecure.

// A Hashtable object invoking put with SSL socket factory key and other put calls on same Hashtable, none with checkserveridentity key, should be flagged as insecure.
package scensct.core.pos;

import java.util.Hashtable;

public class PosCase10 {
    public void configure() {
        Hashtable<String, String> props = new Hashtable<>();
        props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory"); // Scenario 10: put with SSL factory // [REPORTED LINE]
        props.put("mail.smtp.host", "smtp.example.com"); // other put call, not with checkserveridentity key
    }
}

PosCase2.java

Source: output/sonarqube/VerifiedServerHostnamesCheck/src/main/java/scensct/core/pos/PosCase2.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. The risky pattern is still present in the code, so the absence of a report points to a matching gap rather than a benign variant. That is also how the benchmark classifies the sample: A lambda expression assigned to HostnameVerifier with non-block body literal true should be flagged as insecure.

// A lambda expression assigned to HostnameVerifier with non-block body literal true should be flagged as insecure.
package scensct.core.pos;

import javax.net.ssl.HostnameVerifier;

public class PosCase2 {
    public static void main(String[] args) {
        HostnameVerifier verifier = (hostname, session) -> true; // Scenario 2: lambda with non-block body true // [REPORTED LINE]
    }
}

PosCase3.java

Source: output/sonarqube/VerifiedServerHostnamesCheck/src/main/java/scensct/core/pos/PosCase3.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. The risky pattern is still present in the code, so the absence of a report points to a matching gap rather than a benign variant. That is also how the benchmark classifies the sample: A lambda expression assigned to HostnameVerifier with block body containing only return true should be flagged as insecure.

// A lambda expression assigned to HostnameVerifier with block body containing only return true should be flagged as insecure.
package scensct.core.pos;

import javax.net.ssl.HostnameVerifier;

public class PosCase3 {
    public static void main(String[] args) {
        HostnameVerifier verifier = (hostname, session) -> {
            return true; // Scenario 3: lambda block body with only return true; // [REPORTED LINE]
        };
    }
}

PosCase4.java

Source: output/sonarqube/VerifiedServerHostnamesCheck/src/main/java/scensct/core/pos/PosCase4.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. The risky pattern is still present in the code, so the absence of a report points to a matching gap rather than a benign variant. That is also how the benchmark classifies the sample: An Email object invoking setSSL(true) with no other method invocations in the method should be flagged as insecure.

// An Email object invoking setSSL(true) with no other method invocations in the method should be flagged as insecure.
package scensct.core.pos;

import org.apache.commons.mail.Email;
import org.apache.commons.mail.SimpleEmail;

public class PosCase4 {
    public void sendEmail() {
        Email email = new SimpleEmail();
        email.setSSL(true); // Scenario 4: only method call in method // [REPORTED LINE]
    }
}

PosCase5.java

Source: output/sonarqube/VerifiedServerHostnamesCheck/src/main/java/scensct/core/pos/PosCase5.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. The risky pattern is still present in the code, so the absence of a report points to a matching gap rather than a benign variant. That is also how the benchmark classifies the sample: An Email object invoking setSSL(true) with no other method invocations on that same object in the method should be flagged as insecure.

// An Email object invoking setSSL(true) with no other method invocations on that same object in the method should be flagged as insecure.
package scensct.core.pos;

import org.apache.commons.mail.Email;
import org.apache.commons.mail.SimpleEmail;

public class PosCase5 {
    public void sendEmail() {
        Email email = new SimpleEmail();
        email.setSSL(true); // Scenario 5: no other calls on this email object // [REPORTED LINE]
        String str = "test";
        str.length(); // call on other object is allowed
    }
}

PosCase6.java

Source: output/sonarqube/VerifiedServerHostnamesCheck/src/main/java/scensct/core/pos/PosCase6.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. The risky pattern is still present in the code, so the absence of a report points to a matching gap rather than a benign variant. That is also how the benchmark classifies the sample: An Email object invoking setSSL(true) with other method calls on same object, none being setSSLCheckServerIdentity, should be flagged as insecure.

// An Email object invoking setSSL(true) with other method calls on same object, none being setSSLCheckServerIdentity, should be flagged as insecure.
package scensct.core.pos;

import org.apache.commons.mail.Email;
import org.apache.commons.mail.SimpleEmail;

public class PosCase6 {
    public void sendEmail() {
        Email email = new SimpleEmail();
        email.setSSL(true); // Scenario 6: setSSL called // [REPORTED LINE]
        email.setHostName("smtp.example.com"); // other call on same object, not setSSLCheckServerIdentity
    }
}

PosCase7.java

Source: output/sonarqube/VerifiedServerHostnamesCheck/src/main/java/scensct/core/pos/PosCase7.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. The risky pattern is still present in the code, so the absence of a report points to a matching gap rather than a benign variant. That is also how the benchmark classifies the sample: A Hashtable object invoking put with SSL socket factory key and no other method invocations in the method should be flagged as insecure.

// A Hashtable object invoking put with SSL socket factory key and no other method invocations in the method should be flagged as insecure.
package scensct.core.pos;

import java.util.Hashtable;

public class PosCase7 {
    public void configure() {
        Hashtable<String, String> props = new Hashtable<>();
        props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory"); // Scenario 7: only method call in method // [REPORTED LINE]
    }
}

PosCase8.java

Source: output/sonarqube/VerifiedServerHostnamesCheck/src/main/java/scensct/core/pos/PosCase8.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. The risky pattern is still present in the code, so the absence of a report points to a matching gap rather than a benign variant. That is also how the benchmark classifies the sample: A Hashtable object invoking put with SSL socket factory key and no other method invocations on that same Hashtable in the method should be flagged as insecure.

// A Hashtable object invoking put with SSL socket factory key and no other method invocations on that same Hashtable in the method should be flagged as insecure.
package scensct.core.pos;

import java.util.Hashtable;

public class PosCase8 {
    public void configure() {
        Hashtable<String, String> props = new Hashtable<>();
        props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory"); // Scenario 8: no other calls on this Hashtable // [REPORTED LINE]
        String s = "test";
        s.length(); // call on other object is allowed
    }
}

PosCase9.java

Source: output/sonarqube/VerifiedServerHostnamesCheck/src/main/java/scensct/core/pos/PosCase9.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. The risky pattern is still present in the code, so the absence of a report points to a matching gap rather than a benign variant. That is also how the benchmark classifies the sample: A Hashtable object invoking put with SSL socket factory key and other method calls on same Hashtable, none being put, should be flagged as insecure.

// A Hashtable object invoking put with SSL socket factory key and other method calls on same Hashtable, none being put, should be flagged as insecure.
package scensct.core.pos;

import java.util.Hashtable;

public class PosCase9 {
    public void configure() {
        Hashtable<String, String> props = new Hashtable<>();
        props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory"); // Scenario 9: put with SSL factory // [REPORTED LINE]
        props.size(); // other call on same Hashtable, not a put method
    }
}

Cause analysis

The rule is documented as follows: This checker detects hostname verifier implementations that always accept any certificate regardless of hostname mismatch, potentially enabling man-in-the-middle attacks.

In this set the problem shows up around suppression or annotations. The missed cases suggest that the implementation is narrower than the rule description and too dependent on one preferred AST shape.

Once the same behavior is expressed through a helper, an overload, a modifier such as abstract or native, a different comment position, or a slightly rearranged control-flow structure, the report disappears even though the benchmark still treats the case as in-scope.

For Security/CWE/CWE-297/UnsafeHostnameVerification.ql, the practical improvement would be to generalize the match so it follows the underlying behavior rather than one exact spelling of it.

References

None known.

[redsun82]

@Carlson-JLQ thanks for the report, but I don't think this one holds up.

PosCase1–3 (HostnameVerifier returning true): These are already detected and tested — see our existing test file which covers anonymous classes (line 14), lambdas (line 26), named classes (line 107), and variables (line 87). The query requires the verifier to flow into a sink like HttpsURLConnection.setDefaultHostnameVerifier(...). If your test cases just define the verifier without wiring it to a sink, that would explain why nothing is reported — that's by design, not a false negative.

PosCase4–10 (Apache Commons Email.setSSL(true), Hashtable.put with SSL socket factory key): These are out of scope for UnsafeHostnameVerification.ql, but they are covered by a separate query: InsecureJavaMail.ql (java/insecure-smtp-ssl). It looks like you may be comparing against a broader rule from another tool that bundles multiple SSL-related checks under one rule ID.