Advanced Custom CSS <= 1.1.0 - Reflected Cross-Site Scripting

This research plan focuses on analyzing and exploiting a Reflected Cross-Site Scripting (XSS) vulnerability in the Advanced Custom CSS plugin (<= 1.1.0).

1. Vulnerability Summary

The Advanced Custom CSS plugin is vulnerable to Reflected XSS due to the lack of proper sanitization and escaping on user-supplied input reflected in the admin dashboard or public-facing pages. An attacker can craft a malicious URL containing a JavaScript payload that, when clicked by a logged-in administrator, executes in the context of their session. This can lead to session hijacking, unauthorized configuration changes, or the creation of new administrative users.

2. Attack Vector Analysis

• Endpoint: Likely an administrative settings page (e.g., wp-admin/themes.php?page=advanced-custom-css) or a dedicated plugin menu page.
• Vulnerable Parameter: Likely a query parameter used for UI state, such as tab, message, error, or id (inferred).
• Authentication: Unauthenticated (Attacker), but requires a logged-in user (Victim) with high privileges to click the link for maximum impact.
• Preconditions: The plugin must be active.

3. Code Flow (Inferred)

1. Entry Point: The user accesses a plugin-related URL in the WordPress admin dashboard.
2. Hook Registration: The plugin registers an admin page via add_action('admin_menu', ...) or add_theme_page(...).
3. Data Acquisition: Inside the callback function for the menu page (e.g., accss_settings_page), the code retrieves a value directly from the $_GET or $_REQUEST superglobal.
4. Vulnerable Sink: The retrieved value is echoed back to the page HTML without passing through WordPress escaping functions like esc_html() or esc_attr().

Example of a likely vulnerable pattern in advanced-custom-css.php:

function accss_settings_page() {
    $current_tab = isset($_GET['tab']) ? $_GET['tab'] : 'general'; // Inferred
    echo '<div class="wrap"><h1>Settings - ' . $current_tab . '</h1>'; // XSS SINK
    // ...
}

4. Nonce Acquisition Strategy

Reflected XSS typically occurs during the rendering phase of a page rather than during a state-changing action (like saving settings). Therefore, a nonce is often not required to trigger the reflection.

However, if the reflection occurs inside a specific AJAX handler or a form submission that validates a nonce, follow these steps:

1. Identify Shortcode/Page: Determine if the plugin enqueues scripts on a specific page. Search for add_shortcode in the plugin files.
2. Setup Test Page:

   wp post create --post_type=page --post_title="XSS Test" --post_status=publish --post_content='[advanced_custom_css_shortcode]' # Inferred shortcode name
   

3. Extract Nonce: Use browser_navigate to go to the created page and use browser_eval to extract the nonce from the localized script variable.
   • Search grep: grep -r "wp_localize_script" .
   • JS Extraction: browser_eval("window.accss_params?.nonce") (inferred variable name).

5. Exploitation Strategy

The goal is to demonstrate reflection in the browser.

1. Identify Reflected Parameters:
   Search for echoing of GET parameters in the plugin directory:

   grep -rP "echo.*\$_GET" .
   

2. Construct Payload:
   If the parameter tab is found to be echoed:
   • Payload: </h1--><script>alert(document.domain)</script>
3. Execute Request:
   Use the http_request tool to simulate the victim clicking the link. Since this is reflected XSS, we need to observe the response body.
   • URL: http://localhost:8080/wp-admin/themes.php?page=advanced-custom-css&tab=%3Cscript%3Ealert(1)%3C/script%3E (inferred slug).
   • Method: GET
   • Note: You must provide valid admin cookies in the http_request to access the admin page.

6. Test Data Setup

1. Install & Activate: Ensure the plugin advanced-custom-css version 1.1.0 is installed and active.
2. Admin User: Ensure an admin user exists (default admin / password).
3. Plugin Config: Navigate to the plugin settings page once to ensure default options are initialized.

7. Expected Results

• The HTTP response body should contain the raw payload: <script>alert(1)</script>.
• The payload should not be escaped (e.g., should not appear as <script>).
• If viewed in a browser, a JavaScript alert box would appear.

8. Verification Steps

1. Manual Body Check: Use http_request and check if the string <script>alert(1)</script> exists in the output.
2. Check for Escaping: Verify that esc_html or esc_attr is missing in the source code at the line identified in step 5.1.

   # Check the specific line in the file
   cat advanced-custom-css.php | grep -C 5 "echo.*\$_GET\['tab'\]" # Inferred
   

9. Alternative Approaches

If the simple GET reflection fails:

• Attribute Injection: If the input is reflected inside an HTML attribute (e.g., <input value="USER_INPUT">), use: " onmouseover="alert(1)" type="text" autofocus=".
• AJAX Reflection: Check wp_ajax_ handlers. If an AJAX action returns an error message containing the action or other parameters:

  # Test AJAX reflection
  http_request "http://localhost:8080/wp-admin/admin-ajax.php?action=accss_save&data=<img src=x onerror=alert(1)>" # Inferred
  

• Settings Notice: Sometimes XSS is reflected in the "Settings Saved" notice. Try submitting a form with a malicious settings-updated or message parameter.