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.