Identifying Security Issues in Elixir Web Applications

EEF’s Security Working Group [8] describes a special document for best practices for secure web applications running on BEAM. The recommendations are divided into five big groups: “Common Web Application Vulnerabilities”, “Session Management Vulnerabilities”, “TLS Vulnerabilities”, “Information Leakage”, and “Supply Chain Vulnerabilities”. These recommendations are mostly related to the use of the Phoenix [14] framework for web applications. In this paper, we will focus on the “Common Web Application Vulnerabilities”.

RefactorErl [24] is a static source code analysis and transformation tool designed for Erlang. RefactorErl performs lexical and syntactic analysis on the source code, builds an Abstract Syntax Tree (AST), and calls a set of static semantic analysers to extend the AST with semantic information. The result of these analyses is stored in the Semantic Program Graph (SPG) [11]. The SPG can be considered as an intermediate source code representation for Erlang source code. Different static analysis, code comprehension, or refactoring functionalities can be built on top of the SPG [3]. RefactorErl also provides data- and control-flow analysis [24]. A security analyser framework was built for Erlang applications on top of RefactorErl [22, 23]. Our aim is to extend this framework with Elixir analysis.

Elixir programs are compiled to the same intermediate source-code representation (the so-called Abstract Format¹¹1https://www.erlang.org/doc/apps/erts/absform.html) as Erlang programs. RefactorErl can build the SPG from the Abstract Format: it maps the Abstract Format to its AST and performs the semantic analysis on it. The semantics of the Erlang and Elixir generated trees are the same, thus we can run the semantic analysers designed for Erlang on the Elixir AST, and we can define Elixir static analyses within the RefactorErl framework.

A variety of static analysis tools exist to assist developers in identifying security flaws and code quality issues. Popular tools include SonarQube [5], SpotBugs [18], and CodeChecker [12, 20], among others. These tools are designed to integrate seamlessly into commonly used integrated development environments (IDEs). Other examples of widely adopted static analysis tools include ESLint [10] for JavaScript, Bandit [16] for Python, and Brakeman [4] for Ruby on Rails. These tools all contribute to improved code security and quality by catching potential issues early in the development lifecycle, and are usually incorporated into CI/CD (Continuous Integration and Deployment) pipelines, automatically scanning for vulnerabilities with each build.

Although security checkers for Erlang have been around for a while, they are now gaining increased interest within the Elixir community.

The empirical study looks into vulnerability commits of 25 open-source Elixir projects [2]. It was found that 2% of commits were vulnerability-related. The study also found that in 9 out of 25 projects, one security vulnerability was present. The study suggests further research into the problem is needed and suggests the use of static code analysis tools for more detailed results.

Several static analysis tools support Elixir analysis. Sobelow [15] is the most popular security-focused static analysis tool for Elixir and its web framework Phoenix. It detects the following issues: Insecure configuration, Known-vulnerable Dependencies Cross-Site Scripting, SQL injection, Command injection, Code execution, Denial of Service, Directory traversal, and Unsafe serialization. The tool provides the confidence of each insecurity, dividing it into three color-coded categories: green–low, yellow–medium, and high–red. It also rather over-reports than under-reports, resulting often in false positives. Usually, the results of running a tool need to be triaged (evaluated). EEF recommends including Sobelow in a CI/CD pipeline so it can be run every time code is merged into the main branch [8].

Semgrep [17] is an open-source static analysis tool that supports more than 30 programming languages, including Elixir. Semgrep also allows user to enforce their own rules for code standards in a code-like manner. The tool uses pattern-oriented matching technology.

Cross-site scripting (XSS) is a common security vulnerability where a web application incorporates user input without performing validation, allowing the user to inject malicious code into the victim’s web browser.

Phoenix framework provides protection from XSS attacks. However, weak spots for potential abuse are: Phoenix.HTML.raw/1 and Phoenix.Controller.html/2 functions, which render the user’s input. Rendering tainted input can also be achieved using a pipeline of functions send_resp and put_resp_content_type or put_resp_header given that the put_resp_content_type or put_resp_header are accepting “text/html” and send_resp is accepting tainted value as third argument.

Cross-Site Request Forgery (CSRF) is a vulnerability in web applications that allows an attacker to issue commands on behalf of a victim user.

Phoenix provides default protection against CSRF by combining the protect_from_forgery plug with automatically included CSRF tokens in its form helpers when POST requests are used in HTML forms. However, when GET requests are used to change the state, the application is vulnerable to CSRF, which Action Reuse commonly refers to as CSRF.

Cross-Site WebSocket Hijacking (CSWHS) is a vulnerability similar to Cross-Site Request Forgery, but an attacker seeks to establish a WebSocket connection. If successful, the attacker can establish a direct line of communication between themselves and the server, using the victim’s session as if they were the victim.

Phoenix’s connect_info mechanism passes session information to the WebSocket. When the session is exposed using this mechanism, Phoenix applies CSRF protections to prevent attackers from hijacking the WebSocket connection.

CSRF token verification in Phoenix does not block WebSocket connections but only applies when session information is requested. The connect callback must close the connection if authentication fails. Phoenix also offers the check_origin parameter to block connections based on the browser’s Origin header, allowing connections only if the origin matches the configured hostname by default. If cross-origin connections are needed, the origin check can be disabled, but authentication should then rely on a token passed via query parameters instead of cookies.

SQL injection is a type of attack targeting web applications where malicious input is processed by the underlying database, leading to unauthorized operations being executed.

Phoenix applications usually use Ecto, a database wrapper and query generator. When used properly, Ecto prevents SQL injection. However, if raw SQL queries are being passed to Ecto, it could lead to SQL injection. SQL injection occurs when user input is used to build a query directly.

For example, the Ecto.Adapters.SQL.query/4 function executes a custom SQL query. If user input is passed here, it could lead to SQL injection.

A Denial-of-Service attack occurs when a malicious user attempts to overload a website with requests, slowing it down or making it inaccessible. In the context of Elixir applications, one subtle and dangerous way this can occur is through the uncontrolled creation of atoms based on user input. Since the atoms in Elixir and Erlang are not garbage collected and are stored permanently in memory, an attacker can trigger the creation of a large number of unique atoms that can exhaust the system’s atom table, which has a fixed size (by default, 1,048,576 entries). Once this limit is reached, the virtual machine will crash, making this a particularly serious risk for Denial-of-Service vulnerabilities in applications written in Elixir.

The algorithm for detecting XSS vulnerabilities, referred to as Algorithm 1, is a modified version of the algorithm defined in [1] for identifying OS injections. The location of function calls posing an XSS threat is found, and then data-flow analysis is run on those functions’ parameters. By leveraging RefactorErls’ data-flow analysis, we can implement security checkers that reduce false positives. We can trace the origins of arguments and see whether they come from a trusted source or not.

Helper function get_calls_for_xss searches for function calls defined in Matchers. For a vulnerable candidate found, the parameters are checked with get_expr_params_for. Here we filter out the parameters on which the data-flow analysis is going to be run. The get_origins function runs the data-flow analysis and returns possibly tainted input. Further, the get_unsafe_funs checks against the developer’s whitelisted functions. Any function that appears on the whitelist is treated as reliable. In functions get_funs_no_body and get_exported_funs we check if the parameters are functions without bodies or functions that are exported. In both cases, the parameters can introduce security vulnerabilities into the application; as a result, these expressions are automatically classified as unsafe.

Checking if CSP is employed is checking if put_secure_browser_headers plug or plug_content_security_policy plug are being used. Since these plugs can accept policies, we can check the origin of these arguments by using Algorithm 1.

Algorithm 2 describes finding XSS vulnerability if the content-type of the server response is being set by the user by using a pipeline consisting of send_resp and put_resp functions. The analyze_funs is matching the first ten lines of Algorithm 1 for send_resp first parameter. The resulting data-flow value AnalyzedFunctions is checked for being tainted by applying lines 11–14 from Algorithm 1. If the first argument of send_resp is tainted, we check if the third one is also tainted, and if yes, the function is vulnerable. If the first argument is a put_resp call, then we check its third argument for value ‘‘text/html’’ or being tainted. If that is the case, then we can look into this argument of send_resp, and if it is tainted too, the function is vulnerable.

Algorithm 3 is a modified version of Algorithm 1 where we are only looking for the existence of a function defined in a plug. Here, we are looking to see if the function is missing and not if it is being used with trusted sources. CSRF detection is described in Algorithm 3.

In Phoenix, there is not a single built-in function or parameter that explicitly guarantees token-based authentication is passed through query parameters across the framework for CSWHS protection. Instead, developers typically implement token-based authentication using query parameters manually, depending on their specific use case. Therefore, there is not a simple and reliable checker for this issue.

SQL Injection is checked by applying Algorithm 1 and checking all the Ecto vectors for SQL injection defined by EEF. In Algorithm 1, the second line has to be changed to:

DoS and atom exhaustion checkers are not just Phoenix-specific, web-related security issues but general Elixir vulnerabilities. Therefore, these have already been implemented in the RefactorErl tool [23]. Application layer attacks are dependent on logic and implementation, making them unsuitable for detection with static analysis tools.

We analyzed and compared the results with Sobelow for the following projects. The projects were chosen so that they are actively used by the community and have the vulnerabilities discussed in this paper. In Table 1, we see the size of the projects and their respectable lines of code.

• $\mathrm{■}$

  Hexpm²²2https://github.com/hexpm/hexpm is a repository website that hosts packages used by Hex, Elixir’s package manager. Hexpm is widely used in Elixir projects to fetch different libraries.

• $\mathrm{■}$

  Changelog³³3https://github.com/thechangelog/changelog.com is an open-source podcast software that provides content for developers. These podcasts are listened to by more than tens of thousands of users.

• $\mathrm{■}$

  Plausible Analytics⁴⁴4https://github.com/plausible/analytics?tab=readme-ov-file is an open-source alternative to Google Analytics that is more concerned with privacy. It is an independent tool funded by its subscribers. It has 15 thousand paid subscribers, and more than 136 billion tracked page reviews.

In Tables 2, 3 and 4, the results obtained from Sobelow and RefactorErl are compared for the common vulnerabilities in web applications described by EEF. The column names are defined as follows: Num is the total number of found vulnerabilities in each category, FP is False Positive, and FN is False Negative. In the RefactorErl section, we differentiate between reachable and unreachable vulnerabilities. Reachable vulnerabilities are those that are accessible to outside users as exported functions, while unreachable vulnerabilities are present in the beam code but are not used in the project and are not accessible through developer-defined functions that are exported. Unreachable vulnerabilities are the result of Elixir macro expansions.

XSS attacks are by far the most common vulnerability in the analysed projects. We distinguish between three cases of XSS attacks, as already described above. The most common one is using Phoenix.HTML.raw/1 with tainted values.

Since we use beam code for analysis, we can find the function calls that are sometimes hidden in, e.g., $\sim$H sigil that Sobelow does not find. In Phoenix $\sim$H is a sigil used to define HEEx, HTML + Elixir, templates. It is a shorthand for writing HTML-safe templates that can include embedded Elixir code. The embedded Elixir code is not picked up by Sobelow.

Additionally, Table 2 shows that in some cases a vulnerability is detected but flagged as Traversal.FileModule: Directory Traversal in File.read!, as illustrated in the Figure 5.

In all three projects, Sobelow’s and RefactoErl’s results match for CSP, the difference being in the intent whether to interpret it as high or low severity level as discussed above.

Table 2 confirms consistent results for CSRF. In contrast, in Table 3, we observe one false positive value in Sobelow where one CSRF Action by reuse being vulnerability was falsely flagged. It only had a GET method action without the corresponding POST method. In Table 4 we have two unreachable CSRF calls that are a result of expanding macros not having CSRF protection.

When it comes to SQL injection, many vulnerabilities remain unreachable because of the use of Ecto.Repo macro, which can expand to functions using Elixir.Ecto.Adapters.SQL’ vectors: {query,3}, {’query!’, 3},{’query_many’, 3} and {’query_many!’, 3} depending on the version of Ecto used. We also see one false positive value in Table 3. In this case, the arguments of the query are constant and are not tainted.

Results for Denial Of Services are matching in Table 2 and Table 3, while in Table 4, we have two unreachable positives due to macro expansion in RefactorErl and two false positives and one false negative in Sobelow. Two false positives come from binary interpolation of constant values. One false negative comes from not recognizing that the input of function String_to_atom is the constant list (Figure 6). This can be detected with RefactorErl using data-flow analysis.