Automatically finding XSS inside Flash files
Flash content was, for a long period, a meaningful source of cross-site scripting on otherwise well-secured sites, because a single vulnerable SWF file hosted on a trusted domain could be made to execute arbitrary JavaScript in that domain's security context.
Static versus dynamic testing
Two approaches existed for finding this class of bug. Static analysis tools scan a decompiled SWF's ActionScript for patterns that call out to JavaScript, which is fast and scales across large numbers of files, but tends to flag many cases that are not actually exploitable, requiring manual review of every result. Manual decompilation and code review is far more accurate, but does not scale to auditing hundreds of SWF files across a site.
A dynamic middle ground
An alternative is to test behaviourally rather than by reading code: load the real Flash plugin inside a scriptable, headless browser, pass a URL parameter containing a probe value, and watch whether the plugin's JavaScript bridge actually fires. A probe that triggers an alert confirms the file genuinely executes attacker-influenced JavaScript. A probe designed to break out of its expected context and instead produces a script error in the browser's console is also a useful signal, since it shows the input reached a point where it was being interpreted as code rather than as plain data.
This approach can be automated: a crawler collects every SWF file reachable from a site, and each one is driven through the headless browser with a small set of probe parameters, flagging any file that shows either behaviour for manual confirmation.
Limitations
Dynamic testing like this only exercises the specific parameters and input shapes tried; a SWF with no reachable automated trigger, or one that filters the exact probe values used, will not be flagged even if it has a real flaw reachable by other means. It is best used as a triage step ahead of manual review, not a replacement for it.
Why it matters
Even with Flash now long retired from modern browsers, the underlying lesson is current: dynamic, behaviour-based testing against a real rendering engine catches classes of injection that static source analysis tends to either miss or over-flag, and automating it is a practical way to triage a large number of files before committing to manual review.
Key takeaways
- Legacy Flash content hosted on a trusted domain could execute attacker-controlled JavaScript in that domain's security context
- Static analysis of decompiled code scales well but produces many false positives that need manual confirmation
- Loading real plugin content in a scriptable headless browser and watching for triggered JavaScript or script errors is a practical dynamic test
- Automating this probe-and-watch approach across a crawled set of files turns manual auditing into a triage step
- Dynamic testing only catches what the chosen probes actually trigger; it complements manual review rather than replacing it
This note has been rewritten and checked for this edition; it is not a copy of the original post.