Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1000 CNY

100.0%
Buy Us a Coffee

CWE-601 (指向未可信站点的URL重定向(开放重定向)) — Vulnerability Class 722

722 vulnerabilities classified as CWE-601 (指向未可信站点的URL重定向(开放重定向)). AI Chinese analysis included.

CWE-601 represents a critical web application vulnerability where the software accepts user-controlled input to specify a redirect destination without adequate validation. Attackers typically exploit this weakness by crafting malicious URLs that redirect victims to untrusted, phishing sites, often leveraging the trust associated with the legitimate domain to bypass security warnings. This social engineering tactic facilitates credential theft, malware distribution, or session hijacking. To mitigate this risk, developers must implement strict validation mechanisms, such as maintaining an allowlist of permitted domains or verifying that redirect parameters originate from the same origin. Additionally, using relative paths instead of absolute URLs can significantly reduce the attack surface. By ensuring that all redirection targets are explicitly trusted and verified before processing, organizations can prevent unauthorized navigation and protect users from deceptive external links.

MITRE CWE Description
The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.
Common Consequences (2)
Access ControlBypass Protection Mechanism, Gain Privileges or Assume Identity
The user may be redirected to an untrusted page that contains malware which may then compromise the user's system. In some cases, an open redirect can also enable the immediate download of a file without the user's permission, because the r…
Access Control, Confidentiality, OtherBypass Protection Mechanism, Gain Privileges or Assume Identity, Other
By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam. The user may be subjected to phishing attacks by being redirected to an untrusted page. The phishing attack may point to an attacker controlled web page that appears to be a trusted web site. The phi…
Mitigations (5)
ImplementationAssume 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…
Architecture and DesignUse an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.
Architecture and DesignWhen 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.
Architecture and DesignEnsure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).
Architecture and Design, ImplementationUnderstand 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 throug…
Examples (2)
The following code obtains a URL from the query string and then redirects the user to that URL.
$redirect_url = $_GET['url']; header("Location: " . $redirect_url);
Bad · PHP
http://example.com/example.php?url=http://malicious.example.com
Attack
The following code is a Java servlet that will receive a GET request with a url parameter in the request to redirect the browser to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and send a response to redirect the browser to the url address.
public class RedirectServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String query = request.getQueryString(); if (query.contains("url")) { String url = request.getParameter("url"); response.sendRedirect(url); } } }
Bad · Java
<a href="http://bank.example.com/redirect?url=http://attacker.example.net">Click here to log in</a>
Attack · HTML
CVE IDTitleCVSSSeverityPublished
CVE-2017-8451 Elasticsearch Kibana 输入验证错误漏洞 — Elastic X-Pack Security 6.1 -2017-06-16
CVE-2011-1594 Spacewalk: spacewalk: open redirect vulnerability enables phishing attacks via url parameter — Red Hat Enterprise Linux 6 6.5 Medium2014-02-05

Vulnerabilities classified as CWE-601 (指向未可信站点的URL重定向(开放重定向)) represent 722 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.