HTML and CSS Reference
In-Depth Information
Denial of service attacks against web servers come in many flavors. Some DoS
attacks begin from botnets consisting of thousands of compromised PCs; such attacks
are completely under the control of the attacker. Some may consider that botnets are just
a part of modern life on the Internet. There are other attacks, however, that web origin
security can address directly. The web platform can make it more challenging to abuse
features of the Web to launch DoS attacks. In the case of WebSocket, because receiving
servers can use the origin header to verify the origin of incoming requests, DoS attacks
are much more difficult to accomplish. Servers can ban connections from unknown or
attacking origins, saving server resources by rejecting connections.
The proper origin header is included in all WebSocket requests made by browsers.
What about applications that don't run in browsers at all? You may notice that there is
nothing stopping you from opening a socket in a console application and writing any
origin you like. Servers don't really know that a request with a particular origin header
came from a web application; all they know is that a request did
not
come from a web
application from a different origin. One question people ask over and over again is, if
origin is so easily spoofed, what security does it provide? Understanding the answer
requires understanding the true nature of WebSockets, as described in the next section.
What is a WebSocket (from a Security Perspective)?
If you've made it this far in this topic, you know the many benefits afforded by using
WebSocket in your applications. As described in Chapter 1, WebSocket has many
desirable features. WebSocket is a simple, standard, full-duplex protocol with low
overhead that can be used to build scalable, near real-time network servers. If you're
an astute student of computing or recall slightly earlier days, you know that most of
these traits apply equally well to plain, unadulterated TCP/IP. That is, they are traits of
sockets (in particular SOCK_STREAM) and not of WebSockets. So why add the “Web” to
“Sockets”? Why not simply build traditional Internet applications on top of TCP?
To answer this question, we need to distinguish between “unprivileged” and
“privileged” application code. Unprivileged code is code running within a known origin,
and is typically JavaScript running inside of a web page. In the Web security model, TCP
connections cannot be safely opened by “unprivileged code.” If unprivileged application
code were allowed to open TCP connections, it would be possible for a script to originate
HTTP requests with spoofed headers that falsely appear to come from a different origin.
The ability to spoof headers in this way would make it pointless to have rules governing
how scripts can make HTTP connections if the same scripts could sidestep those rules
by re-implementing HTTP over TCP. Allowing TCP connections from web applications
would break the origin model.
WebSocket connections formed from unprivileged code must therefore follow the same
model as AJAX and other network capabilities allowed to unprivileged code. The HTTP
handshake puts connection initialization under browser control and allows the browser
to set the origin header and other headers that are necessary for preserving the origin
model. This way, WebSocket allows applications to perform Internet-style networking with
lightweight bidirectional connections while coexisting with HTTP applications, servers, and
sandboxing rules.
WebSocket connections formed from privileged code can typically open any network
connections; this ability isn't a problem (or at least, isn't a problem for the Web), because
