iRobots.txt SEO <= 1.1.2 - Reflected Cross-Site Scripting

Since the source code for iRobots.txt SEO version 1.1.2 is not provided, this plan is based on the vulnerability description, standard WordPress plugin architecture, and common reflected XSS patterns found in SEO-related plugins.

1. Vulnerability Summary

The iRobots.txt SEO plugin is vulnerable to Reflected Cross-Site Scripting (XSS) due to a failure to properly sanitize and escape user-supplied input before rendering it in the admin dashboard. The vulnerability typically exists in the admin settings page, where a URL parameter (such as a configuration tab, search query, or status message) is echoed directly into the HTML response. An attacker can craft a malicious URL containing a script payload; if an authenticated administrator clicks this link, the script executes in their browser context.

2. Attack Vector Analysis

• Endpoint: /wp-admin/options-general.php (Standard for SEO plugins) or /wp-admin/admin.php.
• Query Parameter: page=irobotstxt-seo (inferred slug) along with a vulnerable reflection parameter such as tab, msg, or s.
• Authentication Level: Unauthenticated to craft/send the link; requires a Logged-in Administrator to click the link (Reflected XSS).
• Vulnerable Sink: Likely an echo or printf statement inside the admin menu callback function.

3. Code Flow (Inferred)

1. The plugin registers an admin page using add_options_page() or add_menu_page() with the slug irobotstxt-seo.
2. The callback function associated with this menu (e.g., irobotstxt_seo_admin_page()) is executed when the administrator visits the settings.
3. Inside the callback, the code retrieves a value from the $_GET or $_REQUEST superglobals (e.g., $active_tab = $_GET['tab'];).
4. The code outputs this value back to the page to indicate the current state or display a message (e.g., echo "<h2>Settings for $active_tab</h2>";) without using esc_html() or esc_attr().
5. The browser interprets the injected script tags, executing the attacker's payload.

4. Nonce Acquisition Strategy

Reflected XSS in a GET parameter typically occurs before or independently of any nonce-protected actions (like saving settings). Therefore, a nonce is likely not required to trigger the reflection.

However, if the goal is to leverage the XSS to perform an administrative action (e.g., creating a new admin user), the XSS payload must dynamically extract the required nonce from the page DOM using JavaScript.

Strategy for Payload (if needed for CSRF):

1. Use browser_navigate to load the settings page.
2. The reflection should occur immediately.
3. If the payload needs to perform an action, use:
   browser_eval("document.querySelector('#_wpnonce')?.value") to identify where nonces are stored in the admin UI for future chain exploitation.

5. Exploitation Strategy

Step 1: Identify the Vulnerable Parameter
The agent should test common reflection points in the admin slug.

• Target URL: http://localhost:8080/wp-admin/options-general.php?page=irobotstxt-seo&tab=test_reflection
• Payload: </b><script>alert(1)</script>

Step 2: Execution via Playwright
The exploitation must be performed using the browser_navigate tool to simulate an administrator's session.

Request Details:

• Method: GET
• URL: http://localhost:8080/wp-admin/options-general.php?page=irobotstxt-seo&tab=%3C/b%3E%3Cscript%3Ealert(document.domain)%3C/script%3E
• Alternative URL: http://localhost:8080/wp-admin/admin.php?page=irobotstxt-seo&msg=%3Cscript%3Econfirm(1)%3C/script%3E

Step 3: Verification of Execution
The agent will check if the script is present in the rendered HTML and if the browser's dialog handling (if triggered) confirms execution.

6. Test Data Setup

1. Install Plugin: Ensure irobotstxt-seo version 1.1.2 is installed and activated.
2. User Creation: Create a standard administrator user (e.g., admin/password).
3. Session: Use browser_navigate to log in as the administrator first to establish the authenticated session.

7. Expected Results

• The HTTP response should contain the raw, unescaped payload: </b><script>alert(document.domain)</script>.
• When viewed in a browser, a JavaScript alert box should trigger, or the script should be visible in the DOM as an executable block rather than encoded text (e.g., NOT <script>).

8. Verification Steps

After attempting the injection:

1. Check Page Source: Search for the string alert(document.domain) in the response body.
2. Verify Non-Escaping: Confirm that < and > characters are not converted to < and >.
3. DOM Inspection: Use browser_eval to check if a specific element injected by the payload exists:

   browser_eval("document.body.innerHTML.includes('alert(document.domain)')")
   

9. Alternative Approaches

If the tab parameter is not vulnerable:

1. Test s parameter: ?page=irobotstxt-seo&s=<script>alert(1)</script> (common in plugins with search/filter logs).
2. Test error or message parameters: Some plugins reflect an error string in a notice: ?page=irobotstxt-seo&error=<img src=x onerror=alert(1)>.
3. Check for POST-based Reflection: Attempt to submit a settings form with a payload in a text field that is echoed back in a "Value saved: [payload]" message. This would require an http_request with a valid nonce (which can be found using browser_navigate + browser_eval).