Home

Awesome

postMessage-tracker

Made by Frans Rosén. Presented during the "Attacking modern web technologies"-talk (Slides) at OWASP AppSec Europe back in 2018, but finally released in May 2020.

<img src="https://github.com/fransr/postMessage-tracker/raw/docs-images/images/listener-uber.png" width="500" />

This Chrome extension monitors postMessage-listeners by showing you an indicator about the amount of listeners in the current window.

It supports tracking listeners in all subframes of the window. It also keeps track of short-lived listeners and listeners enabled upon interactions. You can also log the listener functions and locations to look them through them at a later stage by using the Log URL-option in the extension. This enables you to find hidden listeners that are only enabled for a short time inside an iframe.

It also shows you the interaction between windows inside the console and will specify the windows using a path you can use yourself to replay the message:

<img src="https://github.com/fransr/postMessage-tracker/raw/docs-images/images/console.png" width="350" />

It also supports tracking communication happening between different windows, using diffwin as sender or receiver in the console.

Features

Using New Relic:

<img src="https://github.com/fransr/postMessage-tracker/raw/docs-images/images/before.png" width="200" />

After, with postMessage-tracker:

<img src="https://github.com/fransr/postMessage-tracker/raw/docs-images/images/after.png" width="200" />

Using jQuery:

<img src="https://github.com/fransr/postMessage-tracker/raw/docs-images/images/before-jquery.png" width="200" />

After, with postMessage-tracker:

<img src="https://github.com/fransr/postMessage-tracker/raw/docs-images/images/after-jquery.png" width="200" /> <img src="https://github.com/fransr/postMessage-tracker/raw/docs-images/images/options.png" width="300" /> <img src="https://github.com/fransr/postMessage-tracker/raw/docs-images/images/anonymous.png" width="300" />

Known issues

Since some websites could be served as XML with a XHTML-namespace, it will also attach itself to plain XML-files and will be rendered in the top of the XML. This might confuse you if you look at XML-files in the browser, as the complete injected script is in the DOM of the XML. I haven't found a way to hide it from real XML-files, but still support it for XHTML-namespaces. The content script is not added to the DOM if the document.contentType is application/xml which happens when Chrome renders XML-files.