| name | flash-crossdomain-legacy |
| description | Historical and residual assessment of Adobe Flash crossdomain.xml and Microsoft Silverlight clientaccesspolicy.xml: over-permissive allow-access-from wildcards, socket policies, domain attributes, and leftover player surfaces. Use when legacy Flash/Silverlight assets, cross-domain policy files, or remove-or-restrict hardening of dead plugin trust roots is in scope. |
Flash / Silverlight Cross-Domain Policy (Legacy)
When To Use
- Targets still serve
/crossdomain.xml, path-scoped Flash policies, or /clientaccesspolicy.xml.
- Inventories mention
.swf, Flash Player, AIR, Silverlight XAP, or old media/game hosts.
- Hardening asks whether residual plugin-era trust (
*, secure="false", open sockets) should be removed or restricted.
- Historical review, CTF/legacy app, or residual surface on authorized hosts.
- Not primary for modern browser CORS — use
cors-cross-origin-misconfiguration. Not primary for window.postMessage — use postmessage-security. Combine when legacy policies sit beside modern CORS on the same origin.
Scope And Authorization
- Authorized targets, labs, CTFs, owned apps, and in-scope production only.
- Treat as legacy residual risk: mainstream browsers dropped Flash/Silverlight; impact often needs outdated clients, kiosks, specialized players, or non-browser runtimes that still honor policy files.
- Prefer passive policy fetch and static SWF/XAP inventory. Do not deploy malicious SWF against real users.
- Lab clients or documented historical models only under engagement rules. Redact secrets; keep originals immutable.
Workflow
1. Inventory policy and plugin surfaces
-
Fetch common locations (HTTP/HTTPS, apex and relevant subdomains):
| Path | Runtime |
|---|
/crossdomain.xml | Flash / some socket clients |
/clientaccesspolicy.xml | Silverlight |
| Path-relative policies near SWF/content | Flash (site- or directory-scoped) |
| Socket policy on TCP 843 (if in scope) | Flash XML/socket policy |
-
Search HTML, JS, and CDN manifests for .swf, Shockwave MIME types, .xap, swfobject, Ruffle shims, or old players.
-
Note CDN vs origin: policies on the data host (bucket, media domain) matter as much as the app origin.
-
Record status, Content-Type, cache headers, and host/path differences.
2. Parse crossdomain.xml risk factors
Illustrative high-risk shape:
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
| Element / attribute | High risk when… |
|---|
allow-access-from domain="*" | Any Flash origin may load data from this host |
secure="false" on HTTPS hosts | HTTP SWF may access HTTPS data |
Broad to-ports / socket ranges | Cross-domain sockets to many ports |
permitted-cross-domain-policies="all" | Nested/meta policies widely allowed |
headers="*" | Custom header abuse via plugin stack |
| Over-broad subdomain wildcards | *.example.com trusts every subdomain |
Also flag: upload buckets with private objects, conflicting multi-path policies, and loose XML accepted by old parsers.
3. Parse clientaccesspolicy.xml (Silverlight)
Treat as over-permissive when Silverlight grants look like:
domain uri="*" (or equivalent open allow-from)http-request-headers="*"resource path="/" with include-subpaths="true"
Same residual-client caveats as Flash. Document exact allow-from / grant-to trees.
4. Contextual impact (do not overclaim)
- No Flash/Silverlight consumer observed → often informational residual / trust-debt unless program scores leftover policies strictly.
- Internal thin clients, kiosks, game launchers, AIR/desktop apps, or custom players still loading SWF raise real residual impact.
- Wildcard
* on public static assets → lower; on authenticated APIs, private media, admin hosts, or socket-to-sensitive ports → higher if a consumer exists.
- Historical model: malicious SWF + ambient cookies on a victim plugin. Verify actual consumer before claiming live exploitability.
5. Remove-or-restrict checklist
Prefer remove when no legitimate plugin client remains:
- Delete
crossdomain.xml and clientaccesspolicy.xml from all origins/CDNs/path variants.
- Remove unused
.swf/.xap delivery, embeds, and socket policy listeners (e.g. port 843).
- Purge CDN/cache; block re-publish via IaC, static templates, and default framework files.
If a rare authorized client must stay:
- Exact partner domains only — no
domain="*" / uri="*".
- Prefer
secure="true" on HTTPS data hosts; document any secure="false".
- Least-privilege paths/ports/headers; avoid site-wide
/ + include-subpaths when possible.
- Strictest workable
site-control; monitor new buckets/subdomains for accidental open policies.
6. Verification
- Re-fetch policies → 404 or tight allowlists only.
- Spot-check sibling hosts and historical CDN URLs.
- Grep deploy artifacts for residual policy XML and SWF references.
- Track modern CORS separately — fixing CORS does not remove plugin policies and vice versa.
Routing
| Need | Skill |
|---|
Modern Access-Control-* / credentialed browser reads | cors-cross-origin-misconfiguration |
| Cross-window JS messaging | postmessage-security |
| Framing / UI redress (not policy XML) | clickjacking |
| Cookie flags on residual web sessions | cookie-security-flags |
| Host/API discovery for legacy files | api-recon-and-docs |
| Secure config change implementation | code-quality-standards |
Output Checklist
Rules
- English findings only; label historical vs currently exploitable clearly.
- Wildcard
* alone is not always critical on dead plugin stacks — require consumer context or program residual criteria.
- Do not claim Flash/Silverlight runs in modern browsers without a player or alternate runtime.
- Prefer removal of unused policies over complex allowlists.
- Authorized testing only; no malicious SWF distribution to third parties.
