SensitiveTagCloud <= 1.4.1 - Cross-Site Request Forgery

This research plan outlines the steps required to identify and verify the Cross-Site Request Forgery (CSRF) vulnerability in the SensitiveTagCloud plugin (version <= 1.4.1).

1. Vulnerability Summary

The SensitiveTagCloud plugin fails to implement or incorrectly validates WordPress nonces (CSRF tokens) during administrative actions, most likely when saving plugin settings or updating "sensitive" tag lists. This allows an attacker to perform unauthorized state-changing operations by inducing a logged-in administrator to interact with a malicious webpage or link.

2. Attack Vector Analysis

• Target Endpoint: Likely wp-admin/options-general.php?page=sensitive-tag-cloud or wp-admin/admin-post.php.
• Vulnerable Action: Saving configuration options (e.g., font sizes, tag exclusions, or "sensitive" tag identifiers).
• Authentication Level: Requires the victim to be a logged-in Administrator.
• Preconditions: The plugin must be active. The attacker must know the parameter names used in the settings form.

3. Code Flow (Inferred)

Since source files are not provided, the research agent must trace the following path:

1. Entry Point: Look for add_options_page() or add_menu_page() in the main plugin file to identify the settings page slug.
2. Hook Registration: Identify how the plugin handles form submissions. Check for add_action( 'admin_init', ... ) or add_action( 'admin_post_...', ... ).
3. Form Handler: Locate the function responsible for processing $_POST data.
4. The Sink: Search for update_option() or $wpdb->query() within that handler.
5. The Vulnerability: Observe the absence of check_admin_referer() or wp_verify_nonce() before the state-changing logic occurs.

4. Nonce Acquisition Strategy

The vulnerability is described as missing or incorrect nonce validation.

• If missing: No nonce is required for the exploit.
• If incorrect: The plugin might be using a generic nonce or a hardcoded string that does not change per user session.

To verify the existence of a nonce requirement:

1. Create a test page with the plugin's primary shortcode (if applicable) to see if scripts are enqueued:
   wp post create --post_type=page --post_status=publish --post_content='[sensitive-tag-cloud]'
2. Navigate to the plugin settings page: /wp-admin/options-general.php?page=sensitive-tag-cloud.
3. Use browser_eval to check for localized nonce variables:
   browser_eval("window.stc_vars?.nonce || window.sensitive_tag_cloud_data?.security") (inferred names).
4. Examine the HTML source for hidden inputs:
   browser_eval("document.querySelector('input[name=\"_wpnonce\"]')?.value").

5. Exploitation Strategy

The goal is to change a plugin setting (e.g., hiding all tags) without a valid nonce.

Step 1: Discover Parameters
Navigate to the settings page and extract form fields:
browser_eval("Array.from(document.querySelectorAll('form input, form select')).map(i => i.name)")

Step 2: Execute CSRF via HTTP Request
Using the http_request tool, simulate the admin's form submission but omit the nonce or provide an invalid one.

• URL: http://localhost:8080/wp-admin/options.php (if using Settings API) OR http://localhost:8080/wp-admin/admin-post.php.
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body (Example Payload):
  action=stc_save_settings&stc_font_size=99px&stc_sensitive_tags=important,private&submit=Save+Changes (inferred parameters)

6. Test Data Setup

1. Install Plugin: Ensure sensitive-tag-cloud version 1.4.1 is installed and active.
2. Admin User: Ensure an administrator account exists (default admin / password).
3. Initial State: Record current plugin settings using WP-CLI:
   wp option get stc_settings (inferred option name).

7. Expected Results

• Success: The HTTP response should be a redirect (302) back to the settings page, and the plugin configuration should be updated in the database despite the lack of a valid _wpnonce.
• Failure: The response is a 403 Forbidden or a WordPress "Are you sure you want to do this?" (failure to validate) page.

8. Verification Steps

After sending the http_request, verify the change via WP-CLI:

# Check if the specific option was modified
wp option get stc_settings
# If the output matches the 'attacker_value' sent in the POST body, CSRF is confirmed.

9. Alternative Approaches

• GET-based CSRF: Check if the handler accepts $_REQUEST instead of strictly $_POST. If so, test if the setting can be changed via a simple img tag or link:
  /wp-admin/admin-post.php?action=stc_delete_tags&id=1
• Bypass via Default Action: If wp_verify_nonce($nonce, -1) is used, try obtaining a nonce for the default action from any other part of the WordPress dashboard and reuse it here.