How Securing WebQuake Is Like Securing An Enterprise Application


July 20, 2015 | DevOps | Kevin Gilpin


Securing an Insecure App Using Conjur

Improving the security of an existing application which was not designed with security in mind is a common problem. Here’s a fun real-world example: WebQuake, a port of Quake 2 to HTML5 (client) and Node.js (server). It’s composed of the follower sub-projects:

  • Client A HTTP server (it’s not really a client…) which serves JavaScript and static assets (textures, sound etc). With only the Client web server, you can load and run single-player Quake 2 game in your browser.

  • A web browser which connects to the Client web server to retrieve the game assets and renders the game using HTML5.

  • Server which uses HTTP and WebSocket to implement multiplayer mode. From the browser, you can enter the Websocket URL to a Server; the Server will accept your connection automatically and join you to the running multi-player game.

See it for yourself (YouTube, 1 minute)

“We Didn’t Initially Prioritize Security”

Let’s Secure WebQuake

We were surprised how similar Quake is to an enterprise application in terms of the required “cleanup,” despite it being a video game. We chose it partly because it was never meant to be studied as an example of good security code. (And partly because it’s fun!)

There are several problems that need to be addressed:

Only one password per server

WebQuake implements a facility called “rcon” (remote control). From the browser, a Quake admin will send remote commands to the server, which will perform actions such as changing the map or kicking out players. “rcon” is protected by a single password which is shared among all the server admins.

Remember, password sharing is bad security because:

  • It’s impossible to revoke the access of an individual user.

  • Changing the password is difficult, because all users must be notified simultaneously

Furthermore, the WebQuake server does not have any secure mechanism for storing and restoring the password, or encrypting it at rest.

No traffic encryption

The client does not support the use of an encrypted channel. The “rcon” password we mentioned earlier is being sent over a plaintext channel.

Traffic between the browser and the servers should use HTTPS.

Weak traffic authorization

The server doesn’t implement any authorization of inbound traffic, aside from the “rcon” password.

Fixing the problems

Step 1 – kill the passwords

We will remove the “rcon” password from both the client and the server. This strips WebQuake to its core: a game, not a user authorization system!

Remove the client password:

Remove the server password:

Step 2 – refactor the application security architecture

Rather than use passwords to control access, we’ll use a traffic authorization gatekeeper.

Refactor with traffic authorization

To implement traffic authorization, we will add two additional services:

  • Forwarder a reverse proxy which runs on the local machine of each player. The Forwarder intercepts each connection to the server, and places an authorization token on it (which it has obtained from the Token Broker).

  • Gatekeeper a reverse proxy which sits in front of the server. It intercepts all inbound requests, and verifies the token authenticity and authorization privileges of the client with the Token Broker.

In this manner, access management is handled entirely outside WebQuake.

Step 3 – Define the security policy

The server will use role-based access control. We’ll declare this using a policy document and commit it to the server code repository.

To deploy the WebQuake server, an administrator will load the policy to create application roles and resources.

The gatekeeper will run outside the game, enforcing the security policy before traffic reaches the game. A dedicated security layer allows the application developer to focus on the application, not on security. The gatekeeper will enable us to use separate roles for system administrators, regular game players, and game superusers (players who can use rcon).

Step 4 – Assign client (user) identity and grant roles

To use the server, clients must present an auth token to the gatekeeper. They can obtain this token from the security authentication service, by presenting a username and password (or API key).

Each client is assigned these credentials, and granted one of the roles defined in the policy.

Step 5 – Deploy

To make the application easier to deploy, we’ll package each component as a Docker container. Then, both the client and server can be launched and managed using Docker tools.

(If all the Dockerizing details were presented here, this would quickly turn into a post about Docker! Read Securing Docker With Secrets and Dynamic Traffic Authorization for details.)


The full WebQuake application now consists of:

  • Web, a dockerized HTTP server, serving static assets

  • Proxy forwarder running on the local machine, intercepting outbound requests

  • Web browser

  • Server Gatekeeper intercepting traffic, authorizing it, and passing authorized traffic through to the server.

View a complete run-through! (YouTube, 6 minutes)





Keep up-to-date on security best practices, events and webinars.

Share This