- From: Frode Børli <frode@seria.no>
- Date: Thu, 19 Jun 2008 23:26:47 +0200
>> 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