Định nghĩa chính thức

Chi tiết kỹ thuật

Điểm yếu xảy ra khi thao tác chuyển hướng tin cậy vào URL hoặc thành phần URL được cung cấp trong yêu cầu hay từ một nguồn chịu ảnh hưởng bên ngoài. Kẻ tấn công có thể thay đổi đích để một liên kết gắn với ứng dụng hợp lệ đưa người dùng đến trang do kẻ tấn công kiểm soát. Vì ứng dụng ban đầu vẫn có thể xuất hiện trong liên kết hoặc luồng xử lý, việc chuyển hướng có thể khiến trang lừa đảo trông đáng tin cậy hơn, đồng thời làm người dùng tiếp xúc với mã độc hoặc việc tải xuống ngoài ý muốn. Điểm yếu có thể bắt nguồn từ kiến trúc và thiết kế hoặc từ triển khai, bao gồm giả định rằng cookie, trường ẩn, header hoặc các giá trị nhận gián tiếp khác không thể bị sửa đổi.

Đặc điểm

Đây là điểm yếu độc lập với ngôn ngữ, thường xuất hiện trong ứng dụng web, trong đó dữ liệu từ nguồn bên ngoài đi đến đích chuyển hướng. Đặc trưng của điểm yếu là kiểm soát không đầy đủ đích chuyển hướng, đặc biệt khi ứng dụng chấp nhận URL bên ngoài tùy ý thay vì một tập đích bị giới hạn. Hồ sơ phân loại đây là điểm yếu cơ sở đơn giản và sử dụng các thuật ngữ tương đương Open Redirect, Cross-site Redirect, Cross-domain Redirect và Unvalidated Redirect.

Hậu quả thường gặp

Các tác động chính gồm vượt qua cơ chế bảo vệ và tạo điều kiện để kẻ tấn công chiếm quyền hoặc giả danh người dùng. Người bị chuyển hướng có thể đến một trang lừa đảo bắt chước trang hợp lệ, tiết lộ thông tin xác thực hoặc thông tin nhận dạng cá nhân, rồi để thông tin bị đánh cắp được sử dụng trên dịch vụ hợp pháp. Đích chuyển hướng cũng có thể phân phối mã độc hoặc kích hoạt việc tải xuống ngay lập tức; mã độc có thể ghi phím hoặc thực hiện các hành vi đánh cắp thông tin xác thực và dữ liệu quan trọng khác. Vì vậy, hậu quả liên quan đến kiểm soát truy cập, tính bí mật và các khía cạnh khác của an toàn người dùng và hệ thống.

Dữ liệu MITRE CWE chính thức

Tác động	Phạm vi	Diễn giải
Vượt qua cơ chế bảo vệ, Chiếm đặc quyền hoặc mạo danh	Kiểm soát truy cập	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 redirection to an external site may lead to endpoints on those sites that automatically trigger a download action ("drive-by download" [REF-1478]). This will expose the user to extensive risk. The user's interaction with the web server may also be compromised if the malware conducts keylogging or other attacks that steal credentials, personally identifiable information (PII), or other important data.
Vượt qua cơ chế bảo vệ, Chiếm đặc quyền hoặc mạo danh, Khác	Kiểm soát truy cập, Tính bí mật, Khác	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 phishers may then steal the user's credentials and then use these credentials to access the legitimate web site. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance.

Biện pháp giảm thiểu rủi ro

Sử dụng xác thực theo allowlist cho đích chuyển hướng: giả định dữ liệu là độc hại, kiểm tra độ dài, kiểu, cú pháp, giá trị được phép, tính nhất quán và quy tắc nghiệp vụ, đồng thời chỉ chấp nhận URL hoặc miền đã được phê duyệt. Khi tập đích đã biết, thay URL do người dùng cung cấp bằng các mã định danh cố định được ứng dụng ánh xạ tới đường dẫn hoặc URL được phép, và từ chối mọi mã khác. Một phương án khác là yêu cầu mọi yêu cầu chuyển hướng do bên ngoài cung cấp phải chứa nonce duy nhất, khó đoán và do ứng dụng tạo, nhưng cần lưu ý biện pháp này có thể bị vượt qua bằng XSS. Thu hẹp bề mặt tấn công bằng cách xác định mọi nguồn đầu vào trực tiếp và gián tiếp, gồm tham số, cookie, trường ẩn, header, thành phần URL, tệp, cơ sở dữ liệu, giá trị môi trường và kết quả API. Có thể dùng trang cảnh báo trung gian để thông báo người dùng đang rời trang, yêu cầu họ nhấp vào liên kết hoặc chờ lâu trước khi chuyển hướng, đồng thời tránh tạo XSS trên trang đó. Khi vận hành, tường lửa ứng dụng có thể cung cấp lớp phòng thủ bổ sung hoặc biện pháp tạm thời khi chưa thể sửa mã, nhưng có thể bỏ sót vectơ đầu vào, bị vượt qua, can thiệp vào yêu cầu hợp lệ và cần tùy chỉnh.

Dữ liệu MITRE CWE chính thức

Kiểm tra dữ liệu đầu vào · Hiện thực hóaAssume 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.
Kiến trúc và thiết kếUse 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.
Áp đặt quy tắc bằng chuyển đổi · Kiến trúc và thiết kế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.
Kiến trúc và thiết kếEnsure 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).Note that this can be bypassed using XSS (CWE-79).
Giảm bề mặt tấn công · Kiến trúc và thiết kế, Hiện thực hóaUnderstand 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.
Tường lửa · Vận hành · Hiệu quả: KháUse an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

Cách phát hiện trong hệ thống

Phân tích tĩnh thủ công và rà soát mã nguồn thủ công có thể đạt độ bao phủ cao với ít cảnh báo sai hơn khi có thể đánh giá mọi thao tác chuyển hướng có khả năng bị ảnh hưởng. Phân tích tĩnh tự động, gồm phân tích điểm yếu trên mã nguồn, binary hoặc bytecode, có thể mô hình hóa luồng dữ liệu và luồng điều khiển để tìm liên kết giữa nguồn đầu vào và điểm đích chuyển hướng; tuy nhiên, công cụ có thể không xác định đáng tin cậy liệu đầu vào có kiểm soát phần đầu của URL hay không, làm ảnh hưởng việc giảm cảnh báo sai. Phân tích động tự động có thể đưa URL vào các đầu vào và quan sát thay đổi của header Location; phân tích động với diễn giải tự động có thể dùng trình quét ứng dụng web, dịch vụ web và cơ sở dữ liệu, nhưng giới hạn độ bao phủ khiến chuyển hướng tùy biến có thể bị bỏ sót. Phân tích động với diễn giải thủ công có thể sử dụng trình fuzz và framework-based fuzzer. Rà soát kiến trúc và thiết kế có thể dùng phương pháp hình thức hoặc thiết kế đúng ngay từ đầu, còn inspection có thể cung cấp độ bao phủ một phần. Hồ sơ đánh giá cao các phương pháp thủ công, phân tích tĩnh tự động, phân tích binary hoặc bytecode, phân tích động và rà soát được liệt kê ở những nơi có ghi nhận mức hiệu quả.

Dữ liệu MITRE CWE chính thức

Phương pháp	Cách làm	Hiệu quả
Phân tích tĩnh thủ công	Since this weakness does not typically appear frequently within a single software package, manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all potentially-vulnerable operations can be assessed within limited time constraints.	Cao
Phân tích động tự động	Automated black box tools that supply URLs to every input may be able to spot Location header modifications, but test case coverage is a factor, and custom redirects may not be detected.	—
Phân tích tĩnh tự động	Automated static analysis tools may not be able to determine whether input influences the beginning of a URL, which is important for reducing false positives.	—
Phân tích tĩnh tự động	Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)	Cao
Phân tích tĩnh tệp nhị phân hoặc bytecode tự động	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis	Cao
Phân tích động với diễn giải kết quả tự động	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Web Application Scanner Web Services Scanner Database Scanners	Cao
Phân tích động với diễn giải kết quả thủ công	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Fuzz Tester Framework-based Fuzzer	Cao
Phân tích tĩnh mã nguồn thủ công	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Manual Source Code Review (not inspections)	Cao
Phân tích tĩnh mã nguồn tự động	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer	Cao
Rà soát kiến trúc hoặc thiết kế	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Formal Methods / Correct-By-Construction ``` Cost effective for partial coverage: ``` Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)	Cao

Lỗ hổng điển hình

Các ví dụ tiêu biểu trong hồ sơ chính thức gồm: CVE-2005-4206, trong đó tham số URL nạp URL vào frame khiến nó trông như thuộc về một trang hợp lệ; CVE-2008-2951, trong đó tham số của script tìm kiếm cho phép chuyển hướng đến các trang tùy ý và thực hiện lừa đảo; CVE-2008-2052, trong đó tham số URL cho phép chuyển hướng tùy ý và lừa đảo tương tự; và CVE-2020-11053, trong đó khoảng trắng được mã hóa HTML trong URL chuyển hướng vượt qua kiểm tra của reverse proxy OAuth2 viết bằng Go, đưa người dùng đã xác thực đến trang độc hại. Đây là các ví dụ tiêu biểu, không phải danh sách đầy đủ mọi lỗ hổng.

Dữ liệu MITRE CWE chính thức

Dưới đây là các lỗ hổng tiêu biểu liên quan đến CWE-601, dựa theo mức độ ưu tiên

Nguồn (9)

MITRE CWE

CWE Terms of Use

cprogramming.com

img2.helpnetsecurity.com

CWE-601: Chuyển hướng URL đến trang web không đáng tin cậy ('Open Redirect')

CWE-601 là gì?

Thống kê dữ liệu

Số lượng lỗ hổng nằm trong CWE-601

Số lượng lỗ hổng trong CISA KEV của CWE-601

Định nghĩa chính thức

Chi tiết kỹ thuật

Đặc điểm

Hậu quả thường gặp

Biện pháp giảm thiểu rủi ro

Cách phát hiện trong hệ thống

Lỗ hổng điển hình

Kiểm tra chuyên sâu cùng giải pháp quản lý rủi ro Web toàn diện