4

What is the common practice to sanitize a filename from an outside source (e.g.: xml file) before using it within a subprocess (shell=False)?

Update: Before sending some parsed strings around I would like to make some basic security checks. The given example uses mpg123 (a command line audioplayer) in remote mode to play a sound file.

filename = child.find("filename").text # e.g.: filename = "sound.mp3"
pid = subprocess.Popen(["mpg123"],"-R"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
command = "L "+filename+"\n"  
pid.stdin.write(command.encode())
abw
  • 189
  • 3
  • 8

2 Answers2

3

There's a couple of things I can think of.

A lightweight verification can be done if the systems are tolerant. It may also be appropriate if there is little chance of data destruction, or compromise of sensitive data. You can test to see if the string your given is an actual file by using os.path.isfile.

A more classic "secure" programming design would have you index the acceptable files that can be played and do a lookup based on user input. In this way you never actually pass on user input. It get's "filtered" by the lookup to already validated data (the accepted playable files list).

"Sanitizing" input is a black-listing type of technique. They are always less secure than a white-listing type of technique (above). If you have no choice but to "sanitize" the data you have to understand how that data passes through your system, and any other systems you depend on. You then have to craft rules to take into account any flaws or limitations within ALL of the systems. You would also have to cover classic malicious input cases like data input size, unacceptable character encoding and others.

dietbuddha
  • 7,732
  • 27
  • 33
1

Filenames doesn't need to be sanitized unless you are using a shell or executing anything. Pythons open() will not execute any commands in the filename given.

For security checks, to avoid overwriting files, you use the permission system of your OS, and make sure that the user under which the program is running only can overwrite and access files it should be able to overwrite and access.

It's generally not a good idea to let any program that takes input from the net or another process to accept absolute path names. In this case it should only be allowed to specify files under a defined music folder. I don't think the mp3 player can cause damage by giving it the wrong file, but you can crash it, at least, and that would be annoying.

Lennart Regebro
  • 147,792
  • 40
  • 207
  • 241
  • It's often the programs we don't think can cause damage that do. Granted I think in this particular case it would probably be fairly minimal if any. – dietbuddha Jan 19 '11 at 14:22
  • @dietbuddha: Sure, which is why restricting it to a specific directory is important. And not running it as root, etc, but that's another questions. :) – Lennart Regebro Jan 19 '11 at 16:39