Script security best practices in Bash Scripting - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of a script with safe variable usage

What is the output of this bash script when run?

#!/bin/bash
user_input="; rm -rf /"
echo "Hello, $user_input!"

Bash Scripting

#!/bin/bash
user_input="; rm -rf /"
echo "Hello, $user_input!"

A Hello, ; rm -rf /!

B Hello, !

C Syntax error

D Command executed: rm -rf /

💡 Hint

Look at how the variable is used inside double quotes.

The variable is inside double quotes, so the shell treats it as a string, not a command. The output prints the exact string including the dangerous characters.

💻 Command Output

intermediate

Effect of unquoted variables in bash scripts

What happens when this script runs?

#!/bin/bash
user_input="file.txt; rm -rf /"
cat $user_input

Bash Scripting

#!/bin/bash
user_input="file.txt; rm -rf /"
cat $user_input

A Script exits silently with no output

B Syntax error due to unquoted variable

C Only contents of file.txt printed safely

D Contents of file.txt printed, then system tries to run rm -rf / command

💡 Hint

Think about how the shell interprets unquoted variables with special characters.

Without quotes, the shell splits the variable by spaces and treats ';' as command separator, so it runs 'cat file.txt' then 'rm -rf /'. This is dangerous.

📝 Syntax

advanced

Identify the secure way to read user input in bash

Which option securely reads user input into a variable without allowing command injection?

A read user_input; echo $user_input

B read user_input; eval "$user_input"

C read user_input; echo "$user_input"

D read user_input; bash -c "$user_input"

💡 Hint

Avoid running user input as code.

Option C safely reads input and prints it as a string. Option C and D execute user input as code, which is unsafe. Option C prints unquoted input, risking word splitting.

🔧 Debug

advanced

Debugging a script vulnerable to command injection

This script is vulnerable to command injection. Which option fixes it?

#!/bin/bash
filename=$1
cat $filename

Bash Scripting

#!/bin/bash
filename=$1
cat $filename

A cat "$filename"

B cat $filename | grep -v rm

C cat ${filename}

D cat `echo $filename`

💡 Hint

Quoting variables prevents word splitting and command injection.

Option A quotes the variable, preventing injection. Option A is same as unquoted. Option A pipes output but doesn't prevent injection. Option A uses backticks, which executes the content.

🚀 Application

expert

Secure script to safely handle filenames with spaces and special chars

You want to write a bash script that lists details of files given as arguments. Which script correctly handles filenames with spaces and special characters safely?

A

#!/bin/bash
for file in $*; do
  ls -l "$file"
done

B

#!/bin/bash
for file in "$@"; do
  ls -l "$file"
done

C

#!/bin/bash
for file in "$*"; do
  ls -l "$file"
done

D

#!/bin/bash
for file in $@; do
  ls -l $file
done

💡 Hint

Check how the script iterates over arguments and quotes variables.

Option B uses "$@" which treats each argument separately and quotes variables to handle spaces safely. Options B, C, and D either do not quote properly or iterate incorrectly, causing word splitting or errors.