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.
Let's assume that an AxAp instance has been constructed
using one or more Docker
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
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.
In normal operation (mode=safe
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.
, 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.
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
it can take advantage of their support for authentication
, and other web-related defenses.
In addition, all access can be mediated by HTTPS
and other encryption
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".
is set to 127.0.0.1, Sinatra will respond
to requests for either that address or localhost.
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.
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.
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!