CODEWITHSUNDEEP
asp.netpythonsecurity
Peter Smith
Peter Smith

Reputation: 889

Should I wrap launching a python process in another executable?

So I have a 3rd party application which exposes a Python API. I have a python script that does what I need it to do with that 3rd party application.

The python script only uses command line arguments, no user input and writes to stdout.

I'm wiring this up to be launched at runtime from an ASP.NET website. Since python is so powerful, I'm wondering if it would make sense from a security standpoint to create a new executable that launches the python process with a hard coded or locally read (App.Config) script path and copy its command line arguments to the python process.

This new executable would be launched from the .NET application as a way to prevent attackers from uploading and launching arbitrary python code? Does this negate any attack vectors or is it just extra complexity?

Also, I can't use IronPython, as the 3rd party extensions are written for CPython only.

Idea of the code:

Process p = new Process();
p.StartInfo.FileName = "python.exe";
p.StartInfo.Arguments = "goodscript.py \"" + argument1.Replace("\"","\\\"") + "\" \"" +
  argument2.Replace("\"","\\\"") + "\"";
p.Start();

I'm worried that either a command line switch like -i could be injected or that somehow the file path to goodscript.py could be changed to point to another script. I guess if the later is possible then really the file path to python.exe could be changed to another executable file path.

Upvotes: 0

Views: 193

Answers (3)

Ben
Ben

Reputation: 71545

Your Python script is going to be invoked by the website. If someone can use the website to cause the Python script to be invoked with different arguments, or to execute a different script, or whatever, then that's the security hole. It has nothing to do with "Python being so powerful", this would be a security issue for calling out to any language

How exactly do you think this would be affected by wrapping the Python script with something else and invoking that instead? Either someone can cause a different executable to be invoked, or to be invoked with different arguments or on different data, in which case you're screwed no matter what language you're calling. Or they can't, in which case you're fine no matter what language you're calling.

Upvotes: 1

Lie Ryan
Lie Ryan

Reputation: 64913

As it currently stands, your script is not just an added complexity, but is actually opening up a security hole. Namely, that you're passing the arguments a single string that have to be parsed instead of as pre-tokenized list of strings.

Upvotes: 0

the paul
the paul

Reputation: 9161

The sample code definitely has security concerns. I'm not sure how Process.StartInfo works there; if it splits up the arguments before executing the subprocess or if it uses some shell to do it for you, but either way, there's at least room for an attacker to put backslashes in the argument strings and trick your double-quote-escaping.

If you have some other method to convey arguments individually, instead of trying to pack them into a string and let something else parse them apart, that would be much preferable.

Upvotes: 2

Related Questions