#5477: Surprising DOM origins before HTTPS-E/NoScript redirects have completed
-------------------------------------+--------------------------------------
Reporter: Drugoy | Owner: ma1
Type: defect | Status: reopened
Priority: blocker | Milestone:
Component: EFF-HTTPS Everywhere | Version:
Resolution: | Keywords:
Parent: | Points:
Actualpoints: |
-------------------------------------+--------------------------------------
Comment(by mikeperry):
Replying to [comment:40 pde]:
> 3. Use the HSTS machinery. Advantages: will probably work.
Disadvantages: will require a Firefox patch (!!!) to expose those
mechanisms to JavaScript; the HSTS paths have probably never been tested
with cross-domain rewrites.
Turns out it was actually pretty straightforward to adapt the HSTS
machinery into a general URL rewriting XPCOM API. I created this API in my
Tor Browser-patched Firefox 13 source and tested using it with a patched
HTTPS-Everywhere to use the API, and it worked. It also blocks the url
spoofing exploit by way of the url bar always remaining as
http://ww2.cs.mu.oz.au/~pde/bugs/5477-tst.html (ie steps 2 and 3 of my
description above now never happen).
Will attach both patches. The Firefox patch will need review from some
Mozilla people as well as some more extensive testing, as there are a few
questions I have:
1. Should this API be its own interface instead of getting added to
nsIHTTPChannel?
2. Do I need to do anything special wrt refcounting the nsIURI?
3. Are there any weird edgecases like webfonts, favicons, spdy, post
requests, etc etc?
4. What about other channel types? Should we keep the NoScript machinery
for them?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5477#comment:41>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online