When using Shell.Execute [ http://documentation.xojo.com/index.php/Shell.Execute ] I see we can pass the command separately from the parameters:
Shell.Execute(Command as String [,Parameters as String])
Does passing the Parameters separately prevent command injections? I have a command where the users enter parameters and I’m worried someone could try something…
I would think that (depending on the command line you are building)
that YES, an input could be designed that would be dangerous
Perhaps if you know that certain parameters must be certain conditions (numbers, path to existing files) you could check them first… but if it is free for all text input… I’d be wary at best
Yes, very dangerous.
Imagine the parameter:
"foobar; echo rm -rf /"I put the echo in there in case anyone tries this out to see if it works. Without the echo, if you aren’t handling quoting of parameters just right, the user will have just erased the hard drive.
For two apps that I have, I build a dictionary of acceptable arguments and argument sizes to prevent “dumb” options. For the others, any command that the app needs to execute in pre-constructed using pick lists and checkbox options without the user manually adding anything.
But, be aware that your app is no worse than if the user started a terminal and entered the same dumb commands. There is only so much that we can do to prevent misuse by users determined to mess things up.
But that would result in a “permission denied” message if the user tried to execute it from a normal shell or terminal. And if the user already has the ability to raise the app’s execution level to root, there’s nothing that we can do to stop them, anyway.
[quote=381260:@Hal Gumbert]Shell.Execute(Command as String [,Parameters as String])
Does passing the Parameters separately prevent command injections? I have a command where the users enter parameters and I’m worried someone could try something…[/quote]
Just to be clear if it isn’t already… No, using the Execute command with the Parameters argument does not cleanse input or prevent additional commands from being concatenated onto the parameters.
Sure, but you can mentally substitute “rm -rf ~/Documents” then - the point remains that it’s quite dangerous.
It also may not be the user’s fault, it could be the programmer’s fault - quoting shell paths is tricky. See for example this one https://www.wired.com/2001/11/glitch-in-itunes-deletes-drives/
That specific case is more related to the use of shell variables instead of real values and isn’t truly an “escaped shell path” issue. Additionally, I can’t come up with a scenario where the “claimed” glitch could do more than cause a “file not found” or a “is a directly” error, so I suspect that “anonymous user” is not providing correct info. While your example of the rm of the user’s Documents folder is more of a concern, it plays back into the same situation as the user doing that from a Terminal.
We have a scenario in BRU PE where a user can specify to the UI to overwrite a tape. Upon starting the job, we show the user what prior data will be irrevocably lost and make them choose to append or overwrite. If they choose Overwrite, we warning them again. It is unbelievable how many people manually select the Overwrite option both times and then get mad at us when the tape is actually overwritten.
There is a point in any user interaction where we can only protect the user so much if they are determined to do the wrong thing.
There was a another similar bug that apple made, I think it was in the 10.6.x updater but my google-fu is not working. It’s a real issue. The problem with quoting paths is difficult, as all sort of characters have special meaning in shells, including ", ', ~, | , <, >, &, && and others…