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 On 10/20/06, Peter Elst <[EMAIL PROTECTED]> wrote: > Hi guys, > > Sorry for the dumb questions, haven't had a chance to read that > crossdomain article in detail yet. How exactly does it pose a security > risk, in my understanding any server side code can do what what Flash > does without any sandbox restrictions or am I wrong? > > I've always assumed crossdomain policy files aren't an impenetrable > fortress but does it open any additional security risks over any other > technologies? > > Thanks! > Peter > > > Geoff Stearns wrote: > > the real lesson to learn here is simple: > > > > never create a crossdomain.xml that allows any site to connect to > > yours. no asterisks! > > > > if you absolutely have to do it, put it on a separate domain that > > can't be used to access other normal site operations. > > > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
