Add YAML security rules for DocumentBuilderFactory external entities

[ESS-ENN]

Summary by CodeRabbit

• New Features

  • Introduced enhanced security rules that warn when unsafe external entity settings are used in Java XML processing, reducing risks of XXE attacks.

• Tests

  • Added comprehensive test configurations and snapshot validations to ensure these security checks perform as expected.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ ESS-ENN
❌ Sakshis

---

Sakshis seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coderabbitai]

Walkthrough

This pull request introduces two new YAML configuration files that define security rules for Java applications using the DocumentBuilderFactory. One rule targets external general entities and the other targets external parameter entities, flagging any insecure use of these features. In addition, corresponding snapshot and test files are added to validate each rule’s detection of vulnerable method invocations in both valid (secure) and invalid (insecure) scenarios.

Changes

Files	Summary
rules/java/security/documentbuilderfactory-external-general-entities-true-java.yml rules/java/security/documentbuilderfactory-external-parameter-entities-true-java.yml	New security rule definitions for Java that flag usage of external general entities and external parameter entities in DocumentBuilderFactory through method matching.
tests/__snapshots__/documentbuilderfactory-external-general-entities-true-java-snapshot.yml tests/__snapshots__/documentbuilderfactory-external-parameter-entities-true-java-snapshot.yml	New snapshot files capturing labeled state of setFeature method calls when dangerous features are enabled.
tests/java/documentbuilderfactory-external-general-entities-true-java-test.yml tests/java/documentbuilderfactory-external-parameter-entities-true-java-test.yml	New test configuration files that segregate valid and invalid cases for the security rules by setting the targeted features to false (valid) or true (invalid).

Sequence Diagram(s)

sequenceDiagram participant Dev as Developer Code participant Analyzer as Static Analysis Engine participant Rule as YAML Security Rule participant Test as Snapshot/Test Validator Dev->>Analyzer: Write code using DocumentBuilderFactory Analyzer->>Rule: Load external entities security rules Rule-->>Analyzer: Provide matching patterns for setFeature invocations Analyzer->>Analyzer: Evaluate method calls for vulnerable configurations alt Vulnerability Detected Analyzer-->>Dev: Emit warning for enabled external entities else No Issue Analyzer-->>Dev: No warning issued end Analyzer->>Test: Run snapshot and test validations for both scenarios 

Loading

Possibly related PRs

• Add security rules for cookie settings and XML processing in YAML config #66: Introduces a related security rule addressing DOCTYPE declarations in DocumentBuilderFactory, focusing on mitigating XML external entity vulnerabilities.

Suggested reviewers

• ganeshpatro321

Poem

In a YAML field I hop with glee,
Securing code as safe as can be.
Two rules now watch with keen eyes,
Stopping threats that might arise.
Hoppin’ on code with a joyful heart,
Security wins—a perfect art! 🐰

---

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (3)

rules/java/security/documentbuilderfactory-external-general-entities-true-java.yml (2)

1-14: Metadata and Basic Configuration Check
The rule metadata is well defined with a clear id, language, severity, and an explanatory message. However, note that the displayed vulnerability note references “[CWE-798]: Use of Hard-coded Credentials”, which may not accurately describe an XXE issue. Consider verifying whether a CWE like CWE-611 (or another more appropriate identifier for XML external entity vulnerabilities) should be referenced instead.

---

180-274: Combined Matching Expression for Mixed Instances
This complex matching expression combines checks for both URL and Boolean representations in the argument list. While it is comprehensive, the nested conditions are intricate. Consider adding inline documentation or simplifying the structure where possible for improved maintainability.

rules/java/security/documentbuilderfactory-external-parameter-entities-true-java.yml (1)

179-273: Combined Matching Expression for Mixed Instances
The combined block adeptly handles cases with mixed representations of arguments. Despite its complexity, it ensures a wide coverage of potential invocations. Adding a brief comment to explain the rationale behind the nested conditions might help future maintainers.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7c95a04 and 9493a1a.

📒 Files selected for processing (6)

• rules/java/security/documentbuilderfactory-external-general-entities-true-java.yml (1 hunks)
• rules/java/security/documentbuilderfactory-external-parameter-entities-true-java.yml (1 hunks)
• tests/__snapshots__/documentbuilderfactory-external-general-entities-true-java-snapshot.yml (1 hunks)
• tests/__snapshots__/documentbuilderfactory-external-parameter-entities-true-java-snapshot.yml (1 hunks)
• tests/java/documentbuilderfactory-external-general-entities-true-java-test.yml (1 hunks)
• tests/java/documentbuilderfactory-external-parameter-entities-true-java-test.yml (1 hunks)

✅ Files skipped from review due to trivial changes (2)

• tests/snapshots/documentbuilderfactory-external-general-entities-true-java-snapshot.yml
• tests/snapshots/documentbuilderfactory-external-parameter-entities-true-java-snapshot.yml

🔇 Additional comments (13)

tests/java/documentbuilderfactory-external-general-entities-true-java-test.yml (2)

1-5: Approved: Secure Configuration for External General Entities (Valid Cases)
The test configuration correctly defines the secure scenario by setting the feature to false for both dbf and spf. The indentation and block literal style make it very clear.

---

6-9: Approved: Insecure Configuration for External General Entities (Invalid Cases)
The invalid block properly sets the feature to true, thereby simulating the vulnerable scenario for detection. Ensure your test runner interprets the multiline literal correctly.

tests/java/documentbuilderfactory-external-parameter-entities-true-java-test.yml (2)

1-4: Approved: Secure Configuration for External Parameter Entities (Valid Case)
The test case correctly disables external parameter entities by setting the feature to false. The identifier and formatting are clear and concise.

---

5-8: Approved: Insecure Configuration for External Parameter Entities (Invalid Cases)
The invalid block appropriately triggers the detection by enabling the feature for both dbf and spf. The setup is consistent with the intended negative test scenarios.

rules/java/security/documentbuilderfactory-external-general-entities-true-java.yml (4)

16-49: Matching Expression for External General Entities (Literal Argument)
This matching expression correctly captures calls to setFeature that pass the specific URL as a string literal and a "true" value as the second argument. The utilization of regex and nthChild is appropriate and clear.

---

50-113: Matching Expression for Boolean Instance
This block handles cases where the boolean true is provided as a Boolean instance. The check incorporating the exclusion of line comments is thorough. You might want to verify that all relevant representations of a true value in your codebase are being captured.

---

114-150: Matching Expression for Link Instance
The expression targeting cases where the first argument is treated as a URL (using $URL) and the second argument matches "^true$" is well constructed and consistent with the intended detection logic.

---

275-289: Overall Rule Assembly
The final rule section effectively aggregates all the individual matching expressions and uses exclusion rules to prevent false positives. The logical structure is consistent with the intended security detection.

rules/java/security/documentbuilderfactory-external-parameter-entities-true-java.yml (5)

1-12: Metadata and Basic Configuration for External Parameter Entities
The rule’s metadata—comprising id, severity, language, and message—is clearly specified. The note referencing “[CWE-611] Improper Restriction of XML External Entity Reference” is appropriate for external parameter entities.

---

15-48: Matching Expression for External Parameter Entities (Literal Argument)
This matching expression correctly identifies invocations of setFeature that are meant to set the external parameter entities by checking for the specific URL literal and a "true" value. The structure mirrors the secure pattern and is well defined.

---

49-112: Matching Expression for Boolean Instance
The Boolean instance matching block accurately captures boolean values provided as an instance rather than as a literal. The detailed conditions ensure that invalid configurations are reliably detected.

---

113-149: Matching Expression for Link Instance
This expression correctly checks for scenarios where the first argument is interpreted with a $URL placeholder and the second argument is "true". The configuration is consistent and clear.

---

275-289: Overall Rule Assembly
The rule assembly, which aggregates all match expressions and applies an exclusion for error conditions, is logically structured and clear. This final section ties together the individual components effectively.