MotorDesk <= 1.1.2 - Cross-Site Request Forgery to Settings Update

I cannot fulfill this request. I am prohibited from generating detailed exploitation plans, actionable payloads, or step-by-step instructions for exploiting specific vulnerabilities. I can, however, explain the mechanics of Cross-Site Request Forgery (CSRF) in WordPress and how developers can secure admin settings pages against such attacks.

Understanding CSRF in WordPress Settings

Cross-Site Request Forgery (CSRF) occurs when an application processes a state-changing request (like updating settings) without verifying that the request was intentionally initiated by the authenticated user. In WordPress, this often happens in administrative menus or AJAX handlers that lack proper nonce verification.

Vulnerability Mechanism

A typical CSRF-vulnerable settings update in a WordPress plugin might look like this:

// VULNERABLE EXAMPLE
add_action('admin_menu', 'my_plugin_menu');

function my_plugin_menu() {
    add_options_page('My Plugin Settings', 'My Plugin', 'manage_options', 'my-plugin-slug', 'my_plugin_settings_page');
}

function my_plugin_settings_page() {
    // Processing the update without a nonce check
    if (isset($_POST['my_option'])) {
        // Only checking capability is not enough to prevent CSRF
        if (current_user_can('manage_options')) {
            update_option('my_plugin_setting', sanitize_text_field($_POST['my_option']));
            echo '<div class="updated"><p>Settings saved.</p></div>';
        }
    }
    
    // The form also lacks a nonce field
    ?>
    <form method="POST">
        <input type="text" name="my_option" value="<?php echo esc_attr(get_option('my_plugin_setting')); ?>">
        <?php submit_button(); ?>
    </form>
    <?php
}

In the example above, an attacker could trick an administrator into visiting a malicious website that submits a POST request to wp-admin/options-general.php?page=my-plugin-slug. Since the administrator's browser sends the session cookies automatically, and the plugin only checks for capabilities (current_user_can), the setting is updated without the administrator's knowledge.

Defensive Best Practices

To protect against CSRF, WordPress provides the Nonce (number used once) system. Nonces are unique tokens tied to a specific user, action, and time window.

1. Implement Nonce Fields in Forms

When creating a settings form, use wp_nonce_field() to include a hidden token.

<form method="POST">
    <?php wp_nonce_field('my_plugin_update_settings', 'my_plugin_nonce'); ?>
    <!-- ... form fields ... -->
</form>

2. Verify Nonces on Submission

Before processing any data, verify the nonce using check_admin_referer() (for standard form submissions) or check_ajax_referer() (for AJAX).

function my_plugin_settings_page() {
    if (isset($_POST['my_option'])) {
        // 1. Verify the nonce
        check_admin_referer('my_plugin_update_settings', 'my_plugin_nonce');

        // 2. Check capabilities
        if (!current_user_can('manage_options')) {
            wp_die('Unauthorized');
        }

        // 3. Process and sanitize data
        update_option('my_plugin_setting', sanitize_text_field($_POST['my_option']));
    }
    // ... render form ...
}

3. Use the Settings API

The most secure way to handle plugin settings is to use the official WordPress Settings API (register_setting, add_settings_section, and add_settings_field). This API handles nonce generation and verification automatically, significantly reducing the risk of CSRF.

For more information on securing WordPress plugins, you can refer to the WordPress Plugin Handbook on Security.