Script security best practices in Bash Scripting - Cheat Sheet & Quick Revision

Recall & Review

beginner

Why should you avoid running scripts as the root user unless absolutely necessary?

Running scripts as root can cause serious damage if the script has errors or is malicious. It can change or delete important system files. Always use the least privilege needed to reduce risk.

beginner

What is the purpose of using 'set -e' at the start of a bash script?

'set -e' makes the script stop immediately if any command fails. This helps prevent the script from continuing in a broken state, which can cause security or data problems.

intermediate

How can you protect sensitive data like passwords in your scripts?

Avoid hardcoding passwords in scripts. Use environment variables, encrypted files, or secure vaults. Also, restrict script file permissions so only trusted users can read them.

intermediate

Why should you validate all user inputs in scripts?

Validating inputs prevents injection attacks and unexpected behavior. It ensures the script only processes safe and expected data, reducing security risks.

advanced

What is the risk of using 'eval' in bash scripts, and how can you avoid it?

'eval' executes strings as commands, which can be dangerous if the string contains malicious code. Avoid using 'eval' or sanitize inputs carefully before using it.

What does 'chmod 700 script.sh' do to the script file?

A Allows everyone to read and execute the script

B Allows only the owner to read, write, and execute the script

C Makes the script read-only for everyone

D Removes all permissions from the script

'chmod 700' sets permissions so only the file owner can read, write, and execute the script. This protects the script from unauthorized access.

Which of these is a good practice to avoid exposing passwords in scripts?

A Store passwords in environment variables

B Hardcode passwords directly in the script

C Print passwords to the console

D Share passwords in comments

Storing passwords in environment variables keeps them out of the script code and reduces the risk of accidental exposure.

What is the main reason to validate user input in scripts?

A To increase script size

B To make the script run faster

C To prevent injection attacks and errors

D To allow any input without restrictions

Validating input helps prevent malicious data from causing harm or unexpected behavior in the script.

What does the 'set -u' option do in a bash script?

A Disables error checking

B Ignores unset variables

C Prints all commands before executing

D Treats unset variables as an error and exits

'set -u' helps catch errors by stopping the script if it tries to use a variable that has not been set.

Why is it risky to use 'eval' with user input in bash scripts?

A It can execute malicious commands

B It makes the script shorter

C It slows down the script

D It prevents errors

'eval' runs the input as code, so if the input is malicious, it can harm the system or leak data.

Explain three best practices to keep bash scripts secure.

Think about permissions, input safety, and secrets.

Describe why 'set -e' and 'set -u' are useful in secure bash scripting.

Consider how these options help prevent unexpected script behavior.

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