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

[Harald Alvestrand]

On 02/17/2011 08:17 PM, Ted Hardie wrote:
> 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?
In this case, we're guaranteed that what comes out is a DNS packet, and 
it is (presumably, I don't remember if the dns URL allows server 
specification) sent towards a destination that the OS/browser thinks is 
a DNS server. So I think of this as "browser-vetted 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.
Hopefully, safeguards against this can be installed in the browser, 
since it knows it's dealing with DNS packets.
> 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.
Yup, something similar is contemplated within the Caja effort with 
regard to passing Javascript resources between contexts running in the 
same browsers without compromising security. And of course the whole 
STUN handshake is an example of "pawn ticket" in action (if I understand 
the term correctly).
> 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
>>