Thanks guys, that's a very interesting read. It certainly makes you think about best practices using crossdomain policy files.
Cheers, Peter Bob Ippolito wrote: > Cross-site request forgery (CSRF) exploits cookie-based sessions (most > sessions are Cookie based). Flash's HTTP communication does not > exclude cookies, so if you can talk to a site then you can exploit the > site. Many of these exploits are possible without Flash, but Flash > defeats all mechanical strategies for CSRF protection because it has > the capability to read the HTML page (e.g. to get the value of a > one-use token in a HTML form). > > For example, if gmail had a crossdomain.xml that allowed "*", then I > would be able to put out a Flash trojan horse that can read other > people's mail and send it to me. Or delete mail arbitrarily. Or send > spam from legitimate gmail accounts. > > While you may think that it'd be possible to proactively block > unauthorized Flash communication by inspecting the HTTP headers, you'd > be wrong because Flash allows you to inject headers :) > > -bob _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
