Sobelow is a static analysis tool for discovering vulnerabilities in Phoenix applications.

Command Injection

Command Injection vulnerabilities are a result of passing untrusted input to an operating system shell, and may result in complete system compromise.

Command Injection in :os.cmd

This submodule of the CI module checks for Command Injection vulnerabilities through usage of the :os.cmd function.

Command Injection in System.cmd

This submodule of the CI module checks for Command Injection vulnerabilities through usage of the System.cmd function.

Configuration

Submodules contained within this vulnerability type are related to common insecurities found in how Phoenix applications are configured.

Missing Content-Security-Policy

Content-Security-Policy is an HTTP header that helps mitigate a number of attacks, including Cross-Site Scripting.

Cross-Site Request Forgery

In a Cross-Site Request Forgery (CSRF) attack, an untrusted application can cause a user's browser to submit requests or perform actions on the user's behalf.

Cross-Site Request Forgery

In a Cross-Site Request Forgery (CSRF) attack, an untrusted application can cause a user's browser to submit requests or perform actions on the user's behalf.

Cross-Site Websocket Hijacking

Websocket connections are not bound by the same-origin policy. Connections that do not validate the origin may leak information to an attacker.

HSTS

The HTTP Strict Transport Security (HSTS) header helps defend against man-in-the-middle attacks by preventing unencrypted connections.

HTTPS

Without HTTPS, attackers in a privileged network position can intercept and modify traffic.

Missing Secure HTTP Headers

By default, Phoenix HTTP responses contain a number of secure HTTP headers that attempt to mitigate XSS, click-jacking, and content-sniffing attacks.

Hard-coded Secrets

In the event of a source-code disclosure via file read vulnerability, accidental commit, etc, hard-coded secrets may be exposed to an attacker. This may result in database access, cookie forgery, and other issues.

Denial of Service

The Denial of Service (DOS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.

Denial of Service via Unsafe Atom Interpolation

In Elixir, atoms are not garbage collected. As such, if user input is used to create atoms (as in :"foo#{bar}", or in :erlang.binary_to_atom), it may result in memory exhaustion. Prefer the String.to_existing_atom function for untrusted user input.

Denial of Service via List.to_atom

In Elixir, atoms are not garbage collected. As such, if user input is passed to the List.to_atom function, it may result in memory exhaustion. Prefer the List.to_existing_atom function for untrusted user input.

Denial of Service via String.to_atom

In Elixir, atoms are not garbage collected. As such, if user input is passed to the String.to_atom function, it may result in memory exhaustion. Prefer the String.to_existing_atom function for untrusted user input.

IO helpers. Mostly mirror Mix.Shell.IO, but Mix will not always be available to Sobelow.

Miscellaneous

This suite of tests is to be a catch-all for checks that don't fall neatly into the other detection categories.

Insecure use of binary_to_term

If user input is passed to Erlang's binary_to_term function it may result in memory exhaustion or code execution. Even with the :safe option, binary_to_term will deserialize functions, and shouldn't be considered safe to use with untrusted input.

Insecure use of File and Path

Note: This check has been deprecated. File/Path issues were addressed with the release of OTP 21.

Remote Code Execution

Remote Code Execution vulnerabilities are a result of untrusted user input being executed or interpreted by the system and may result in complete system compromise.

Code Execution in eval function

Arbitrary strings passed to the Code.eval_* functions can be executed as malicious code.

Insecure EEx evaluation

If user input is passed to EEx eval functions, it may result in arbitrary code execution. The root cause of these issues is often directory traversal.

SQL Injection

SQL Injection occurs when untrusted input is interpolated directly into a SQL query. In a typical Phoenix application, this would mean using the Ecto.Adapters.SQL.query method and not using the parameterization feature.

SQL Injection in Query

This submodule of the SQL module checks for SQL injection vulnerabilities through usage of the Ecto.Adapters.SQL.query.

SQL Injection in Stream

This submodule of the SQL module checks for SQL injection vulnerabilities through usage of the Ecto.Adapters.SQL.stream.

Path Traversal

Path traversal vulnerabilities are a result of interacting with the filesystem using untrusted input. This class of vulnerability may result in file disclosure, code execution, denial of service, and other issues.

Directory Traversal in File function

This submodule checks for directory traversal vulnerabilities in the File module.

Directory Traversal in send_download

This submodule checks for directory traversal vulnerabilities in the send_download function of a Phoenix Controller.

Directory Traversal in send_file

This submodule checks for directory traversal vulnerabilities in the send_file function.

Known Vulnerable Dependencies

An application with known vulnerabilities is more easily subjected to automated or targeted attacks.

Coherence Version Vulnerable to Privilege Escalation

For more information visit: https://github.com/advisories/GHSA-mrq8-53r4-3j5m

Plug Version Vulnerable to Arbitrary Code Execution in Cookie Serialization

For more information visit: https://github.com/advisories/GHSA-5v4m-c73v-c7gq

Ecto Version Lacks Protection Mechanism

For more information visit: https://github.com/advisories/GHSA-2xxx-fhc8-9qvq

Plug Version Vulnerable to Header Injection

For more information visit: https://github.com/advisories/GHSA-9h73-w7ch-rh73

Plug Version Vulnerable to Null Byte Injection

For more information visit: https://github.com/advisories/GHSA-2q6v-32mr-8p8x

Phoenix Version Vulnerable to Arbitrary URL Redirection

For more information visit: https://github.com/advisories/GHSA-cmfh-8f8r-fj96

Cross-Site Scripting

Cross-Site Scripting (XSS) vulnerabilities are a result of rendering untrusted input on a page without proper encoding. XSS may allow an attacker to perform actions on behalf of other users, steal session tokens, or access private data.

XSS in put_resp_content_type

If an attacker is able to set arbitrary content types for an HTTP response containing user input, the attacker is likely to be able to leverage this for cross-site scripting (XSS).

XSS in html

This submodule looks for XSS vulnerabilities in html calls from the Phoenix Controller.

XSS in raw

This submodule checks for the use of raw in templates as this can lead to XSS vulnerabilities if taking user input.

XSS in send_resp

This submodule looks for XSS vulnerabilities in the body argument of Conn.send_resp.

Sobelow is a static analysis tool for discovering vulnerabilities in Phoenix applications.