java-injection-audit

Audit Java source code for six injection vulnerability classes using dataflow evidence.

1.7k|238|Updated Dec 7, 2019
One-click install
npx skills add https://github.com/wgpsec/AboutSecurity --skill java-injection-audit
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: java-injection-audit
Source: https://github.com/wgpsec/AboutSecurity/tree/main/skills/code-audit/java/java-injection-audit
Command: npx skills add https://github.com/wgpsec/AboutSecurity --skill java-injection-audit

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

White-box auditors reviewing Java codebases need a systematic way to determine whether injection vulnerabilities actually exist, rather than flagging every dangerous API call. This Skill verifies whether filtering along each Source-to-Sink path is sufficient, using structured EVID_* dataflow evidence as audit input.

Core Features & Use Cases

  • Six Injection Classes: Covers SQL injection (JDBC/MyBatis/Hibernate/JPA), command injection (Runtime.exec/ProcessBuilder), SSRF (HttpURLConnection/OkHttp/RestTemplate), SpEL/OGNL expression injection, LDAP injection, and NoSQL injection (MongoDB).
  • Dangerous vs Safe Pattern Comparison: A reference document pairs vulnerable code with secure alternatives, such as MyBatis ${} vs #{}, PreparedStatement misuse, and SimpleEvaluationContext sandboxing.
  • Standardized Severity Scoring: Applies the java-audit-pipeline formula Score = R0.40 + I0.35 + C*0.25 so findings are rated consistently.
  • Use Case: Given EVID_SQL_* evidence showing a MyBatis mapper using ${orderColumn} for ORDER BY, the auditor traces the parameter source, confirms no whitelist exists, marks it confirmed, and assigns a severity score.

Quick Start

Audit the Java project for injection vulnerabilities using the EVID evidence produced by the java-audit-pipeline and report confirmed findings with severity scores.

Frequently Asked Questions about java-injection-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit Java code for SQL injection vulnerabilities?

Trace each SQL execution sink such as Statement.execute or MyBatis mappers back to its input source and check whether parameters use binding. Statement concatenation and MyBatis ${} are dangerous, while PreparedStatement placeholders and #{} binding are safe; ORDER BY identifiers require whitelisting.

What is the difference between MyBatis ${} and #{} for injection risk?

#{} uses parameterized binding and is safe against SQL injection, while ${} performs direct string concatenation and is injectable. Auditors should search globally for ${ occurrences and verify each one is protected by a whitelist, especially in ORDER BY and LIKE clauses.

Does Runtime.exec(String) in Java allow shell command injection?

The single-string form splits on whitespace without invoking a shell, so metacharacters like ; | & are usually not interpreted, but argument injection remains possible. Wrapping commands in sh -c or cmd /c re-enables shell interpretation and is dangerous with user-controlled input.

How can SpEL expression injection lead to remote code execution?

When user input reaches SpelExpressionParser.parseExpression with a StandardEvaluationContext, expressions like T(java.lang.Runtime).getRuntime().exec() execute arbitrary code. Using SimpleEvaluationContext disables type references and constructors, mitigating the risk.

What input does this audit skill require before it can run?

It requires EVID_* dataflow evidence entries produced by Phase 3 of the java-audit-pipeline, such as EVID_SQL_*, EVID_CMD_*, and EVID_SSRF_* records. Sinks without supporting evidence can only be marked as pending verification rather than confirmed.