SQL injection prevention in Wordpress - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding SQL Injection Risks in WordPress

Which of the following best describes why using raw SQL queries with user input in WordPress is risky?

A Because user input can contain malicious SQL code that changes the query behavior.

B Because WordPress does not support SQL queries at all.

C Because SQL queries are always slow and cause performance issues.

D Because user input is automatically encrypted by WordPress.

💡 Hint

Think about what happens if a user types something unexpected into a search box.

Raw SQL queries with user input can be manipulated to run harmful commands if the input is not handled safely. This is called SQL injection.

❓ component_behavior

intermediate

Behavior of $wpdb->prepare() in WordPress

What does the $wpdb->prepare() function do when used with user input in WordPress?

A It removes all user input from the query.

B It executes the SQL query immediately without any changes.

C It encrypts the user input before adding it to the query.

D It safely escapes user input to prevent SQL injection by preparing the query with placeholders.

💡 Hint

Think about how placeholders work in SQL queries.

The $wpdb->prepare() function replaces placeholders with safely escaped user input, preventing attackers from injecting harmful SQL.

📝 Syntax

advanced

Correct Usage of $wpdb->prepare()

Which of the following code snippets correctly uses $wpdb->prepare() to safely query posts by title?

A $wpdb->prepare("SELECT * FROM wp_posts WHERE post_title = ?", $title);

B $wpdb->prepare("SELECT * FROM wp_posts WHERE post_title = '$title'");

C $wpdb->prepare("SELECT * FROM wp_posts WHERE post_title = %s", $title);

D $wpdb->prepare("SELECT * FROM wp_posts WHERE post_title = %d", $title);

💡 Hint

Remember the placeholder types: %s for strings, %d for numbers.

Option C correctly uses %s as a placeholder for a string and passes the variable separately. Option C is unsafe because it injects the variable directly. Option C uses an invalid placeholder '?'. Option C uses %d which is for integers, not strings.

🔧 Debug

advanced

Identifying SQL Injection Vulnerability

Given the following WordPress code, what is the main security issue?

$title = $_GET['title'];
$query = "SELECT * FROM wp_posts WHERE post_title = '$title'";
$results = $wpdb->get_results($query);

Wordpress

$title = $_GET['title'];
$query = "SELECT * FROM wp_posts WHERE post_title = '$title'";
$results = $wpdb->get_results($query);

A The code uses $wpdb->get_results() which is deprecated.

B The code directly inserts user input into the SQL query without escaping, allowing SQL injection.

C The variable $title is not defined before use.

D The query uses double quotes which causes a syntax error.

💡 Hint

Look at how the variable $title is used inside the query string.

Directly inserting user input into SQL queries without escaping or preparing allows attackers to inject malicious SQL code.

❓ state_output

expert

Output of a Prepared Query with Malicious Input

What will be the output of the following WordPress code if the user inputs "anything' OR '1'='1" as $title?

$title = "anything' OR '1'='1";
$query = $wpdb->prepare("SELECT * FROM wp_posts WHERE post_title = %s", $title);
echo $query;

Wordpress

$title = "anything' OR '1'='1";
$query = $wpdb->prepare("SELECT * FROM wp_posts WHERE post_title = %s", $title);
echo $query;

A SELECT * FROM wp_posts WHERE post_title = 'anything\' OR \'1\'=\'1'

B SELECT * FROM wp_posts WHERE post_title = 'anything' OR '1'='1'

C SyntaxError due to unescaped quotes

D SELECT * FROM wp_posts WHERE post_title = %s

💡 Hint

Think about how $wpdb->prepare() escapes quotes inside strings.

The $wpdb->prepare() function escapes single quotes inside the input by adding backslashes, so the malicious input is treated as a string literal, not SQL code.