HTML and CSS Reference
In-Depth Information
acknowledgement of headers. Of these headers, some begin with the prefix “ Sec- ”, and
are described in RFC 6455. These headers are used in the opening WebSocket handshake
(see Table 3-2 for a full description of these Sec- headers):
Several header names are reserved by browsers for platform-level usage in the
XMLHttpRequest specification and thus are off-limits for use in applications. These
header names include those starting with Sec-, as well as common security-critical
headers like referer , host , and cookie .
The new headers defined in RFC 6455 are all prefixed with Sec- . These prefixes
are so named because the browser is opening WebSocket connections on behalf of
applications, but the low-level, security sensitive parameters in the handshake are off-
limits to application code. This effectively locks down upgrade requests so that they can
only be made through APIs like the WebSocket constructor and not through general
HTTP APIs like XMLHttpRequest.
WebSocket Secure Handshake: Accept Keys
You may recall from our discussion of the WebSocket Protocol that WebSocket
connections succeed based on the server's response. The server must respond to the
initial WebSocket handshake with the 101 response code, WebSocket upgrade header,
and Sec-WebSocket-Accept header. The value of the Sec-WebSocket-Accept response
header is derived from the Sec-WebSocket-Key request header and contains a special key
response that must match exactly what the client expects.
The reason for the required exchange of the Sec-WebSocket-Key and Sec-WebSocket
headers between the client and server is not obvious. The keys are only used during
connection initialization, are easily intercepted, and clearly offer no protection to
WebSocket clients or servers. What could these keys be protecting? These keys actually
protect non -WebSocket servers and eliminate the possibility of cross-protocol attacks.
Examples of cross-protocol attacks are those that make specially crafted WebSocket
requests to non-WebSocket servers in order to establish connections or otherwise exploit
them, and confuse servers expecting one protocol by making cleverly crafted connections
with another protocol. To prevent cross protocol attacks using WebSocket, the handshake
requires that the server transform a client-supplied key. If the server does not reply as
expected, the client closes the connection. The WebSocket RFC contains a Globally
Unique Identifier (GUID), which is a magic key used to identify the protocol rather than
the connection or the user or any other participant in the system. The GUID is
258EAFA5-E914-47DA-95CA-C5AB0DC85B11 .
Search WWH ::

Custom Search