Gareth Heyes discovered that comparing the screenTop property before and after triggering a potential XSS could reveal whether the IE XSS filter had activated and shown its yellow InfoBar. When the InfoBar appeared, the browser’s client area shifted down by a few pixels, changing screenTop. I extended this technique to IE9 by noting that the old-style InfoBar reappeared when HTML content was rendered inside a non-native container such as a XAML frame.

The attack flow was:

  1. Record screenTop from any IFrame (accessible cross-origin).
  2. Trigger the potential XSS.
  3. Record screenTop again.
  4. If the value changed, the InfoBar appeared, meaning the filter fired.
// Accessible from any IFrame, regardless of origin
var before = window[0].screenTop;
// ... trigger XSS attempt ...
var after = window[0].screenTop;
if (after !== before) {
    // XSS filter activated
}

This let an attacker know whether their payload had been blocked before the user saw anything, and adjust accordingly. The XAML-frame angle was specific to IE9 where the standard InfoBar had been removed, but its equivalent appeared inside plugin-hosted HTML content.

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.