This skill focuses on determining at the source code level whether "an injection holds", with the core being to verify whether the filtering along the Source→Sink path is sufficient. Runtime exploitation techniques such as constructing payloads and bypassing WAFs fall under the scope of the corresponding black-box exploit skill.
In-Depth Reference
- Dangerous pattern / secure pattern code comparison / EVID evidence examples for the 6 types of injection → references/injection-patterns.md
Quick Reference Table for the 6 Types of Injection
| Type | Typical Sink | Dangerous Pattern | Severity |
|---|---|---|---|
| SQL Injection | Statement.execute, session.createQuery, MyBatis ${}, JPA nativeQuery |
String concatenation into SQL | Critical-High |
| Command Injection | Runtime.exec, ProcessBuilder.start, commons-exec |
User input concatenated into a command string or wrapped via sh -c wrapping |
Critical |
| SSRF | HttpURLConnection, OkHttpClient, RestTemplate, WebClient |
User-controllable URL initiates a server-side request | High-Medium |
| SpEL/OGNL Injection | ExpressionParser.parseExpression, ValueStack.findValue, @Value |
User input enters an expression parsing context | Critical |
| LDAP Injection | DirContext.search, LdapTemplate.search |
User input concatenated into a filter string | High-Medium |
| NoSQL Injection | MongoCollection.find, @Query, $where |
String concatenation into a query or operator injection | High |
General Audit Process (4 Steps)
Step 1 -- Confirm EVID Evidence Points: From the java-audit-pipeline EVID_* evidence produced in Phase 3, filter injection-type entries (EVID_SQL_、EVID_CMD_、EVID_SSRF_、EVID_EXPR_、EVID_LDAP_、EVID_NOSQL_). Sinks without EVID evidence can only be marked "to be verified".
Step 2 -- Determine Filtering Effectiveness: Trace each filtering/escaping operation along the Source→Sink path and assess whether it is effective for the current injection type. Common pitfalls: PreparedStatement but the SQL fragment is still constructed by concatenation, MyBatis ${} is misused as #{}、escapeshellarg and other PHP ways of thinking migrated to Java do not apply.
Step 3 -- Assess Bypass Possibility: When filtering exists but is insufficient, analyze the specific bypass path (encoding differences, type confusion, secondary processing, etc.). If a bypass approach can be given, mark it "confirmed"; otherwise mark it "to be verified" and record the known filtering method.
Step 4 -- Determine Severity: Use the java-audit-pipeline three-dimensional scoring formula Score = R*0.40 + I*0.35 + C*0.25. Injection-type vulnerabilities usually have high Impact (command/expression injection I=3, SQL injection I=2-3), but a comprehensive judgment must be made in combination with reachability and exploitation complexity.
Key Points for SQL Injection Auditing
- JDBC PreparedStatement vs Statement:
PreparedStatement+?placeholders are safe,Statement.execute(sql)concatenation is dangerous; note thatPreparedStatementmay still contain concatenated fragments - MyBatis
#{}vs${}:#{}parameter binding is safe,${}direct concatenation is dangerous; ORDER BY scenarios are often forced to use${}, requiring whitelist validation - Hibernate HQL concatenation:
session.createQuery("from User where name='" + input + "'")although it is HQL, it can still be injected - JPA @Query nativeQuery:
@Query(value="...", nativeQuery=true)SpEL in#{#param}or string concatenation are both dangerous - Dynamic sorting ORDER BY: identifiers cannot be parameterized, whitelisting is the only safe solution; Spring Data's
Sortobject is safe
Key Points for Command Injection Auditing
- Runtime.exec(String) vs exec(String[]): The single-string form is split by whitespace into program and arguments and is not automatically interpreted through a shell; the array form is more explicit, but both require attention to
-flagparameter injection - ProcessBuilder: The parameter list form is similar to array exec, but via
sh -c "cmd"wrapping degrades to shell interpretation - Reflective invocation: Invoking via reflection
Runtime.getRuntime()orProcessBuildercan bypass static scanning - commons-exec CommandLine:
CommandLine.parse(userInput)dangerous,addArgument(input, false)safe
SSRF audit key points
- HttpURLConnection:
new URL(userInput).openConnection()— the most basic SSRF entry point - OkHttp / Apache HttpClient / RestTemplate / WebClient: all need to check whether URL parameters are user-controllable
- Protocol restrictions: check whether
http/https（file://is restricted for reading files,jar://SSRF、netdoc://information disclosure) - DNS Rebinding: parsing and validating first and then making the request creates a TOCTOU race
- Redirect following:
HttpURLConnectionfollows same-protocol redirects by default, needsetInstanceFollowRedirects(false)
SpEL/OGNL expression injection audit key points
- SpEL:
new SpelExpressionParser().parseExpression(userInput).getValue()— direct RCE - @Value / @PreAuthorize: referencing user-controllable configuration values in annotations can trigger SpEL parsing
- Thymeleaf SSTI:
__${expr}__preprocessing syntax triggers SpEL execution - OGNL (Struts2):
ActionContext/ValueStackinjection, with many historical vulnerabilities - Safe mode:
SimpleEvaluationContextrestricts SpEL functionality (disables type references and constructors)
LDAP injection audit key points
- Filter concatenation:
"(uid=" + username + ")"— injecting*)(uid=*))(|(uid=*can modify query logic - Safe mode: manually escape
( ) * \ \0or use Spring LDAP'sLdapQueryBuilder/LdapEncoder - DN injection: different from filter injection, need to escape
, + " \ < > ;and other DN special characters
NoSQL injection audit key points
- MongoDB Java Driver:
BasicDBObject/Documentwhen constructing, if a JSON string is concatenated, operators can be injected - Spring Data MongoDB:
@Query("{'name': ?0}")parameterized is safe; string concatenation to construct queries is dangerous - $where / $regex:
$whereaccepts JavaScript expressions, equivalent to code execution when user-controllable - Criteria API:
Criteria.where("name").is(input)is a safe parameterized query method
Detection checklist
- all injection-type EVID_* evidence points have been reviewed one by one
- all SQL concatenation points have been verified for whether parameterization/precompilation is used, MyBatis
${}all marked - every parameter source and construction method of command execution entry points has been checked
- the URL source, protocol restrictions, and redirect policy of SSRF sinks have been confirmed
- the expression sources of SpEL/OGNL parsing entry points have been traced
- the escaping handling of LDAP filters and DNs has been confirmed
- the construction methods of NoSQL query parameters have been checked
- points with insufficient filtering have been given specific bypass ideas or marked "to be verified"
- severity scoring uses a unified formula, consistent with the pipeline