I am about to start using https://find-sec-bugs.github.io. It is reporting an error of: Bug type PATH_TRAVERSAL_IN for the following code:

 def writeLocalFile(fileName: String, content: String): Unit = {
    Files.write(Paths.get(fileName), content.getBytes(StandardCharsets.UTF_8))

As mitigation

if (!file.exists()) {
        return Response.status(Status.NOT_FOUND).build();

is suggested (i.e something which makes sense for a web application. My application is

  • trying to write a file (so it could be true that the file does not exist
  • a spark data analytics job not facing regular web security problems as it is only executed in firewalled backends

Nonetheless I would like to understand if:

  • this is a false positive, if yes how can it be ignored
  • otherwise how to properly fix given that writing to a non existing path should should create it.

According to the documentation found here

This warning is raised because you're passing a variable into the Paths.get function. It could lead to overwriting of files you didn't intend.

In fact, I believe your mitigation technique would only serve to help an attacker because you'd only be allowing them to overwrite files that exist.

The documentation says:


A file is opened to write to its contents. The filename comes from an input parameter. If an unfiltered parameter is passed to this file API, files at an arbitrary filesystem location could be modified.

This rule identifies potential path traversal vulnerabilities. In many cases, the constructed file path cannot be controlled by the user. If that is the case, the reported instance is a false positive.

If I were you I would look at rearchitecting this. Do you really need to pass in the path or can it be hardcoded to some constant value?

You may want to reconsider all angles of attack on this.

| improve this answer | |
  • ` Files.write(Paths.get(basePath, FilenameUtils.getName(fileName)), content.getBytes(StandardCharsets.UTF_8)) ` – Georg Heiler Jul 5 '18 at 21:11
  • 1
    @GeorgHeiler - even assembling the path isn't safe - there are "psuedo" directory entries for navigating the tree (that is, ../). If the end user gets to supply the raw path they can maneuver to their heart's content. Note that explicitly blacklisting such things may not work: there may be other such pseudo directories, or the file system may perform some sort of unicode resolution or decoding (think & type of entries). Whitelisting is always easier/safer. – Clockwork-Muse Jul 5 '18 at 23:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.