Aptible does not have a WAF solution built-in but it is possible to use them with Aptible-hosted Apps. However, WAFs are not required for HIPAA compliance nor are they perfect. If they are configured too leniently, they may miss malicious requests and, if they’re too strict, they may block legitimate requests. For these reasons, we recommend using other methods to protect against request-based attacks.
Mitigating Request-Based Attacks
SQL Injection
Using an Object-Relational Mapping (ORM) when interacting with Databases will mitigate SQL injection attacks. The ORM will handle escaping string parameters so the Database can distinguish between SQL and parameters.
Cross-Site Request Forgery
Many frameworks guard against CSRF attacks. If you’re not using a framework or yours does not provide this protection you can implement a token based approach to mitigate this risk.
Cross-Site Scripting
XSS attacks can be mitigated by avoiding inserting untrusted data in dangerous places in HTML such as script tags, comments, and attribute names, escaping the data when putting it in the body of a tag, and avoiding running untrusted scripts. There are also some libraries and frameworks that handle these concerns.
WAF Placement
Like all reverse-proxies used with Aptible-hosted Apps, there are three main locations where a WAF can be deployed:
- Inside the same container as the App
- In its own dedicated App or Service
- Outside of Aptible
Each placement has some considerations on how to prevent users from circumventing the WAF and accessing the App directly.
Inside the App Container
When a WAF is deployed in the same container as the App it’s proxying, the Endpoint for this App has to target the port the WAF is listening on and the WAF must forward the request to the App.
This method ensures that all internal and external traffic must pass through the WAF in order to access the App and will scale with the App. However, it also increases the complexity of Apps and requires that the WAF be installed in all App Images that utilize it.
Dedicated Service
When deploying the WAF in its own dedicated Service, an External Endpoint must be created on the WAF Service and Internal Endpoints must be created on the Service(s) that the WAF is proxying. Users will connect to the WAF via the External Endpoint and the WAF will connect to the Service(s) via the Internal Endpoints.
This method prevents having to install the WAF in every App Image and a single WAF Service can serve multiple Services simultaneously. The downside is that that WAF won’t scale with the Services, another App on the Stack could circumvent the WAF and access an Internal Endpoint directly, and it can create a single point of failure for multiple Services though this can be mitigated by scaling the WAF horizontally.
Outside Aptible
Forcing users to connect to an App through a WAF deployed outside of Aptible is a little more tricky. An External Endpoint can still be used to allow the WAF to connect to the services it’s proxying but IP Filtering will need to be used to only allow access from the WAF. Otherwise, users could access the Endpoint directly and circumvent the WAF. An Internal Endpoint may also be used but the WAF will have to access it via a Network Integration.
There are many off-the-shelf products that can be used with this method but if they’re processing PHI a BAA will be required for HIPAA compliance. Unlike using a dedicated Service on Aptible Deploy, Apps on the same Stack will still have to route requests through the WAF in order to access the underlying App.