[Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Konrad Rosenbaum]

On Sunday, Sunday 26 January 2014 at 23:46, Richard Moore wrote:
> The aim of the masking is to prevent request splitting and smuggling
> attacks when going through proxies. It prevents an application from
> being to trick proxies into beginning a new request that does
> something different to the one intended.
> 
> https://www.owasp.org/index.php/HTTP_Request_Smuggling

Thanks for the link, this is an interesting attack on faulty proxies.

Masking does not solve this attack completely. Only for browsers (in which 
case the "application" cannot control the mask) and scripts that don't have 
much time to mount their attack. 32 bits is not exactly a big obstacle, even 
if they consist of good random (however they are a big enough obstacle if the 
attacker does not control hundreds or thousands of browsers for a long enough 
time to attack the same target). And there remain enough attack surfaces 
outside websockets...

As far as I can see all request smuggling attacks rely on the attacker being 
able to inject Content-Length headers to confuse the proxy. I've read only the 
first 3 chapters of the RFC yet, but as far as I can see a Content-Length 
header should not be generated at all in a Websocket handshake (if we receive 
one: ignore the data and complain loudly with qWarning, if we receive more 
than one: panic and close the TCP connection immediately).

Are the following assumptions correct?

1) Websockets in Qt use different TCP connections than normal HTTP connections 
(QNAM for clients, and whatever is used as a HTTP server equivalent)

2) The Websocket implementation does not allow to manipulate/inject headers 
during handshake, esp. Content-Length (setting some pre-defined headers, like 
cookies and Sec-Websocket-Protocol is fine if the values are sanitized - 
remove newlines!)

3) the client side implementation always uses a fresh TCP connection and the 
CONNECT method (not GET) when faced with a proxy - even broken proxies should 
not care about content after CONNECT is successful

4) the first data packets are queued until the handshake is complete and only 
transmitted after a successful handshake

In that case we do not need to worry about "secure masking". If not, we may 
have to rethink the design and/or strong random (if we also care about 
corporations using outdated and broken proxies)...





	Konrad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140127/d34d0c4c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140127/d34d0c4c/attachment.sig>