Are shell scripts / bash inherently less secure than other (script) languages such as python?

Question

Are shell scripts / bash suitable for any kind of task as long as the developer(s) write correct, security bug free scripts?

Or are shell scripts / bash less advisable for some tasks such as parsing untrusted data over networks?

Are shell scripts / bash inherently less secure than other (script) languages such as python?

This question is being asked from perspective of someone who writes shell / bash scripts, that could also write those in other languages if necessary.

Answer 1

Short version:

1. Shell scripts require more caution with untrusted input; there are inherent dangers.
2. Shell scripts are not general purpose languages, and are probably unsuited for "parsing untrusted data over networks"
3. All that said, shell scripts can do amazing amounts of things, and can do it securely with enough care. Should is a different matter, and left to the coder to determine...

Long version:

See the "Injection Attacks" section of this Shell Scripting Primer. Because data is often passed via variables and to command lines, and because command lines do globbing and parsing in ways which were designed to be powerful but trusted the user, extra care needs to be taken in shell scripts (as opposed to general-purpose languages which more carefully separate variables from process execution).

Consider this script:

#!/bin/bash
echo -n "String: "
read BADE
echo $BADE

And watch me run it:

$ ./foo.sh
String: hello
hello
$ ./foo.sh
String: -n hello
hello$

Notice that in the second execution of foo.sh, the "-n" that I entered as part of the user input string is treated as a command line argument by the echo command. As a result, there's no newline between "hello" and the "$" prompt, as there was in the first execution of foo.sh.

While it's possible to sanitize user input, doing so in bash means using tools which may be vulnerable to this sort of manipulation (consider 'echo $INPUT | tr -d ...'). In general, the fact that bash is not a general purpose language means that doing anything usually requires other programs to be invoked, and you can't think about the security of bash alone, but also the security of all the programs it's calling.

In bash, those subprogram calling interfaces are parsed rather than programatically defined. In most general-purpose programming languages, there's a clearer distinction between data and code. Strings passed to functions are passed as a string, not as a series of tokens which are parsed for potential function variables before being treated as data. So, yes, bash is "less advisable for some tasks such as parsing untrusted data over networks".

"Inherently less secure" is not a phrase that I think should be used. Every programming language on the face of the earth has strong points and weak points. If I'm programming in C, I need to be very careful about memory allocation and boundaries, because the language isn't. In Bash, memory allocation and boundaries are handled for me, but I need to worry about data and command channels being easily mingled. And this interview with Guido van Rossum shows how with Python the interpreter has been subject to vetting for security issues and when asked "when 'enough is enough' in terms of hardening the interpreter" responded "That's not really how we approach it. We realize that security is an ongoing effort..."

This sort of question is always difficult because it's subjective. If you're a bash expert, should you write in Python, which you might not know? Or will your knowledge of how bash works help you avoid the pitfalls? And your answer is going to be different than his, than hers, than anybody else reading this. There's people out there that have written amazing network servers in bash, no doubt; it's possible, so never say it can't be done.

The objective truth is: know your languages, and know their strengths and weaknesses, and choose the right one for the job. And try to continually learn how to do so securely because "security is an ongoing effort."