[Webkit-unassigned] [Bug 32246] Multiple connection attempts to a WebSocket server should not be allowed

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 7 21:58:49 PST 2009


https://bugs.webkit.org/show_bug.cgi?id=32246





--- Comment #2 from Fumitoshi Ukai <ukai at chromium.org>  2009-12-07 21:58:49 PST ---
Chromium implement this in SocketStreamHandle, but it's not clean.
It needs to sniff data to detect handshake message.

To implement it in WebCore/websocket,  we need to add some methods in
SocketStreamHandle and SocketStreamHandleClient.

 - new SocketStreamHandle
        resolve ip address from host.
        calls back client->willOpen(handle, addresslist);
 - in WebSocketChannel, maintain table of address that is running handshake.
   if handle's address is open, call handle->connect().
   otherwise, wait other handle's handshake finishes, or close.

  - in WebSocketChannel, once handshake is finished or closed, clear its
addresses from table.
     pick next handle which address becomes free from the table, and call
handle->connect().



(In reply to comment #0)
> We don't have the following implemented yet:
> 
> -------------------------------
>    1.   If the user agent already has a Web Socket connection to the
>         remote host (IP address) identified by /host/, even if known by
>         another name, wait until that connection has been established or
>         for that connection to have failed.
> 
>         NOTE: This makes it harder for a script to perform a denial of
>         service attack by just opening a large number of Web Socket
>         connections to a remote host.
> 
>         NOTE: There is no limit to the number of established Web Socket
>         connections a user agent can have with a single remote host.
>         Servers can refuse to connect users with an excessive number of
>         connections, or disconnect resource-hogging users when suffering
>         high load.
> -------------------------------

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list