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):
•
Sec-WebSocket-Key
•
Sec-WebSocket-Accept
•
Sec-WebSocket-Extensions
•
Sec-WebSocket-Protocol
•
Sec-WebSocket-Version
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
.
