Add Java security queries: cleartext LDAP, insecure JDBC cert, credentials in URL, IDOR#151
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
|
@copilot why is this not compiling, it works with latest CodeQL version on my local machine |
- 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 |
|
@felickz Did a quick review. Let me know what you think. |
Co-authored-by: Kevin Stubbings <kwstubbs@github.com>
… String URL arg Hoist the method-name filter so it constrains both the RestOperations and RestTemplate branches (the original only applied it to RestTemplate, so the RestOperations branch matched arg0 of any method whose declaring type descends from RestOperations, including setters/getters and URI/RequestEntity overloads). Add postForLocation and patchForObject, and require the URL arg to be a String. Co-authored-by: Kwstubbs Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ngRequestMappingMethod) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The route accessor on SpringRequestMappingMethod is getValue() in the pinned java-all 7.1.3 (see .codeqlversion 2.21.1 and existing query CWE-094/SpringImplicitViewManipulation.ql). It was renamed to getAValue() in newer library versions, so compiling against the bundled 9.x fails, but the repo's CI resolves the pinned 7.1.3. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* docs: document CodeQL version pinning and pack compatibility - Add a consumer-facing compatibility note in README linking to GitHub's official CodeQL pack compatibility docs, reassuring users that older published packs generally keep working with newer CLIs (with caveats). - Add a maintainer-facing 'Supported CodeQL versions' section in CONTRIBUTING.md documenting the two-file pinning mechanism (.codeqlversion for the CLI, <lang>/src/codeql-pack.lock.yml for the locked library version) with a table of current locked versions per language, including the upstream *-queries dependency used by C/C++ and C# only. - Link out to the community CodeQL Bundle Version Tracker for the broader CLI-to-library version mapping. Motivated by GHSL PR #151 (java-all API rename between 7.1.3 and 9.1.2 causing local/CI compile mismatches) and issue #145 (stale packs). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * docs: split CodeQL CLI references into Bundle and Binary links --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
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).