GHSA-72h4-mxfc-jx37

Summary

Heimdall performs host matching in a case-sensitive manner, while HTTP hostnames are case-insensitive. This discrepancy can result in heimdall failing to match a rule for a request host that differs only in letter casing, potentially causing the request to be classified differently than intended.

Note: The issue can only lead to unintended access if heimdall is configured with an "allow all" default rule. Since v0.16.0, heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled, e.g. via --insecure-skip-secure-default-rule-enforcement or the broader --insecure flag.

Details

This vulnerability can potentially be exploited by an adversary if rule matching relies on the request host.

For example, consider the following rule:

id: rule-1
match:
  hosts:
    - type: exact
      value: admin.example.com
execute: # configured to require authentication and authorization
  # ...

If an adversary now sends a request with the Host header set to Admin.Example.Com, rule-1 will not be matched, and the following will happen instead:

• If no default rule is configured, the request will result in an error (404 Not Found)
• If a default rule is configured, it will be executed. If the default rule is configured in an overly permissive way (e.g. allowing anonymous access), this results in a policy bypass.

Impact

Bypass of access control policies enforced by heimdall may lead to the following consequences:

• Access to or modification of data that should be restricted
• Invocation of functionality that is expected to require authentication or authorization
• In certain configurations, escalation of privileges depending on the exposed functionality

Workarounds

• Normalize request hosts to lowercase in the layers in front of heimdall.
• Do not configure a permissive default rule. Respectively, do not make use of the --insecure or the...