DEVOPSdigest

The previous blog in this WhiteHat Security series recommended executing the app as one or more stateless processes by using small programs that communicate over the network. From a security standpoint it’s key to always assume that all process inputs are controlled by hackers, and create one or more processes that are dedicated exclusively to security services.

Start with Security and the Twelve-Factor App - Step 1

Start with Security and the Twelve-Factor App - Step 2

Start with Security and the Twelve-Factor App - Step 3

Start with Security and the Twelve-Factor App - Step 4

Start with Security and the Twelve-Factor App - Step 5

Start with Security and the Twelve-Factor App - Step 6

Step 7 of the Twelve-Factor App focuses on exporting services via port binding, and what to apply from a security point of view. Here is some actionable security-focused advice which developers and ops engineers can follow during the SaaS build and operations stages.

Defining Port Binding in the Twelve-Factor App

In this seventh step, the Twelve-Factor methodology encourages the integration of the network handling traffic code inside your running application. To explain, web apps are sometimes executed inside a web server container. For example, PHP apps might run as a module inside Apache HTTPD(link is external), or Java apps might run inside Tomcat(link is external).

The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.

The challenge is that these modules must still be configured, which can lead to security risks if an app is bound to privileged ports or protected with poor passwords.

Applying Security to Step 6

To elevate security risks, bind your app to an unprivileged port and make use of port forwarding facilities. Unprivileged ports are any port number greater than 1024. Binding to a port above 1024 will not require system or root level privileges, thus allowing your app to run with least privilege. Port forwarding can then be used to transfer production traffic from a well-known privileged port, such as port 443, to a non-privileged port being used by your app. This can be achieved at the operating system level, often using firewall configurations. For example, the IP Tables firewall is commonly used to achieve port forwarding on Linux operating systems.

In the next blog we’ll chat through Step 8, which recommends scaling out via the process model, and two simple processes that can be incorporated to enhance security.

Read Security and the Twelve-Factor App - Step 8