HTTP Protocols

What is HTTP?

REST with JSON over HTTP is the standard for services today. No matter what language or framework we use, it boils down to shipping some chunk of formatted, semantically meaningful text as an HTTP request and waiting for an HTTP response.

HTTP protocols vulnerability

Of course, all HTTP-based protocols use sockets, so they are vulnerable to all of the problems described previously. HTTP adds its own set of issues, mainly centered around the various client libraries.

Let’s consider some of the ways that such an integration point can harm the caller:

• The provider may accept the TCP connection but never respond to the HTTP request.

• The provider may accept the connection but not read the request. If the request body is large, it might fill up the provider’s TCP window. That causes the caller’s TCP buffers to fill, which will cause the socket write to block. In this case, even sending the request will never finish.

• The provider may send back a response status the caller doesn’t know how to handle. Like “418 I’m a teapot.” Or more likely, “451 Resource censored.”

• The provider may send back a response with a content type the caller doesn’t expect or know how to handle, such as a generic web server 404 page in HTML instead of a JSON response. In an especially pernicious example, the ISP may inject an HTML page when the DNS lookup fails.

• The provider may claim to be sending JSON but actually sending plain text. Or kernel binaries. Or another unrecognized message.

Client libraries

Use a client library that allows fine-grain control over timeouts including both the connection timeout and read timeout and response handling.

We recommend you avoid client libraries that try to map responses directly into domain objects. Instead, treat a response as data until we’ve confirmed it meets our expectations. It’s just text in maps (also known as dictionaries) and lists until you decide what to extract. We’ll revisit this theme in the Security chapter.