{"id":1444,"date":"2026-09-06T16:38:56","date_gmt":"2026-09-06T16:38:56","guid":{"rendered":"https:\/\/www.securesteps.tn\/?p=1444"},"modified":"2026-09-06T16:38:56","modified_gmt":"2026-09-06T16:38:56","slug":"perchance-nns-ctf-walkthrough","status":"publish","type":"post","link":"https:\/\/www.securesteps.tn\/ar\/perchance-nns-ctf-walkthrough\/","title":{"rendered":"perchance \u2014 Browser Extension Origin and Context Confusion | NNS CTF"},"content":{"rendered":"

perchance \u2014 Browser Extension Origin and Context Confusion<\/h1>\n

Platform:<\/strong> NNS CTF 2026
Category:<\/strong> Web \/ Browser Extension<\/p>\n

1. Components<\/h2>\n

The challenge combines a bot, a browser extension, an attacker-controlled page, and the trusted Rust documentation origin. The goal is to make code execute in the Rust documentation origin, where a non-HttpOnly flag cookie is available.<\/p>\n

The exploit is not one isolated bug. It is a chain of trust failures: weak URL validation, an unvalidated cross-origin message, an attacker-observable imported function, and unsafe HTML insertion.<\/p>\n

2. Weak URL validation<\/h2>\n

The options page accepts a URL only if it contains https:\/\/doc.rust-lang.org\/<\/code>. This is a substring check, not an origin check. A URL using userinfo can satisfy the check while loading an attacker host, for example:<\/p>\n

https:\/\/anything@ATTACKER\/?https:\/\/doc.rust-lang.org\/<\/code><\/pre>\n
The browser interprets ATTACKER<\/code> as the real host; the Rust string appears only in the userinfo\/query portion. The code then stores u.origin<\/code> as activateOn<\/code>, allowing the attacker origin to become the extension’s activation origin.<\/p>\n
3. Cross-origin postMessage bug<\/h2>\n
The options script listens for messages and calls updateConfig<\/code> whenever the data begins with http<\/code>. It never checks event.origin<\/code> or that event.source<\/code> is the expected window:<\/p>\n
window.addEventListener('message', function (e) {\n  if (e.data.match(\/^https?\/)) updateConfig(e.data);\n});<\/code><\/pre>\n
An attacker page can frame the options page and post the crafted URL. This bypasses the need for a manual user entry and sets the extension configuration from an untrusted origin.<\/p>\n
4. Replacing the sanitizer function<\/h2>\n
On an activated page, the content script creates a random name and injects a module import into the page context:<\/p>\n
const nonce = 'a' + crypto.randomUUID().replaceAll('-', '');\nscr.textContent = `import ${nonce} from 'http:\/\/localhost:3000\/jsxss.js';\nwindow['${nonce}']=${nonce}`;<\/code><\/pre>\n
The script waits until window.wrappedJSObject[nonce]<\/code> exists and then calls it on the current URL. The random name is not secret from page observers: a MutationObserver can watch newly inserted script elements, extract the nonce, and define the corresponding global before the import completes. The attacker-controlled replacement returns HTML instead of sanitized text.<\/p>\n
5. Reaching the trusted origin<\/h2>\n
The content script stores the return value as previous<\/code>. On the final visit it creates a paragraph and assigns:<\/p>\n
elm.innerHTML = `Previous: ${prev}`;<\/code><\/pre>\n
Because the stored value can contain markup, an image payload such as an onerror<\/code> handler executes when inserted. The final navigation is to https:\/\/doc.rust-lang.org\/stable\/std\/<\/code>, so the payload runs where the flag cookie is readable and sends it to the attacker-controlled endpoint.<\/p>\n
6. Exploit sequence<\/h2>\n
    \n
  1. Frame the extension options page.<\/li>\n
  2. Send an attacker URL containing the required Rust substring to set activateOn<\/code>.<\/li>\n
  3. Reload the attacker page so the content script executes.<\/li>\n
  4. Observe the imported script, recover its random global name, and replace the sanitizer function.<\/li>\n
  5. Return an HTML payload that exfiltrates document.cookie<\/code>.<\/li>\n
  6. Reset the activation origin to Rust documentation.<\/li>\n
  7. Navigate to the Rust standard-library page and read the exfiltrated cookie.<\/li>\n<\/ol>\n
    7. Verified result<\/h2>\n
    The bot requested an \/exfil<\/code> URL containing the URL-encoded flag cookie. Decoding that value produced:<\/p>\n
    flag=NNS{p3RH4ps_y0u_M16h7_P0551b1Y_3Nj0Y_c7Fs_P3RCH4nc3}<\/code><\/pre>\n
    8. Defensive lessons<\/h2>\n
      \n
    • Compare parsed URL origins, not substrings.<\/li>\n
    • Validate both event.origin<\/code> and event.source<\/code> for postMessage.<\/li>\n
    • Do not expose security-sensitive functions through page globals.<\/li>\n
    • Keep extension data isolated from page scripts.<\/li>\n
    • Use text insertion or a trusted sanitizer instead of innerHTML<\/code>.<\/li>\n
    • Mark sensitive cookies HttpOnly and Secure where possible.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
      Detailed NNS CTF browser-extension walkthrough covering URL validation, postMessage origin confusion, sanitizer replacement, trusted-origin execution, and defenses.<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1444","post","type-post","status-publish","format-standard","hentry","category-webapplicationsecurity"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t