CVE Vulnerabilities

CVE-2023-22418

URL Redirection to Untrusted Site ('Open Redirect')

Published: Feb 01, 2023 | Modified: Nov 07, 2023
CVSS 3.x
6.1
MEDIUM
Source:
NVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
CVSS 2.x
RedHat/V2
RedHat/V3
Ubuntu

On versions 17.0.x before 17.0.0.2, 16.1.x before 16.1.3.3, 15.1.x before 15.1.7, 14.1.x before 14.1.5.3, and all versions of 13.1.x, an open redirect vulnerability exists on virtual servers enabled with a BIG-IP APM access policy. This vulnerability allows an unauthenticated malicious attacker to build an open redirect URI. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Weakness

A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.

Affected Software

Name Vendor Start Version End Version
Big-ip_analytics F5 13.1.0 13.1.5
Big-ip_policy_enforcement_manager F5 13.1.0 13.1.5
Big-ip_local_traffic_manager F5 13.1.0 13.1.5
Big-ip_link_controller F5 13.1.0 13.1.5
Big-ip_fraud_protection_service F5 13.1.0 13.1.5
Big-ip_application_security_manager F5 13.1.0 13.1.5
Big-ip_application_acceleration_manager F5 13.1.0 13.1.5
Big-ip_advanced_firewall_manager F5 13.1.0 13.1.5
Big-ip_access_policy_manager F5 13.1.0 13.1.5
Big-ip_access_policy_manager F5 15.1.0 *
Big-ip_advanced_firewall_manager F5 15.1.0 *
Big-ip_analytics F5 15.1.0 *
Big-ip_application_acceleration_manager F5 15.1.0 *
Big-ip_application_security_manager F5 15.1.0 *
Big-ip_domain_name_system F5 15.1.0 *
Big-ip_fraud_protection_service F5 15.1.0 *
Big-ip_link_controller F5 15.1.0 *
Big-ip_local_traffic_manager F5 15.1.0 *
Big-ip_policy_enforcement_manager F5 15.1.0 *
Big-ip_ddos_hybrid_defender F5 15.1.0 *
Big-ip_ddos_hybrid_defender F5 13.1.0 13.1.5
Big-ip_ssl_orchestrator F5 13.1.0 13.1.5
Big-ip_advanced_firewall_manager F5 14.1.0 *
Big-ip_advanced_firewall_manager F5 16.1.0 *
Big-ip_advanced_firewall_manager F5 17.0.0 *
Big-ip_access_policy_manager F5 17.0.0 *
Big-ip_analytics F5 17.0.0 *
Big-ip_application_acceleration_manager F5 17.0.0 *
Big-ip_application_security_manager F5 17.0.0 *
Big-ip_domain_name_system F5 17.0.0 *
Big-ip_fraud_protection_service F5 17.0.0 *
Big-ip_link_controller F5 17.0.0 *
Big-ip_local_traffic_manager F5 17.0.0 *
Big-ip_policy_enforcement_manager F5 17.0.0 *
Big-ip_ssl_orchestrator F5 17.0.0 *
Big-ip_ssl_orchestrator F5 15.1.0 *
Big-ip_ssl_orchestrator F5 14.1.0 *
Big-ip_policy_enforcement_manager F5 14.1.0 *
Big-ip_local_traffic_manager F5 14.1.0 *
Big-ip_link_controller F5 14.1.0 *
Big-ip_domain_name_system F5 14.1.0 *
Big-ip_ddos_hybrid_defender F5 14.1.0 *
Big-ip_application_security_manager F5 14.1.0 *
Big-ip_analytics F5 14.1.0 *
Big-ip_access_policy_manager F5 14.1.0 *
Big-ip_access_policy_manager F5 16.1.0 *
Big-ip_analytics F5 16.1.0 *
Big-ip_application_acceleration_manager F5 16.1.0 *
Big-ip_application_security_manager F5 16.1.0 *
Big-ip_ddos_hybrid_defender F5 16.1.0 *
Big-ip_domain_name_system F5 16.1.0 *
Big-ip_fraud_protection_service F5 16.1.0 *
Big-ip_link_controller F5 16.1.0 *
Big-ip_local_traffic_manager F5 16.1.0 *
Big-ip_policy_enforcement_manager F5 16.1.0 *
Big-ip_ssl_orchestrator F5 16.1.0 *

Potential Mitigations

  • Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Use a list of approved URLs or domains to be used for redirection.
  • When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
  • For example, ID 1 could map to “/login.asp” and ID 2 could map to “http://www.example.com/". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
  • Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  • Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.

References