by Michael Lubas
There are a number of resources online related to Elixir and Phoenix security, however when it comes to securing your own project, determining where to begin is a difficult task. Here are five recommendations to get started improving the security of your application.
The Erlang Ecosystem Foundation’s Security Working Group publishes guidelines on secure coding in Elixir and Erlang. Read through this entire document to get familiar with common examples of vulnerable code, it will give you an excellent foundation for the work ahead.
Sobelow is a static analysis tool created for the Phoenix framework. If your application is on the public internet, and handles customer data, you should be using it. The documentation and source code are both well written, and the creator Griffin Byatt gave a talk on common patterns of vulnerable code, ElixirConf 2017 - Plugging the Security Holes in Your Phoenix Application.
The talk assumes you have some knowledge on common web application vulnerabilities. If you are not familiar with terms such as XSS, CSRF, and directory traversal, a good book to read is The Web Application Hacker’s Handbook, 2nd edition, by Stuttard and Pinto.
MixAudit provides a mix task to scan dependencies for security vulnerabilities. While Sobelow finds vulnerabilities in Phoenix code you wrote, this finds vulnerabilities in the dependencies you use in your project. A common source of confusion is the difference between
mix deps.audit vs
mix hex.audit, here’s what
MixAudit's documentation says on this:
Mix provides a mix hex.audit task. According to its documentation, mix hex.audit shows all dependencies that have been marked as retired.
MixAudit provides a mix deps.audit task (similar to npm audit and bundler-audit) that scans dependencies for reported security vulnerabilities.
Both tasks are useful but they just don’t share the same purpose.
If your application is on the public internet, ask yourself the following questions:
If you answered yes to any of these, your application will be attacked by bots, and you need some form of defense in place. These attacks are called credential stuffing (for the login form), and carding (for the payments function).
Paraxial.io stops these attacks, and enterprise customers are eligible for a free bot risk assessment. There are also open source alternatives, see this article from Felt by Tyler Young on Rate Limiting Algorithms for Client-Facing Web Apps. Using reCaptcha is also an option, however this likely to frustrate users, and be bypassed by bots using 3rd party solving services.
Server Side Request Forgery (SSRF) is a type of vulnerability that occurs when a URL entered by a user triggers some outbound HTTP request in your application. An attacker can use this functionality to send requests to the server’s cloud hosting metadata service, leaking private credentials. The engineers at Slab have released an open source library, SafeURL, to prevent this. Audit your application to determine if user-provided URLs trigger HTTP requests in your code. If that is the case, use SafeURL to prevent SSRF attacks.
While the five examples in this article seem straightforward, correctly following each one is a significant project. If you would like guidance from someone experienced in Elixir/Phoenix security, Paraxial.io offers security consulting services in this area. Click here to book a call.
Paraxial.io is the only application security and compliance platform made for Elixir.
Subscribe for new posts about Elixir and Phoenix security.