Synchronizing Requests and Responses

This example assumes that we are managing a simple line-based protocol. Each request is one line long, delimited by a new-line character (\n). Each response might be very long, but is finished by a single line containing a dot (".\n").

This protocol is similar to many simple line-based protocols like POP, IMAP or SMTP, although they each have more sophisticated ways if indicating when a response has finished. The protocol is persistent - there might be many requests and responses within a single connection.

You can use a simple client-first or server-first Virtual Server to manage this protocol.

You might want to intercept a particular request and return a response directly from the Traffic Manager without forwarding the request to the back-end server, but it might be desirable to keep the connection open and forward other requests to the server. This example permits all requests other than "HACKME\n", for which "403 Go Away!\n.\n" is returned

A first attempt might be as follows:

# get the request
$req = request.getLine();

if( $req == "HACKME\n" ) {
request.sendResponse( "403 Go away!\n.\n" );
}

This simple filter has great potential for being subverted. A determined hacker could:

Try sending the requests byte-by-byte to fool any parsing code (this would not work in this case).

Try sending two requests in one packet - the first is valid, the second is “HACKME”. The above filtering code lets the entire packet through.

Send one request and a partial "HACK" in one packet, then send "ME\n" in a second packet when the attacker receives the response from the first request. Our sample filter does not recognize the fragmented "HACKME" request.

To avoid these potential errors, it is necessary to synchronize individual requests, processing each request in turn and buffering up any additional data for the next request:

# get the request
$req = request.endsWith( "\n" );

if( $req == "HACKME\n" ) {
request.sendResponse( "403 Go away!\n.\n" );
}

Using request.endsWith() causes data to be read up to, and including, the “\n”. This data alone is then processed, going through the request and response stage of the state machine. When a response has been received from the server, the next request starts processing, which might contain data that was postponed from the previous request.

This simply and effectively guards against attempts to subvert the parser by sending two requests in one, or by sending partial requests.

This solution has an unfortunate side effect. If a user sends two requests in quick succession, and the first request causes the server to send a large response, with the second request being the “HACKME” message that causes the Traffic Manager to send a response itself.

If the “HACKME“ request is received while the server is still responding to the previous request, the Traffic Manager’s direct response might be interleaved with the server's response, resulting in a corrupt data stream back to the client.

The solution is to synchronize responses in the data stream, so that processing of the next request is delayed until the previous request has completed. This can be achieved with a simple response rule:

$res = response.getLine();
while( $res != ".\n" ) {
response.flush( string.len( $res ) );
$res = response.getLine();
}

The response rule does not complete until a line containing ".\n" is received. When it completes, all remaining response data is flushed to the client and the next request is processed.