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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.