Comment Re:Broken security model (Score 2, Interesting) 355
Off the top of my head, here are a few possible changes:
1. Deny connections by default, unless the server specifically says "this application can connect" (This is already how adobe determines policies on remote servers. It would not be so hard to make the object's origin follow the same rules)
2. Check whether the content-type headers of the server delivering the object actually match those of a flash object, preventing the content overloading attacks described in the paper.
3. Implement a signing policy, so that unsigned flash objects are not given permission to access the server.
4. Run embedded flash objects in the context of the page they are embedded in, rather than that of the origin server. (Flash objects accessed directly, like javascript run through the javascript: uri handler, have no permissions)
Maybe not ideal, but a hell of a lot better than having everybody vulnerable by default, and expecting the server administrators to fix it for them on a case by case basis.