Arp Spoofing in Phoenix

ARP spoofing (Address Resolution Protocol spoofing) is a layer-2 network attack where an attacker sends falsified ARP messages onto a local network, linking their MAC address with the IP address of a legitimate host (like your Phoenix server or a client). This enables man-in-the-middle (MITM) or denial-of-service attacks. While ARP spoofing targets the network infrastructure, its impact on a Phoenix application manifests through the exposure of unencrypted traffic and misconfigured network bindings that make the application accessible on shared or untrusted local networks.

In a Phoenix context, this vulnerability typically arises from two patterns:

• Binding to all network interfaces (0.0.0.0): A common development or misconfigured production setting in config/prod.exs where the Phoenix endpoint listens on 0.0.0.0. This exposes the API (HTTP or WebSocket) on every network interface, including any private or guest networks that might be compromised via ARP spoofing. An attacker on the same physical or virtual network segment can intercept traffic destined for the Phoenix server.
• Unencrypted WebSocket (WS) channels: Phoenix Channels over plain WebSocket (ws://) transmit all channel messages, including authentication tokens and user data, in cleartext. If an attacker performs ARP spoofing between a client and the Phoenix server, they can capture and manipulate these messages. This is particularly dangerous for real-time features like chat, notifications, or live dashboards.

Consider this vulnerable Phoenix endpoint configuration:

# config/prod.exs - VULNERABLE
config :my_app, MyAppWeb.Endpoint,
  http: [ip: {0, 0, 0, 0}, port: 4000],
  url: [host: "example.com"],
  debug_errors: false,
  secret_key_base: System.get_env("SECRET_KEY_BASE"),
  # No force_ssl, channels use ws://

Here, the server binds to all interfaces (ip: {0,0,0,0}) and does not enforce SSL redirection. An attacker on the same LAN can ARP spoof the gateway, intercept HTTP requests, and steal session cookies or inject malicious JavaScript into responses. The WebSocket connections remain unencrypted, allowing real-time traffic interception.

Additionally, Phoenix's default plug Plug.SecureHeaders might be missing or misconfigured, failing to set Strict-Transport-Security (HSTS) headers. Without HSTS, even if a user initially accesses via HTTPS, a subsequent network-level attack could downgrade the connection to HTTP, exposing the API.

Detecting ARP spoofing exposure in a Phoenix application involves identifying configurations that increase the attack surface on the local network and verifying the enforcement of encrypted transport. Since ARP spoofing is a network-layer attack, detection focuses on the application's network footprint and TLS posture rather than application logic flaws.

1. Review Endpoint Binding Configuration
Check your config/prod.exs (or config/runtime.exs for newer projects) for the http: and https: options. Binding to {0,0,0,0} (IPv4) or :: (IPv6) indicates the application listens on all interfaces. This is acceptable only if the server is on a dedicated, physically secure network. For cloud or shared environments, bind to the specific private IP of the network interface that serves public traffic.

# config/runtime.exs - SAFER EXAMPLE
if config_env() == :prod do
  config :my_app, MyAppWeb.Endpoint,
    http: [ip: {10, 0, 1, 15}, port: 80], # Bind to specific private IP
    https: [
      ip: {10, 0, 1, 15},
      port: 443,
      cipher_suite: :strong,
      keyfile: System.get_env("SSL_KEY_PATH"),
      certfile: System.get_env("SSL_CERT_PATH")
    ],
    force_ssl: [hsts: true], # Enforce HTTPS and HSTS
    url: [host: "api.example.com", port: 443]
end

2. Enforce HTTPS and HSTS
Ensure force_ssl is enabled in your endpoint configuration. This sets the Strict-Transport-Security header and redirects HTTP to HTTPS. Without it, an attacker can force a client to use HTTP after an initial ARP spoofing-induced connection reset.

3. Validate WebSocket Security
In your Phoenix channel client code (JavaScript), verify that the WebSocket connection uses wss:// (WebSocket Secure). The connection URL should be derived from the endpoint's __END__ URL configuration, which should be HTTPS.

// assets/js/user_socket.js - SECURE
let socket = new Socket("/socket", {
  params: {user_token: userToken},
  // Phoenix automatically uses wss:// if the page was loaded via HTTPS
});
socket.connect();

4. Scan with middleBrick
While middleBrick does not directly test for ARP spoofing (a network-layer issue), it can detect configuration weaknesses that exacerbate the risk. Scan your Phoenix API endpoint (e.g., https://api.example.com) with the CLI:

middlebrick scan https://api.example.com --format json

Review the output for findings related to:

• Encryption (TLS): Check if TLS is enforced and properly configured. A finding like "HTTP endpoint detected without HTTPS enforcement" indicates the API is accessible via unencrypted HTTP, making it vulnerable to MITM via ARP spoofing.
• Data Exposure: Look for sensitive data (API keys, tokens) in responses that could be harvested if traffic is intercepted.
• Rate Limiting: Absence of rate limiting could allow an attacker to perform reconnaissance or brute-force attacks after poisoning the ARP cache.

Example middleBrick JSON snippet for a missing HTTPS enforcement:

{
  "score": 65,
  "grade": "C",
  "categories": {
    "encryption": {
      "score": 30,
      "findings": [{
        "severity": "high",
        "title": "HTTP endpoint accessible without HTTPS redirection",
        "description": "The API is reachable via HTTP on port 80. An attacker on the local network could perform ARP spoofing to intercept unencrypted traffic.",
        "remediation": "Configure the Phoenix endpoint with `force_ssl: [hsts: true]` and ensure all requests are served over HTTPS."
      }]
    }
  }
}

This finding highlights a configuration that, while not an ARP spoofing flaw itself, creates the conditions for an ARP spoofing attack to succeed against your Phoenix API.

Remediation focuses on minimizing the local network attack surface and ensuring all traffic is encrypted end-to-end. Phoenix provides built-in mechanisms to enforce these protections.

1. Bind to Specific Interfaces
Never bind your production Phoenix endpoint to {0,0,0,0} unless the server is on an isolated, trusted network. In config/runtime.exs (or config/prod.exs), set the ip option to the specific private IP address of the network interface that should receive public traffic. This limits exposure to only the intended network segment.

# config/runtime.exs
config :my_app, MyAppWeb.Endpoint,
  http: [ip: {10, 0, 1, 15}, port: 80], # Replace with your server's private IP
  https: [
    ip: {10, 0, 1, 15},
    port: 443,
    cipher_suite: :strong,
    keyfile: System.get_env("SSL_KEY_PATH"),
    certfile: System.get_env("SSL_CERT_PATH")
  ],
  # ...

2. Enforce HTTPS and HSTS
Activate force_ssl in your endpoint configuration. This does two things: redirects all HTTP requests to HTTPS and adds the Strict-Transport-Security header, telling browsers to only use HTTPS for your domain for a specified duration (e.g., 1 year). This prevents protocol downgrade attacks that could follow an ARP spoofing event.

# config/runtime.exs
config :my_app, MyAppWeb.Endpoint,
  force_ssl: [hsts: true, expires: 31536000, host: "api.example.com"],
  # ...

3. Secure Phoenix Channels
Phoenix Channels automatically use the same protocol as the page load. If your page is served over HTTPS, the Socket will use wss://. Ensure all pages that establish channel connections are served exclusively via HTTPS. You can also set the transport_log to false in production to avoid logging sensitive channel payloads that might be intercepted in a MITM scenario.

# lib/my_app_web/channels/user_socket.ex
defmodule MyAppWeb.UserSocket do
  use Phoenix.Socket

  ## Channels
  channel "room:*", MyAppWeb.RoomChannel

  # Only allow connections over wss:// (enforced by endpoint force_ssl)
  @impl true
  def connect(_params, socket, _connect_info) do
    {:ok, socket}
  end

  @impl true
  def id(_socket), do: nil
end

4. Set Secure Cookie Flags
Phoenix session cookies should have the secure flag (sent only over HTTPS) and httponly flag (inaccessible to JavaScript). This prevents session theft via MITM or XSS. In your endpoint configuration:

# config/runtime.exs
config :my_app, MyAppWeb.Endpoint,
  session: [
    store: :cookie,
    key: "_my_app_key",
    signing_salt: System.get_env("SIGNING_SALT"),
    secure: true, # Only send over HTTPS
    httponly: true # Not accessible via JS
  ],
  # ...

5. Network-Level Defenses (Outside Phoenix)
While not Phoenix-specific, complement application fixes with network controls: use static ARP entries on critical servers, implement DHCP snooping and dynamic ARP inspection (DAI) on network switches, and segment your network so Phoenix servers reside on a VLAN with restricted access. These measures prevent ARP spoofing at the infrastructure level.

After applying these changes, rescan your API with middleBrick to verify that the Encryption category score improves and the HTTP-to-HTTPS redirection finding is resolved. For continuous assurance, add middleBrick's GitHub Action to your CI pipeline to fail builds if HTTPS enforcement is ever regressed.