[Java] Proposal: path traversal rule for archive-derived and constructed paths

Rules and Languages New rules / language support
1

Hi Sonar team,

I would like to ask for feedback on a possible new Java security rule related to path traversal.

While reviewing several Java cases, I noticed a recurring pattern that seems comparatively under-covered: attacker-controlled path components being propagated into file-system paths or resource lookups.

Representative cases include:

  • CVE-2022-4494
  • CVE-2022-39367
  • CVE-2022-31194
  • CVE-2022-29253

The common shapes are:

  • archive-entry-derived paths such as ZipEntry.getName() / JarEntry.getName()
  • request-derived paths propagated through one path-construction step
  • template or resource names later reaching ClassLoader.getResource(…)

A representative archive-entry example is:

while ((zipEntry = zipInputStream.getNextEntry()) != null) {

final File destFile = new File(importSandboxDirectory, zipEntry.getName());

ServiceUtilities.ensureFileCreated(destFile);

final FileOutputStream destOutputStream = new FileOutputStream(destFile);

}

A representative request-derived example is:

String resumableIdentifier = request.getParameter(“resumableIdentifier”);

tempDir = tempDir + File.separator + resumableIdentifier;

File fileDir = new File(tempDir);

fileDir.mkdir();

A representative resource-lookup example is:

String templatePath = suffixPath + templateName;

return classloader.getResource(templatePath);

I prepared a conservative prototype that focuses on:

  • ZipEntry.getName() / JarEntry.getName()
  • getParameter(…)
  • conservative path-like method parameters such as path, file, filename, dir, template, or resource
  • simple propagation through assignment and string concatenation
  • sinks such as new File(…), mkdir(), mkdirs(), createNewFile(), and ClassLoader.getResource(…)

I also validated the prototype on the representative cases above.

The current prototype uses a temporary rule key only for implementation and testing purposes, and I would be happy to align with the usual SonarJava rule-key / RSPEC process.

Before pushing this proposal further, I would really appreciate your feedback on whether this looks like a rule direction that would fit SonarJava’s expectations and rule strategy.

If this seems relevant, I can continue refining the PR accordingly.

Thanks a lot.