feat(java): detect direct positive-index access into String.split(...) result without length check (CWE-248/754)

[ai-anant]

Summary

New generic Java rule detecting the pattern where the result of String.split(...) is indexed at a positive literal offset in the same expression (e.g. someString.split(SEP)[1], ...split(SEP)[3], or ...split(SEP)[2].someMethod()) without first verifying the split-array length.

Why

When the input string does not contain enough separator-delimited segments, the direct index throws an uncaught ArrayIndexOutOfBoundsException. If the split input is at all attacker-influenced (file contents, log lines, request data, structured report payloads), this is an uncaught-exception denial-of-service (CWE-248 / CWE-754) that aborts the enclosing build/request/worker thread. The >0-index access is distinct from index 0, which is always safe for String.split (never throws), hence the rule targets only positive literal offsets.

Rule

• Path: java/indexing/unchecked-split-index.yaml
• Id: codevigilant.java.indexing.unchecked-split-index
• Severity: MEDIUM
• CWE: 248 (Uncaught Exception) / 754 (Improper Check for Unusual or Exceptional Conditions)
• Detection: direct-chain split($SEP)[$N], split($SEP, $LIMIT)[$N], split($SEP)[$N].$METHOD($ARGS) with $N a positive integer literal ([1-9][0-9]*).

Test

• Positive: three direct positive-index split shapes — all fire.
• Negative: a length-checked (guard-clause) variant using index 0 — silent.
• semgrep --validate passes; semgrep --config java/ passes on the tree.