Bugforge Vaultly-010

first of all ,we check the sandbox feature:

Explanation of the sandboxing flow :

1- the content HTML+JS is stored in apps.vaultly-sandbox.dev

2- deliver the content's URL to an HQ reviewer

3- the HTML+JS is able to make a cross-site request to api.vaultly.app

Further enumeration of the API:

• every API endpoint is accessible except : '/api/hq/recovery' which returns 403 Forbidden

Next : We analyze the endpoint:

• the origin is reflected in the ACAO header instead of validating it against an allow list which means SOP is relaxed and cross-site requests are possible.
• ACAC header is set to true meaning the response can be read by JS

The Attack Cycle:

• from what we mentioned earlier , we need the cookie's sameSite attribute to be set to none so the cookie can get attached on a cross-site request (because they are two completely different domains)

• from our script : a fetch to the unauthorized endpoint with cookies attached (credentials:'include')
• the resulted response is sent to our server

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

• cookie must be : sameSite=None so the browser can attach it cross-site
• ✔ ACAO header is reflecting the origin (SOP is relaxed)
• ✔ ACAC header is set to true , meaning JS can read the response
• ✔ No CSP header that restricts connection to our exfil server
• Now Deliver it to the HQ reviewer and check your exfil server

Diagram for the full flow :

We've achieved our goal