Script security best practices in Bash Scripting - Step-by-Step Execution

Concept Flow - Script security best practices

Start Script

↓

Check User Input

↓

Validate Input

↓

Valid

↓

Sanitize

↓

Use Safe Commands

↓

Set Permissions

↓

Log Actions

↓

End Script

The script starts by checking and validating user input, sanitizes it if valid, uses safe commands, sets proper permissions, logs actions, and ends safely.

Execution Sample

Bash Scripting

#!/bin/bash
read -p "Enter filename: " file
if [[ "$file" =~ ^[a-zA-Z0-9._-]+$ ]]; then
  touch "$file"
else
  echo "Invalid filename"
fi

This script reads a filename, validates it to allow only safe characters, then creates the file if valid, else shows an error.

Execution Table

Step	Action	Input/Condition	Result	Output
1	Prompt user for filename	User inputs: test_file.txt	Input received
2	Validate filename	test_file.txt matches regex ^[a-zA-Z0-9._-]+$	Validation passed
3	Create file	touch "test_file.txt"	File created
4	End script	No errors	Script ends normally

💡 Script ends after creating file because input was valid

Variable Tracker

Variable	Start	After Input	After Validation	Final
file	""	"test_file.txt"	"test_file.txt"	"test_file.txt"

Key Moments - 3 Insights

Why do we validate the filename with a regex before using it?

Validating the filename ensures it contains only safe characters, preventing injection of harmful commands or unexpected behavior, as shown in step 2 of the execution_table.

What happens if the filename contains spaces or special characters?

The validation fails and the script prints "Invalid filename" and does not create a file, preventing unsafe operations (see step 2 and exit behavior).

Why do we quote the variable "$file" when using it with touch?

Quoting "$file" prevents word splitting and globbing, ensuring the filename is treated as a single safe string, avoiding unintended command execution (step 3).

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'file' after user input?

A "test_file.txt"

B "Invalid filename"

C ""

D "touch test_file.txt"

💡 Hint

Check the 'After Input' column in variable_tracker for 'file'

At which step does the script decide not to create a file if input is unsafe?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Validate filename' action in execution_table step 2

If the user inputs 'file; rm -rf /', what would happen according to the script flow?

A File is created with that name

B Script runs 'rm -rf /' command

C Script exits with 'Invalid filename' message

D Script crashes

💡 Hint

Refer to the validation regex and the branch for invalid input in concept_flow

Concept Snapshot

Script Security Best Practices:
- Always validate and sanitize user input
- Use safe characters only (e.g., regex validation)
- Quote variables to prevent word splitting
- Set strict file permissions
- Log important actions
- Exit safely on invalid input

Full Transcript

This visual execution shows how a bash script securely handles user input for a filename. The script prompts the user, then validates the input using a regex to allow only letters, numbers, dots, underscores, and dashes. If the input passes validation, the script safely creates the file using the quoted filename to avoid command injection. If validation fails, the script prints an error and exits without running unsafe commands. Variables are tracked step-by-step to show how the filename changes from empty to user input. Key moments highlight why validation and quoting are critical to prevent security risks. The quiz tests understanding of variable values, decision points, and the effect of unsafe input. This approach helps beginners see how to write safer bash scripts by controlling input and command usage carefully.

Practice

1. Which of the following is a key reason to use set -euo pipefail at the start of a bash script?

easy

A. It automatically logs all commands to a file for debugging.

B. It speeds up the script execution by running commands in parallel.

C. It stops the script immediately if any command fails or if an unset variable is used.

D. It disables all user inputs to prevent accidental changes.

Solution

1. Step 1: Understand what set -euo pipefail does

   This command combination makes the script exit if any command fails (-e), if an unset variable is used (-u), and if any part of a pipeline fails (pipefail).

2. Step 2: Identify the effect on script safety

   By stopping early on errors or unset variables, it prevents the script from continuing in an unexpected or unsafe state.

3. Final Answer:

   It stops the script immediately if any command fails or if an unset variable is used. -> Option C

4. Quick Check:

   Strict mode = stops on errors [OK]

Hint: Remember: strict mode stops on errors and unset variables [OK]

Common Mistakes:

• Thinking it speeds up script execution
• Assuming it logs commands automatically
• Believing it disables user input

2. Which of the following is the correct way to check if a variable user_input is set and not empty in bash?

easy

A. if [ $user_input = "" ]; then echo "Empty"; fi

B. if [ -z "$user_input" ]; then echo "Empty"; fi

C. if [ -n $user_input ]; then echo "Empty"; fi

D. if [ "$user_input" == null ]; then echo "Empty"; fi

Solution

1. Step 1: Understand the test for empty string

   The test [ -z "$user_input" ] returns true if the variable is unset or empty, which is the correct way to check emptiness safely.

2. Step 2: Check other options for correctness

   if [ "$user_input" == null ]; then echo "Empty"; fi compares to 'null' string which is incorrect. if [ -n $user_input ]; then echo "Empty"; fi lacks quotes and reverses logic. if [ $user_input = "" ]; then echo "Empty"; fi lacks quotes and can cause errors if variable is unset.

3. Final Answer:

   if [ -z "$user_input" ]; then echo "Empty"; fi -> Option B

4. Quick Check:

   Use -z with quotes to check empty safely [OK]

Hint: Use quotes and -z to check empty variables safely [OK]

Common Mistakes:

• Not quoting variables causing errors
• Comparing to 'null' string instead of empty
• Using wrong test operators

3. What will be the output of this script snippet if PATH is not set and set -u is enabled?

#!/bin/bash
set -u
echo "Path is: $PATH"

medium

A. No output, script runs silently

B. Path is:

C. Path is: /usr/bin:/bin

D. bash: PATH: unbound variable

Solution

1. Step 1: Understand set -u effect

   The set -u option causes the script to exit with an error if an unset variable is referenced.

2. Step 2: Analyze the script behavior

   Since PATH is not set, referencing $PATH triggers an unbound variable error and the script stops with a message.

3. Final Answer:

   bash: PATH: unbound variable -> Option D

4. Quick Check:

   Unset variable with set -u causes error [OK]

Hint: set -u errors on unset variables immediately [OK]

Common Mistakes:

• Assuming empty string output instead of error
• Thinking script runs silently
• Assuming default PATH value is used

4. Identify the security issue in this script snippet:

#!/bin/bash
read -p "Enter filename: " file
cat $file

medium

A. Using read without validation allows command injection.

B. No issue, script is safe as is.

C. Missing quotes around $file causes syntax error.

D. Using cat is insecure; should use less instead.

Solution

1. Step 1: Analyze input handling

   The script reads user input directly into file and uses it without validation or sanitization.

2. Step 2: Understand risk of command injection

   If the user inputs something like file.txt; rm -rf /, the shell will execute the dangerous command, causing security risk.

3. Final Answer:

   Using read without validation allows command injection. -> Option A

4. Quick Check:

   Unvalidated input risks command injection [OK]

Hint: Always validate or sanitize user input before use [OK]

Common Mistakes:

• Ignoring input validation
• Thinking missing quotes cause syntax error here
• Believing command choice alone fixes injection

5. You want to securely run a script that uses a password stored in a file. Which practice improves security best?

hard

A. Read the password from a file with restricted permissions and never echo it.

B. Store the password in plain text in the script for easy access.

C. Pass the password as a command line argument to the script.

D. Write the password to a temporary file with world-readable permissions.

Solution

1. Step 1: Evaluate password storage methods

   Storing passwords in plain text inside scripts or passing them as command line arguments exposes them to other users or logs.

2. Step 2: Choose secure handling

   Reading the password from a file with strict permissions (e.g., 600) and avoiding printing it prevents leaks and unauthorized access.

3. Final Answer:

   Read the password from a file with restricted permissions and never echo it. -> Option A

4. Quick Check:

   Restrict file permissions and avoid exposing secrets [OK]

Hint: Never expose passwords; restrict file access and avoid echoing [OK]

Common Mistakes:

• Hardcoding passwords in scripts
• Passing secrets as command line arguments
• Using world-readable temporary files