[RTW] Criteria for what one can do in Javascript vs what one has to do inside the browser

[Ted Hardie]

Hi Harald,

Some comments below.

On Thu, Feb 17, 2011 at 9:05 AM, Harald Alvestrand <harald at alvestrand.no> wrote:
> Trying to sort out thoughts in my own head.... I've run a few experiments,
> and thought a few thoughts.
>
> There are a couple of things that should NOT be permitted from Javascript in
> an RTC-Web enabled application, and there are a couple of things that just
> can't be done at the present stage of our codebase.
>
> Things that should not be permitted:
>
> - Sending an UDP packet with script-specified content to a script-specified
> destination. This has far too much potential for havoc (imagine them being
> fired at business critical systems, DNS servers or SNMP monitoring ports).
>
> - Setting up a TCP connection to a script-specified destination and sending
> script-specified data down it. Same issues as above.
>
> The traditional defense against the second type is the "same origin policy",
> policed by browsers in their implementation of XmlHttpGet, WebSockets and
> similar interfaces, which also limits requests to more-or-less valid HTTP
> (but see http://www.alvestrand.no/ietf/http-traps.html for some fun abuses
> that used to work...)

I'd like to understand a bit better what you see as the line between
"in Javascript"
and "in the Browser".  To take an example, if the javascript contains
a dns URI with a
pointer to a specific authoritative server (RFC 4501 gives the form as:
 dns:[//authority/]domain[?CLASS=class;TYPE=type] ),
it is handing the crafting of the actual DNS packet to the OS
subsystem that does
that work.   Is this a UDP packet with script-specified content to a
script-specified
destination, or does the OS subsystem's involvement mean that it is
not script-specified
content?

A script could theoretically do the same thing with snmp URIs, for example, but
the DNS one is a bit more compelling, because we know the browser must handle
DNS resolution at some level.  If same-origin means it will never
honor an authority
section in a DNS uri, then the only thing a script could do would be
to request resolution
of a huge number of a  records to DoS the local resolver.

I'm also curious about the extent to which document.domain style hacks would be
okay for folks contemplating this work.  If a web server providing
rendezvous can point to
other hosts within its domain as "same origin", some scaling will get
easier because
it will be able to hand off some tasks.

I also wonder whether shifting from same origin to pawn ticket
uri-style authorization
might not be better for this problem space, but I haven't baked an
actual method yet.
That would obviously not work in the current Javascript environment,
but it might
be possible to extend things to include a document.pawnticket in future.

regards,

Ted

>
> So far, we have assumed that the STUN handshake is our defense against the
> first one, and that it's OK to send out a moderate amount of STUN-formatted
> UDP packets to ports and IP addresses chosen by the script, believing that
> the STUN format prevents them from being parsed as valid packets by other
> protocols.
>
> (Query: What other operations need to be protected against?)
>
> Things that can't be done:
>
> - Anything that requires timing of events within 20-100 ms of each other
> - Anything that depends on multithreading behaviour in the browser
>
> In both cases, Javascript just doesn't work that way.
>
> I think the TCP constraint + the UDP constraint means that we can't
> implement SIP or XMPP in Javascript without a gateway that talks
> SIP-over-HTTP - you just can't get around the security features.
>
> I think the timing constraint means that if you implement ICE in Javascript,
> you're going to need to have seriously relaxed timing constraints - the
> standard specifies that you should try candidates at <complicated expression
> that usually turns out to be 20 ms>.
>
> What else are serious limitations on what we can or cannot do?
>
> What are the consequences?
>
>                         Harald
>
>
>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>