Re: [discovery-api] Mitigating real-world device compromise

Hi Rich,

Thanks for developing further your ideas about opacifying URLs obtained
via NSD. While I like the idea, I have some concerns about how reliably
it can be implemented.

Le jeudi 24 octobre 2013 à 12:05 +1100, Rich Tibbett a écrit :
> However, to initial a simple GET request to
> a particular URL as detailed in this particular exploit, a web page
> could simply [load it as an image]
> 
Are there any protection against this type of attacks where the attacker
would include this kind of URL in any regular Web page, using for the
host name part of the URL well-known local network IP addresses for the
router?

Most routers come pre-configured with a default range of IP addresses
for the local network, including a default IP address for themselves;
and some ISP provide a modem-router that is available as a well-known
local DNS name.
> 
> Developers cannot call anything above '/myService' in the www
> hierarchy and developers cannot infer paths to any other potential
> services on the same device from the provided url.

That requires that any given service is fully made available through a
single directory hierarchy — both in the sense that no other service
should be available under that hierarchy, and that all the resources
needed by the said service should be available under that hierarchy; I
feel this is pushing the bar of what is required from local service
providers quite a bit further than just "add CORS".

> A full solution should would obfuscate both the initial service
> endpoint url and monitor service messaging itself with a view to
> obfuscating in-messaging urls via XHR.

I'm not sure how this could be done practically, though; there are so
many possible variations on how the URL or part of it could be leaked;
imagining a JSON data file being sent:
{ url: "http://10.0.2.1:5000/"}
vs
{ host: "10.0.2.1", port: "5000"}
vs
{ host: "10.0.2.1" }
vs
{ relurl: "//10.0.2.1" }

Not to mention that the service could know about local-network-only DNS
names and expose them for one reason or another. And all of this could
of course also be inserted in non textual formats.

It feels to me that the only option to screen URLs, short of having the
browser itself takes care of all the messaging, would be to have it be
responsible for obtaining all the URL end points, i.e. the developer
would only be able to act on URL end points obtained via API calls; I'm
not sure if this is in practice different from having the browser do
everything.

But it may be that we need to approach that problem at another level: it
certainly feels like the attack we want to protect against is already
readily available without NSD (include an image from well-known local
addresses); NSD may just make it more precise.

Maybe this is something we should bring to the WebAppSec WG to get their
input?

Dom

> [1] http://shadow-file.blogspot.com.au/2013/10/complete-persistent-compromise-of.html
> 
> [2] http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0129.html
> 
>

Received on Thursday, 24 October 2013 07:33:26 UTC