W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2008

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

From: João Araújo <jta@fe.up.pt>
Date: Thu, 19 Jun 2008 23:06:32 +0100
Message-ID: <485AD868.4050003@fe.up.pt>
Frode B?rli wrote:
>>> 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).
>   
What if the DDOS attack is on the DNS servers rather that the server 
you're supposedly connecting to? I might be wrong, but you could always 
ask for a TCPConnection for each of an unlimited amount of bogus 
subdomains which could overload the DNS server with record requests. 
Just a thought.
Received on Thursday, 19 June 2008 15:06:32 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:03 UTC