Preventing Command and Argument Injection

Bash is a powerful glue language — it passes text directly to the kernel, other programs, and sub-shells. That power becomes a liability the moment untrusted input reaches a command without validation or quoting.

Two root causes drive nearly every Bash injection:

• Word splitting: Unquoted variables are split on whitespace (IFS), turning one logical value into many shell tokens.
• Glob expansion: Characters like *, ?, and [ are expanded by the shell before the command even runs.

An attacker who controls a filename, username, URL parameter, or environment variable can exploit both to run arbitrary commands, read files, or escalate privileges.

This lesson shows exactly how these vulnerabilities appear and — more importantly — how to eliminate them with correct quoting, input validation, and array-based argument passing.

When Bash sees an unquoted variable, it splits its value on any character listed in $IFS (default: space, tab, newline). What looks like one argument becomes many.

Run the script below and observe how a filename with a space becomes two separate arguments to rm.

The simplest and most effective defense against word splitting is to always double-quote variable expansions.

• "$var" — expands to exactly one token, preserving spaces, tabs, and newlines.
• 'literal' — single quotes: no expansions at all, useful for fixed strings.
• Never use $var unquoted unless you explicitly need word splitting and glob expansion.

The script below shows the safe version of the previous example.

Unquoted variables are also subject to pathname expansion (globbing). If user-controlled input contains * or ?, Bash expands it against the filesystem before the command runs.

A classic attack vector: a web form that sets PATTERN=* and the script runs cp $PATTERN /tmp/leak/ — copying every file in the current directory.

The fix is identical: double-quote the variable. A quoted "$PATTERN" is passed literally; the shell never performs glob expansion on it.

Scripts that accept arguments from the caller are prime injection targets. Each positional parameter ($1, $2, ...) must be quoted wherever it is used.

A particularly dangerous pattern is passing $@ or $* unquoted to another command:

• "$@" — expands each positional parameter as a separate, individually quoted word. Always use this form.
• $@ or $* unquoted — subject to word splitting and globbing.
• "$*" — joins all parameters into one word (rarely what you want).

eval re-parses its argument as shell code. Any untrusted data reaching eval can execute arbitrary commands.

Common dangerous patterns:

• eval "$user_input"
• eval echo \$$var (indirect variable lookup)
• Passing user data through bash -c "$input"

Rule: never pass untrusted input to eval or bash -c. Use safe Bash alternatives:

• Indirect expansion: ${!varname} instead of eval echo \$$varname
• Associative arrays for dynamic key-value lookup
• Functions instead of generated command strings

Rejecting known-bad characters (a denylist) is fragile — attackers find encodings or characters you forgot. Instead, allowlist: accept only characters you know are safe.

Allowlist strategies in Bash:

• Regex match: [[ "$input" =~ ^[A-Za-z0-9_-]+$ ]]
• Pattern match: case "$input" in [A-Za-z0-9]*) ... ;; esac
• Enum check: compare against a fixed set of valid values

Validate at the boundary — as soon as input enters the script — before it touches any command.

When you need to build a command dynamically — conditionally adding flags, looping over inputs — use a Bash array instead of concatenating strings.

String concatenation collapses all structure; a Bash array preserves each argument as a discrete element with no shell re-parsing.

• Declare: args=()
• Append: args+=(--flag "$value")
• Execute: command "${args[@]}"

"${args[@]}" expands every element as a separate, individually quoted word — exactly like "$@".

Even a correctly quoted argument can be misinterpreted as an option flag if it begins with -. Consider rm "$file" where file='-rf .': the quoting protects word splitting, but rm still interprets -rf as flags.

The POSIX convention -- signals end of options to most GNU/BSD utilities. Everything after -- is treated as a positional argument, never as a flag.

When Bash scripts invoke database CLIs (psql, mysql), curl with user-supplied URLs, or similar tools, two additional layers apply:

• Parameterised queries: Never interpolate user data into SQL strings. Pass values via -v in psql or --data-urlencode in curl.
• Separate data from code: Use printf with a literal format string; never let user input be the format string.

The example below queries PostgreSQL safely, keeping the user-supplied value completely out of the SQL text.

A production-grade secure Bash script combines every technique from this lesson into a consistent, layered defence. Here is a minimal but complete hardened template:

• set -euo pipefail — exit on error, treat unset variables as errors, propagate pipe failures.
• Validate at entry — allowlist every external input before it touches any command.
• Quote everything — "$var", "$@", "${array[@]}" — no exceptions unless you need splitting.
• Use arrays for dynamic command construction.
• Prefix arguments with -- when passing user-supplied filenames or strings.
• Never use eval with untrusted data; prefer ${!var} for indirect lookup.
• Restrict permissions — run scripts with the minimum required privileges; avoid sudo inside scripts that accept user input.

Test your understanding of the key concepts in this lesson.

You have covered the complete defensive toolkit for safe Bash input handling:

• Word splitting and glob expansion are the root mechanisms that turn unsafe variables into injection vectors.
• Double-quote every variable ("$var", "$@", "${arr[@]}") to suppress both threats.
• Use "$@" — never $@ or $* unquoted — when forwarding arguments.
• Prefix user-supplied filenames with -- to prevent flag injection.
• Allowlist all external input with a regex guard ([[ $v =~ ^pattern$ ]]) before it reaches any command.
• Build dynamic commands with arrays (cmd+=() → "${cmd[@]}"), never string concatenation.
• Eliminate eval and bash -c "$input"; use ${!varname} for safe indirect expansion.
• Always open scripts with set -euo pipefail and IFS=$'\n\t' for a hardened baseline.

These practices, applied consistently from the first line of every script, reduce the attack surface of Bash to near zero for injection-class vulnerabilities.