Sobelow: Static analysis for the Phoenix Framework
Written by: Griffin Byatt

Phoenix Framework?
The Phoenix Framework is a relatively new web framework, powered by the Elixir programming language. Elixir runs on the Erlang Virtual Machine, which promises low-latency, distributed, and fault-tolerant systems. As such, Phoenix is being adopted by companies across the spectrum, and it’s being chosen for more new projects every day. Despite this growing popularity, there has been very little information or tooling around securing and auditing Phoenix applications.
Background
This lack of available information made Phoenix an attractive research topic, and, early this year, I started looking at the security posture of the framework and surrounding ecosystem. As I analyzed more Phoenix applications, I discovered a number of common vulnerabilities. Some of these vulnerabilities are common across frameworks, such as directory traversal or SQL injection; and others are more Elixir-specific, like denial of service through atom creation. To aid in identification of these common security concerns, I created Sobelow.
How does Sobelow help?
Sobelow is the first security-focused static analysis tool for the Phoenix framework. For security researchers, it is a useful tool for getting a quick view of points-of-interest. For project maintainers, it can be used to prevent the introduction of a number of common vulnerabilities.
Currently Sobelow detects some types of the following security issues:
- Insecure Configuration
- Known-Vulnerable Dependencies
- Cross-Site Scripting
- SQL Injection
- Command Injection
- Denial of Service
- Directory Traversal
- Unsafe Serialization
Potential vulnerabilities are flagged in different colors according to confidence in their insecurity. High confidence is red, medium confidence is yellow, and low confidence is green.
Design Choices
Sobelow was built specifically for scanning Phoenix applications. However, with a few warnings, it should be able to scan just about any Elixir library you throw at it. The reason for this choice is that the Phoenix Framework generally enforces a common set of configurations and files within Phoenix applications. Although it is technically possible for Sobelow to scan arbitrary Elixir libraries, the commonalities between Phoenix apps allow Sobelow to make some assumptions about project structure, and the confidence in a finding. For instance, Phoenix applications have a router made up of pipelines. If a pipeline accepts “html” but is missing the “protect_from_forgery” plug, it is highly likely to be vulnerable to Cross-Site Request Forgery.
In regards to the actual reporting, Sobelow makes a couple of strong choices. First and foremost, Sobelow favors over-reporting to under-reporting. Because of this, you may notice a lot of “green” (low confidence) findings in your output. A finding is typically marked “low confidence” if it looks like a function could be used insecurely, but it cannot reliably be determined if the function accepts user-supplied input. That is to say, green findings are not secure, they just require greater manual validation.
Related to this, Sobelow also doesn’t allow users to blanket ignore findings of a specific severity. Instead, users are encouraged to use a decorator-like “skip” functionality to mark functions as do-not-report on an individual basis.
Anything else?
Sobelow has a number of additional options to tailor your scan to fit your needs. These options, and additional information can be found in the repository on GitHub: https://github.com/nccgroup/sobelow
Published date: 27 July 2017
Originally published at www.nccgroup.trust.


