Doug Turner wrote:
> Sounds like you are confirming what I found -- there is no easy way to
> go from DNS resolution in the socket transport to the "responsible"
> document that caused the load.
Right.
> Basically, what it looks like is that, DNS resolution makes a callback
> to the Socket Transport (onLookupComplete). At this point, we can
> determine if the dns recorded contained any private IPs. If it does, we
> want to walk back up to the "responsible" document and see where that it
> was also loaded from a private ip.
Correct. The problem is determining the "responsible" document.
> It looks like the socket transport can talk to the http connection which
> may know something about the http channel which seams to know that there
> is a doc shell set as the interface requestor.
Yes, but this docshell is the one in which the load is happening. It may not
be
the same as the one that started the load, and worse yet the docshell that
started the load may no longer contain the document responsible for starting
the
load.
If we assume that a public-IP document can never get hold of a private-IP
document, these issues are somewhat mitigated, perhaps. But that's a big
assumption...
> I suppose we can add an
> interface to the docshell keep track of how context is loaded, but this
> feels extremely brittle.
Yeah.
For what it's worth, if I were designing this system today I would design it as
follows:
1) Require a principal argument to newURI, so that for each URI it's clear
where it originated. Not sure how to handle mutations to URIs offhand,
but this is a start. Another option is to pass the principal to
newChannel, but the problem is that there are various places that call
newChannel that don't really know where the load is coming from; the image
loader comes to mind. Oh, and the image loader coalesces loads across
documents, which makes it a real mess in all this.
2) Have the loading principal available in networking code (it's hanging off
the channel's URI, basically). Possibly copy the principal at channel
creation time, or use the current URI, depending on exact setup and
desired behavior.
3) Perform a callback after DNS resolution to see whether the load is
allowed. This is similar to how redirects work now. All IP-based
protocols would have to do this.
The problem is that I'm not quite sure that adding the necko APIs for this
(because the existing ones are frozen), transitioning all our code to the new
APIs and evangelizing extensions to do so as well are really 1.9-scope stuff.
:(
On the other hand, are we worried about all access to private IPs, or just form
posts? Doing something more limited with the latter (in particular hanging an
nsIPrincipal off their nsIInterfaceRequestor) might not be that invasive...
-Boris
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
