Re: [hybi] Web sockets and existing HTTP stacks

Maciej Stachowiak <mjs@apple.com> Wed, 03 February 2010 23:46 UTC

Return-Path: <mjs@apple.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8118B3A689D for <hybi@core3.amsl.com>; Wed, 3 Feb 2010 15:46:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOZqAaBCCBvJ for <hybi@core3.amsl.com>; Wed, 3 Feb 2010 15:46:37 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id BF8953A6811 for <hybi@ietf.org>; Wed, 3 Feb 2010 15:46:37 -0800 (PST)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id E0C8F8A009D1 for <hybi@ietf.org>; Wed, 3 Feb 2010 15:47:21 -0800 (PST)
X-AuditID: 11807137-b7bd4ae000000f0d-a3-4b6a0b090199
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id 84.F4.03853.90B0A6B4; Wed, 3 Feb 2010 15:47:21 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.246.16.190] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KXA00B97I2X9J80@elliott.apple.com> for hybi@ietf.org; Wed, 03 Feb 2010 15:47:21 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <ADFF563C-46E7-457D-86BE-6EFEB1F57AFD@d2dx.com>
Date: Wed, 03 Feb 2010 15:47:21 -0800
Message-id: <6DBD0DC4-065A-4390-A68A-85A148127B96@apple.com>
References: <557ae280911171402v7546e5e7n93a1e57f87dc10e5@mail.gmail.com> <ad99d8ce1002012139l3b8f525bj9caf7861332f3d18@mail.gmail.com> <1427E183-FDBC-4854-9455-B93AB28DAB03@apple.com> <ad99d8ce1002012343n132169f8wbaacc1cf4efe2f87@mail.gmail.com> <31123817-6D3F-489D-9F48-109AC93E6769@apple.com> <ad99d8ce1002030000i566f3517qddf4e62f386c9211@mail.gmail.com> <4B692EDB.1060300@gmx.de> <E9DF7FE9-70F0-4268-8CEF-1007D71F9FBB@apple.com> <ad99d8ce1002030107i5994c847yf639b660dc64cdc9@mail.gmail.com> <7CB6EE56-B840-4368-ABAF-C8AA1CCE6600@apple.com> <ad99d8ce1002030956w7503957eg8bd6e88da66a884a@mail.gmail.com> <D8279D52-AE47-46F6-84DA-8E348116662A@apple.com> <ADFF563C-46E7-457D-86BE-6EFEB1F57AFD@d2dx.com>
To: Vladimir Katardjiev <vladimir@d2dx.com>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: hybi@ietf.org
Subject: Re: [hybi] Web sockets and existing HTTP stacks
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2010 23:46:38 -0000

On Feb 3, 2010, at 2:51 PM, Vladimir Katardjiev wrote:

> 
> For the second case, I don't see at all why this would help on a websocket server that doesn't validate input data... or on a websocket server at all. Since the nonce is opaque to the server, why can't I just send something that pretends to be a nonce from my xhr?

XDomainRequest cannot send custom headers, so it cannot send WebSocket-Nonce at all. Cross-site XHR using CORS cannot send custom headers without the server explicitly opting into that header via a preflight request. So it would be unable to send WebSocket-Nonce unless there was a major configuration error that led to replying to preflight with permission to send a WebSocket-Nonce header. We could also blacklist all headers starting with WebSocket- in CORS.

> It should properly parse, as long as it's [a-zA-Z0-9]+ and the server will happily reply. But it stands to reason if you don't validate your input you're open to attacks. The best you can do is always force the WebSocket server to validate the handshake (which, if I'm not mistaken, you're arguing anyway?)

I am indeed arguing that. But part of the reason for the nonce is to protect non-WebSocket servers from being exploited using WebSocket.

Regards,
Maciej