[whatwg] Implementation of a good HTTPSocket (TCP-socket)

>> Web pages should only be allowed to access other servers when the
>> script has been digitally signed, and when the user has agreed to
>> giving the script elevated privileges - or there should be a
>> certificate on the origin server which is checked against DNS records
>> for each server that the script attempts to connect to.

I have changed my view on this. Only a DNS record is required:

1. A script by default can only connect to the server that it was
downloaded from.
2. Server A has a script that tries to connect to Server B. Server B
must have a record in its DNS that allows scripts originating from
Server A.

Nothing more should be needed, a DDOS attack using javascript can
never succed unless the attacker controls the DNS servers. I think
this DNS method could be used for all cross site scripting security
policies (java applets, flash etc). Additionally, the client can have
policies disallowing reconnects in for example one minute, if the
server responds with HTTP 401 Access Denied.

>> So what we want is a http based protocol which allow the client to
>> continue communicating with the script that handles the initial
>> request.
> I absolutely agree that this would be the best way. However, couldn't
> we use Michaels proposal for that? It seems to solve the same problems
> and is actually compliant HTTP (in theory at least).

We should have both a pure TCPConnection, and a ServerConnection
object. It could possibly be based on the BEEP protocol, i dont know
that protocol. All I know is that HTTP has mechanisms for switching
protocols (HTTP 101 Switching Protocols), and is a good basis for
browser to webserver communications already.

The ServerConnection should have some mechanisms in the protocol that
allows transmission of events from the server and to the server - as
well as sending variables/structures. Example:

var data = { name: "Frode B?rli", address: "Norway" }
document.serverConnection.send(data)

Also the client can add arbitrary event listeners to the
serverConnection object:

document.serverConnection.onwhatever = function(message) {
alert(message.city); }

The server should be able to listen to all DOM events also.

> I find the SessionID header a very good idea though.What are the
> thoughts on that?
>
> I'm sorry if that has already been discussed, but if we use HTTP, why
> can't we use the Access Control spec as an "opt in mechanism" that is
> a little easier to implement than DNS? If you modify the behaviour a
> little, you could even use it against DDOS attacks:

Without DNS records (or an alternative implementation) i think the
TCPConnection and the ServerConnection object should be restricted by
the same rules as XMLHttpRequest.

> "Counter suggestion": When a WebSocket objects attempts to connect,
> perform Access Control checks the way you would for POST requests.
> If the check fails and if the server response contains an
> Access-Control-Max-Age header, agents must immediately close the
> connection and must not open a connection to that resource again (or,
> if Access-Control-Policy-Path is present, to any resource specified)
> until the specified time has elapsed.
> That way, administrators that are hit by a DDOS can simply put

By securing with DNS records, administrators will not have to do
anything to prevent ddos, as it can't happen. Without DNS records, the
script is allowed only to connect to the same server that it was
fetched from. (Same as Java applets, Flash applets and XMLHttpRequest)

> Access-Control: allow <*> exclude <evilsite.example.com>
> Access-Control-Max-Age: 86400
> Access-Control-Policy-Path: /

I think the idea is good, but I do not like the exact implementation.
I think the server should be able to see which script is initiating
the connection (header sent from the client), and then the server can
respond with a HTTP 401 Access Denied. No need to specify anything
more. No need to specify which hosts that are allowed, since the
script can decide that on a number of parameters (like IP-address
etc).

Received on Thursday, 19 June 2008 14:26:47 UTC