Create a tiny XSS to run a second payload contained inside the URL. This second payload will exfiltrate the flag and bypass the CSP using a DNS exfiltration with WebRTC.
Using htmlspecialchars within the srcdoc attribute doesn’t prevent against HTML Injection/XSS. The code example below demonstrates that HTML entity codes are effectively interpreted inside the iframe. For more details, refer to attr-iframe-srcdoc.
We know how to execute an XSS, our next challenge is to bypass the 30 characters or less filter. To perform an XSS within this limit, we can use the URL to locate a part of our payload.
When you’re within an iframe, you can’t employ the location attribute to access the top-level location and you can’t use the top.location attribute because it exceeds the character limit. However, you can leverage the baseURI property of the Node (in this case, the svg). This property provides the absolute base URL of the document housing the node.
Iframe’s sandbox & COOP
Futhermore, you cannot access the top window context because of the sandbox iframe’s attribute. Also, you cannot access the opener attribute from other origin because the Cross-Origin-Opener-Policy header is set to same-origin (cross-origin documents are not loaded in the same browsing context).
As we cannot directly evalute the baseURI property, we can create a string that will contain the URL, close this string and initiate our second payload. This means the second payload resides both within the URL and outside the xss parameter, allowing us to bypass the character limit.
Now that we can execute an XSS without dealing with the character size resitriction, our final step is to find a CSP bypass to extract the flag. For this purpose, we can use a DNS exfiltration via WebRTC.