- Same-Origin Policy Part 1: Why we’re stuck with things like XSS and XSRF/CSRF
- Same-Origin Policy Part 2: Server-Provided Policies?
- Browser Security Gets Even More Confusing (Cross-site Request Draft)
- W3C Access Control for Cross-Site Requests
- EcmaScript Security Proposal
A few links about Browser and Web security
- Create a DOM access language with composable semantics similar to CSS
- Proxy DOM and other environment access from the JavaScript VM
- add an optional policy=”…url…” to the <script> tag
- What about injected scripts?
- Make sure the policy language composes (cascading inheritance) to more restriction, never less, so that injected scripts cannot gain capabilities
- Try Meyers distribute information flow tags (more general than data tainting).
Ideas for Information Flow
Inject security tags on input to the VM, inspect the tags on output.
The empty script <script policy=”…”></script> means apply that policy to all remaining scripts on the page?
- Not sure what Meyer’s Iflow solves vs taint. It’s more powerful, but why would this be necessary? Need an example problem to demonstrate the difference.
- For the attack vectors at google caja vulnerabilities page, solutions other than Iflow would suffice
- What are the principals in a HTML page? is each script its own principal, what about each domain? or url?
- Will we need to extend HTMl for supporting the policy language? Is this feasible?
- Need to list all the security attacks that we are defending against: XSS, CSRF (confused deputy), man in middle, ….
- data tainting problems
- global object poisoning
- scripts replacing other scripts with bad scripts
- change submit log in forms
- Need to test solutions
- Establish proxy before re-routing to shopping site, “man in the middle”