4

Given that rolling one's own is not usually a great security idea, is there a crate or library function in Rust to sanitise a filename? The recent 'nul' crate demonstrates that there's a few OS-specific gotchas.

Squirrel
  • 1,189
  • 12
  • 15
  • 1
    Could you elaborate on what exactly this function should do? Decide whether or not a given filename is potentially dangerous? Or something else? Maybe some examples? :) – Lukas Kalbertodt May 15 '17 at 07:05
  • 6
    Given the number and breadth of filesystems in use, and how they work, I'm not sure any such code *could* be written. For example, `nul` was not a problem because of Windows, it was a problem because of how Git is written. Are filenames that would undergo canonicalisation when written on macOS dangerous? Files that could be interpreted as switches? On which OSes, with which shells? Are spaces dangerous? Invalid characters? Where do you draw the line? – DK. May 15 '17 at 07:12
  • While the OS will tell you if a filename would not be legal, it won't indicate in which way one should convert the input such that the input is a legal filename. Is there an equivilent to .net's IO.Path.GetInvalidFileNameChars such that one could know from the OS what would be legitimate? – Squirrel Jun 20 '17 at 21:09

1 Answers1

5

"Safe" mostly depends on your threat model.

If you simply want to avoid your filesystem from being corrupted through bad filenames, then there's good news, you don't need to do anything since filesystem APIs will reject invalid names with errors. Although if you want file names and not paths you either have to be careful to not use APIs that take AsRef<Path> or strip path separators (see std::path::is_separator), since they will accept absolute or relative paths.

If you need to handle relative paths from untrusted inputs you will at least have to strip .. paths to stop directory traversal attacks.

If you want to avoid attacks on the human instead of the software you will have to do a lot of sanitizing, such as removing Unicode text direction overrides which could mislead the user about file extensions.

The recent 'nul' crate demonstrates that there's a few OS-specific gotchas.

That was not an issue with things being unsafe on a particular platform. The issue here is one of cross-platform compatibility. Something that works on UNIX systems did not translate nicely to Windows systems. But the Windows systems failed safely, it simply caused an error and Cargo handled that error in a particular way (stopping the update). It could have chosen to handle the failure in a different way, e.g. by skipping that one particular crate or by mangling the filename.

the8472
  • 40,999
  • 5
  • 70
  • 122
  • 1
    Agreed, not unsafe in any way. I was just alluding that striping/changing invalid chars is necessary but not always sufficient for a filename to be valid. – Squirrel Jun 20 '17 at 21:13