Security

This page examines AxAp's approach to computer security. Because we aren't expert in this area, and we don't want to cause problems for our users, we'd like to follow best practices, such as making AxAp secure by design.

On the other hand, some of the things AxAp does would be concerning to a typical web developer. For example, we want to access local resources (e.g., commands, devices, files), based on input from a web browser. We also expect to assemble the running application from components created by assorted developers.

The attack surface of a software environment is the sum of the different points (the "attack vectors") where an unauthorized user (the "attacker") can try to enter data to or extract data from an environment.

Here are some naive attempts to characterize AxAp's attack surface and propose some responses.

Initial Software

Let's assume that an AxAp instance has been constructed using one or more Docker containers. Each container's file system image has been defined by (essentially) unknown parties, working separately. The behavior and motivations of the resulting application are thus entirely unpredictable.

However, Docker containers have very limited access rights, by default. So, even if the instance contains broken or infected software, the damage it can cause can be kept to an acceptable level. This is similar, philosophically, to the limitations placed on JavaScript code by web browsers.

In addition, security provisions can be set up within each container. These can monitor the application's behavior, prevent running components from infecting each other, etc. Obviously, this isn't a bulletproof solution, but we think it's a reasonable starting point.

Login

In normal operation (mode=safe or mode=safer), AxAp shouldn't give out much information. So, anyone requesting a web page is sent to the Login page. If they enter a valid username and password, appropriate access privileges are added to their session. (In mode=safer, the server uses HTTPS, preventing miscreants from snooping on the user's interactions.)

In demonstration mode (mode=demo), AxAp shows quite a number of pages, but we cannot show the contents of proprietary EPUBs. However, we want our developers and the publishers of those EPUBs to be able to inspect our renderings of them. So, if we receive a valid username and password, we can add appropriate access privileges.

In open access mode (mode=open) is specified, any local machine can access the server with full privileges (no login needed!). Obviously, this should only be used by developers working on private networks.

Network Access

It's inevitable that AxAp will be used (at least occasionally) on public networks. Even if it is being used on a nominally secure LAN, there's always the chance that the router has been compromised. So, we have to assume that miscreants can "sniff" packets on the network, direct packets at the system (and, indeed, at AxAp), etc.

Because AxAp is based on frameworks such as Phoenix and Sinatra, it can take advantage of their support for authentication, authorization, and other web-related defenses. In addition, all access can be mediated by HTTPS and other encryption-based technologies.

IP Address

Note: The following information was gathered by experimentation on a Mac Pro, running OSX 10.10.5. On any other machine, YMMV!

By default, Sinatra only responds to requests on "localhost". In this mode, it is inaccessible from other machines. In fact, it doesn't even respond on address "127.0.0.1". If settings[:bind] is set to 127.0.0.1, Sinatra will respond to requests for either that address or localhost.

However, if settings[:bind] is set to 0.0.0.0, Sinatra will respond to requests for either that address, 127.0.0.1, localhost, or the assigned address on the LAN (192.168.1.205). So, that appears to be a reasonable approach for allowing access from browsers on multiple machines.

Port Numbers

Sinatra's default port number is 4567, which is nicely out of the way. However, we have set up our demo server to respond to 64567 (and added a pinhole in CFCL's firewall).

HTTPS, SSL, etc.

In order to prevent miscreants from snooping on AxAp's traffic, we have implemented support for HTTPS, SSL, etc. However, until we figure out how to get a "real" certificate, we will be relying on a "self-signed" certificate. See the doc/issues/Security.md file for details...


This wiki page is maintained by Rich Morin, an independent consultant specializing in software design, development, and documentation. Please feel free to email comments, inquiries, suggestions, etc!

Topic revision: r14 - 14 Dec 2016, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email