Add Java security queries: cleartext LDAP, insecure JDBC cert, credentials in URL, IDOR#151
Add Java security queries: cleartext LDAP, insecure JDBC cert, credentials in URL, IDOR#151felickz wants to merge 2 commits into
Conversation
Adds five Java queries (each with a Markdown help doc): - CWE-319 CleartextLdapUrl: ldap:// URL on an LDAP context source - CWE-295 InsecureJdbcCertificateValidation: JDBC trustServerCertificate=true - CWE-598 CredentialsInOutboundUrl: credential getter reaching an outbound request URL - CWE-639 UserControlledRecordRetrieval: read/disclosure IDOR (path id to repository finder) - CWE-639 InsecureDirectObjectReference: modify IDOR, Java analogue of cs/web/insecure-direct-object-reference Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Adds new Java security queries (and corresponding Markdown help) under java/src/security to detect additional transport-security and broken-access-control patterns not covered by default suites/community queries.
Changes:
- Introduces two CWE-639 IDOR-related queries (read/dataflow and write/heuristic) with docs.
- Adds new transport/security misconfiguration queries for cleartext LDAP and insecure JDBC TLS validation, with docs.
- Adds a dataflow query for credentials flowing into outbound HTTP request URLs, with docs.
Show a summary per file
| File | Description |
|---|---|
| java/src/security/CWE-639/UserControlledRecordRetrieval.ql | New path-problem query for @PathVariable id flowing into repository findById-style calls. |
| java/src/security/CWE-639/UserControlledRecordRetrieval.md | Help doc for the record-retrieval IDOR (read/disclosure) query. |
| java/src/security/CWE-639/InsecureDirectObjectReference.ql | New problem query for mutating Spring controller actions keyed by id lacking authorization checks/annotations. |
| java/src/security/CWE-639/InsecureDirectObjectReference.md | Help doc for the mutating IDOR query. |
| java/src/security/CWE-598/CredentialsInOutboundUrl.ql | New path-problem query for credential getters flowing into outbound HTTP URL arguments. |
| java/src/security/CWE-598/CredentialsInOutboundUrl.md | Help doc for outbound-URL credential exposure. |
| java/src/security/CWE-319/CleartextLdapUrl.ql | New problem query for constant ldap:// URLs passed into LDAP context configuration calls. |
| java/src/security/CWE-319/CleartextLdapUrl.md | Help doc for cleartext LDAP URL configuration. |
| java/src/security/CWE-295/InsecureJdbcCertificateValidation.ql | New problem query for JDBC URLs containing trustServerCertificate=true. |
| java/src/security/CWE-295/InsecureJdbcCertificateValidation.md | Help doc for insecure JDBC TLS certificate validation configuration. |
Copilot's findings
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 10/10 changed files
- Comments generated: 4
| from LdapUrlSink sink, string url | ||
| where | ||
| constantStringValue(sink.getUrlArg(), url) and | ||
| url.regexpMatch("(?i)ldap://.*") | ||
| select sink, "LDAP context configured with cleartext URL '" + url + "'; use ldaps:// or STARTTLS." |
| select m, | ||
| "This action may be missing authorization checks for which users can access the resource of the provided id." |
| exists(Annotation a | a = p.getAnAnnotation() | | ||
| a.getType() | ||
| .hasQualifiedName("org.springframework.web.bind.annotation", | ||
| ["PathVariable", "RequestParam"]) and | ||
| a.getAStringArrayValue(["value", "name"]).toLowerCase().matches(["%id", "%idx"]) |
|
@copilot why is this not compiling, it works with latest CodeQL version on my local machine https://github.com/GitHubSecurityLab/CodeQL-Community-Packs/actions/runs/28042925672/job/83013579419 |
- Replace getAValue() with getValue() in InsecureDirectObjectReference.ql to compile against codeql/java-all@7.1.3 (CI uses CLI 2.21.1) - Fix getAStringArrayValue -> getAStringValue for PathVariable/RequestParam annotations (value/name are single String attrs, not arrays) - Remove setUrls from LdapUrlSink (takes String[], not a single constant) - Remove LDAP URL literal from alert message to avoid exposing credentials - Improve InsecureDirectObjectReference alert message clarity
The CI was failing because Fixed in commit that replaces |
What
Adds five Java security queries, each with a Markdown help doc, under
java/src/security. They cover transport-security and broken-access-control patterns that the default CodeQL Java suite and the existing community queries do not flag.CleartextLdapUrl.qlldap://URL configured on an LDAP context source (setUrl/setProviderUrl), transmitting bind credentials in cleartextInsecureJdbcCertificateValidation.qltrustServerCertificate=true, which accepts any server certificate (MITM)CredentialsInOutboundUrl.qlgetPassword/getSecret/...) whose value flows into the URL of an outbound HTTP client callUserControlledRecordRetrieval.ql@PathVariableid flowing into a repository finder (findById/...) with no per-record authorization checkInsecureDirectObjectReference.qlcs/web/insecure-direct-object-referenceWhy
These were found while reproducing a set of true positives that SAST missed on a sample Spring application. The two CWE-639 queries deliberately split IDOR into its two sub-classes:
UserControlledRecordRetrieval(dataflow) covers the read/disclosure case.InsecureDirectObjectReferenceports the C#InsecureDirectObjectReferenceQuerydesign (absence-of-authorization-check on a mutating action) to Spring MVC.Validation
codeql query compile --warnings=erroragainstcodeql/java-all(CLI 2.25.6).codeql query format.CleartextLdapUrl->ctx.setUrl("ldap://...")InsecureJdbcCertificateValidation->DriverManager.getConnectionwithtrustServerCertificate=trueCredentialsInOutboundUrl->props.getPassword()intorestTemplate.getForObject(url)UserControlledRecordRetrieval->@PathVariable idintorepository.findById(id)InsecureDirectObjectReferencereturns no result on that sample because its only id-bearing endpoint is a GET read; it is a faithful port of the first-party C# query, which targets state-changing actions. It fires on mutating endpoints (POST/PUT/DELETE/PATCH or edit/delete/modify/update/save/remove) that lack an authorization check.Notes
java.qlspath glob (kinds problem/path-problem, precision medium and low); no suite changes needed.getAQlClassortoStringregex;regexpMatchis applied only to string values (names, URL literals).