Frontend Post Submission Manager Lite <= 1.2.7 - Unauthenticated Open Redirect via 'requested_page' Parameter

This research plan outlines the steps required to demonstrate an unauthenticated Open Redirect vulnerability in the Frontend Post Submission Manager Lite plugin.

1. Vulnerability Summary

The Frontend Post Submission Manager Lite plugin (versions <= 1.2.7) is vulnerable to an unauthenticated Open Redirect. The vulnerability exists within the verify_username_password function, which processes login or verification requests from the frontend. The function utilizes a POST parameter named requested_page to redirect users after processing, but it fails to validate that the URL is local to the WordPress installation using wp_validate_redirect() or wp_safe_redirect(). This allows an attacker to craft a request that redirects a victim to an external, potentially malicious domain.

2. Attack Vector Analysis

• Endpoint: The plugin likely hooks verify_username_password to a common initialization hook like init or wp_loaded to intercept POST requests.
• Vulnerable Parameter: requested_page (POST).
• Authentication: None required (Unauthenticated).
• Trigger: A POST request containing the parameter that triggers the login/verification logic. This is typically associated with a frontend login form provided by the plugin.

3. Code Flow (Inferred)

1. Entry Point: The plugin registers a hook: add_action('init', '...verify_username_password') or similar in the main plugin file or an includes file.
2. Processing: The function verify_username_password() is executed on every page load.
3. Condition: It checks if specific POST parameters are set (e.g., a "login" button name or a specific action).
4. Vulnerable Sink:

   if ( isset( $_POST['requested_page'] ) ) {
       $redirect_url = $_POST['requested_page'];
       wp_redirect( $redirect_url ); // Redirects without validation
       exit;
   }
   

5. Result: The browser receives a 302 Found header with the Location set to the attacker-supplied external URL.

4. Nonce Acquisition Strategy

Login forms and frontend submission forms often use nonces for CSRF protection.

• Shortcode Identification: The plugin likely uses a shortcode to render the login form, such as [fpsm_login_form] (inferred).
• Strategy:
  1. Search the plugin code for add_shortcode to find the login/submission form shortcode.
  2. Create a public page with this shortcode: wp post create --post_type=page --post_status=publish --post_content='[SHORTCODE_NAME]'.
  3. Navigate to the page.
  4. Extract the nonce and any other required hidden fields (like fpsm_login_nonce) using browser_eval.
  5. JS Check: Look for wp_localize_script calls in the plugin source to see if a nonce is stored in a global JS object (e.g., window.fpsm_vars?.nonce).

5. Exploitation Strategy

The goal is to trigger the verify_username_password function and provide an external URL in the requested_page parameter.

Request Details:

• Method: POST
• URL: http://localhost:8080/ (The root URL is usually sufficient if the function is hooked to init)
• Headers: Content-Type: application/x-www-form-urlencoded
• Body Parameters:
  • requested_page: https://vulnerable.com (Target of the redirect)
  • fpsm_login_submit: 1 (Inferred: A parameter to trigger the login logic)
  • nonce_field_name: [NONCE_VALUE] (If discovered in step 4)

Example Payload:

POST / HTTP/1.1
Host: localhost:8080
Content-Type: application/x-www-form-urlencoded

fpsm_login_submit=1&requested_page=https://vulnerable.com&fpsm_login_nonce=abcdef1234

6. Test Data Setup

1. Install Plugin: Ensure Frontend Post Submission Manager Lite <= 1.2.7 is installed and active.
2. Create Form Page:
   • Search plugin files for add_shortcode.
   • Run: wp post create --post_type=page --post_title="Login" --post_status=publish --post_content='[fpsm_login_form]' (Replace with actual shortcode).
3. Identify Trigger: Look at the HTML source of the created page to find the name attribute of the submit button and the requested_page hidden input (if it exists).

7. Expected Results

• The server should respond with an HTTP 302 Found status code.
• The Location header in the response must match the value provided in the requested_page parameter (e.g., Location: https://vulnerable.com).
• The redirection should occur regardless of whether the "login" credentials (if any) are valid, provided the redirection logic is reached.

8. Verification Steps

1. Analyze HTTP Response: Use the http_request tool and inspect the headers property of the response object.
   • Check response.status === 302.
   • Check response.headers['location'] === 'https://vulnerable.com'.
2. Manual Browser Check: Use browser_navigate to the crafted URL and verify the browser actually lands on the external site.

9. Alternative Approaches

• Path Traversal/Absolute Path: If the plugin prepends the site URL, try bypasses like //vulnerable.com or https://vulnerable.com.
• Different Hooks: If init doesn't work, check if the plugin uses a specific admin-post.php action or an AJAX action (wp_ajax_nopriv_...).
• Empty Password/User: Some login handlers only redirect if the input is processed. Try providing a dummy username/password to reach the part of the code that handles requested_page.
• Query String: Check if the parameter is also accepted via GET: http://localhost:8080/?requested_page=https://vulnerable.com.