Browser Security

    Ideas for Information Flow

  • Create a DOM access language with composable semantics similar to CSS
  • Proxy DOM and other environment access from the JavaScript VM
  • Inject security tags on input to the VM, inspect the tags on output.

  • add an optional policy=”…url…” to the <script> tag
  • What about injected scripts?
  • The empty script <script policy=”…”></script> means apply that policy to all remaining scripts on the page?

  • 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).

    Questions and Concerns

  • 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”

Leave a Reply

You must be logged in to post a comment.