Re: [tor-bugs] #27427 [Applications/Tor Browser]: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#27427: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages
-------------------------------------------------+-------------------------
 Reporter:  rustybird                            |          Owner:
                                                 |  arthuredelstein
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Very High                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  TorBrowserTeam201809R,               |  Actual Points:
  tbb-8.0.1-can                                  |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by ma1):

 Replying to [comment:17 cypherpunks3]:
 > Replying to [comment:15 ma1]:
 > > It should not: NoScript defers all the HTTP(S) traffic until its
 policy is configured and ready to be enforced.
 > Ok, so let's say it only breaks in harmless cases. Regardless, it still
 looks like a bug to me: the handler for `fetchChildPolicy` is running
 before making sure the state is properly initialised; for example, the
 object `ns.policy` is used and dereferenced in `getForDocument` even
 though it could still be null. Or maybe I'm wrong, I'm just reading this
 code now.
 >

 I think you're wrong, indeed. The message handler gets enabled only after
 initialization is completed.

 > > about:blank, data: and file: URLs are those which might suffer of this
 problem, because NoScript has no means to prevent them from loading before
 it's initialized.
 > Does that mean that the approach mentioned there
 [ticket:27553#comment:3] is unreliable because of this race?

 That approach is reliable, except on the very first load of a local
 (bypassing webRequest) page. I.e. if you set a file:, data: or about: URL
 as your home page (or, regrettably, if you're using session restore and
 that's the last active tab) NoScript won't be able to affect it on first
 load.

 A work-around would be detecting some in the static content scripts (which
 appear to run anyway) that the dynamic content scripts didn't (i.e.
 NoScript's background script has not been initialized yet), stopping the
 load and triggering a (delayed?) reload. Maybe this could be helped by
 waiting for a response to a dummy HTTP fetch() request, relying on the web
 traffic deferral, in order to prevent reload loops in case something
 fails.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27427#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs