Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.

On Fri, Dec 4, 2009 at 02:47, Ian Hickson <ian@hixie.ch> wrote:
>> Although it is partly outside of the scope of the document, I still
>> would like to raise the question about why creating a new protocol and
>> not allowing plain TCP?
>
> It would be a security nightmare (e.g. it would mean a hostile Web site,
> when visited by a corporate user, could connect to an arbitrary HTTP
> server behind the intranet firewall and read its files).

I propose nothing (much) different than what is already available with
flash, so one is already exposed to the same problems. I think a good
implementation would have additional mechanisms to limit access for
just this reasons, but that is outside of the API specification.

>> I understand the need to limit the amount of damage a browser can do
>> via malicious javascript, but why not simply use one of the existing
>> limits of the current networking capable web technologies?
>> With Java applets you can connect to TCP ports on the same hostname
>> that served the applet (or is it the same IP?).
>
> That allows attacks on shared hosting providers, and prevents cross-site
> websocket access.

Yes, I agree that model isn't that good and I mentioned it only to
highlight that it is already possible for malicious code to do such a
connection, even though it is often easier to inject hostile
javascript than a new jar file.

>> With flash, you can connect to any server and any port as long as the
>> application can first download a policy file from the same IP number.
>
> Flash's security model has had so many security holes reported on it that
> I really don't want to try to emulate it. It also requires two sets of TCP
> connections per socket, and has some scary race conditions. It also
> requires talking to two different ports, which is dubious in shared
> hosting situations.

In shared hosting situations, the policy file should be generated from
other data sources, just like other firewall rules, no?

Just so we are talking about the same thing. When the current flash
player tries to connect with TCP to a server, it first connects to a
different port on that server and gets a policy file in response, the
player does only have to open the port and the server just have to
send a file and close the socket afterwards. So it wastes less network
and server resources than getting the FavIcon.ico file for example. I
don't know if the current player caches the result, but that could be
added. The policy file lists allowed origins of the swf file and port
numbers on that server that it is allowed to connect to.

The flash player has two other ways of getting its policy file. One
can change the policy port from the code. If no policy file could be
loaded, it connects to the service's port, sends a string
("<policy-file-request/>") and expects a policy file in return.

There have been different models in previous versions.

As far as I know there are two security problems with this model:
a) the application can measure the time it takes to get the policy
file and thus do port mapping. Skipping the two other ways of getting
the policy file would solve this without limiting the usefulness much.
I think this has been addressed in the latest version of the player by
returning the error after the same amount of time.
b) a naive implementation would use two different dns answers for the
two connections. This is an implementation issue more than a model
issue.

Are there other security problems with the model and not just its
implementations?

>> The "origin" concept is a great way to limit malicious javascript, but
>> so is flash policy files. If a policy file must be downloaded from a
>> specific port/URL, before the application is allowed to connect and the
>> browser caches the result for a while that would limit DoS attacks quite
>> well while at the same time make the WebSocket API powerfull enough to
>> make use of old protocols.
>
> What's wrong with the way WebSocket does it?

The WebSocket protocol can not connect to any existing services and I
think that is a pretty serious drawback and limits its usefulness a
lot.

The WebSocket protocol can be used to do portmapping.

Many custom protocols are based on a length field followed by a
protocol frame. With WebSocket it is possible to connect to such a
service and be connected for a while until a timeout happens and thus
a DoS attack against such a service would be trivial to write.

Regards,
Sebastian Andersson

Received on Friday, 4 December 2009 08:42:25 UTC