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

Chi tiết kỹ thuật

Xác thực đầu vào áp dụng cho dữ liệu thô và siêu dữ liệu, bao gồm chuỗi, số, tham số, nội dung tệp, tiêu đề và kích thước. Việc kiểm tra có thể cần xác định giới hạn kích thước và giá trị, chỉ mục và độ lệch, khóa biểu tượng, tính đúng cú pháp và token, kiểu dữ liệu, tính nhất quán giữa các giá trị liên quan, sự phù hợp với quy tắc nghiệp vụ, tính tương đương, cũng như tính xác thực hoặc quyền sở hữu.

Dữ liệu có thể đơn giản hoặc có cấu trúc lồng nhau nhiều tầng, kết hợp siêu dữ liệu với dữ liệu thô. Ứng dụng cũng phải tính toán chính xác các thuộc tính được suy ra từ dữ liệu. Lỗi có thể phát sinh khi nhà phát triển tin cậy các kiểm tra phía máy khách, cookie, trường biểu mẫu ẩn hoặc đầu vào khác mà kẻ tấn công có thể sửa đổi, hoặc khi việc xác thực không đầy đủ, diễn ra trước khi ghép dữ liệu từ nhiều nguồn, hay bị vượt qua do khác biệt về giải mã và biểu diễn dữ liệu.

Đặc điểm

Đây là một lỗi xác thực có phạm vi rộng, không chỉ giới hạn ở một định dạng đầu vào. Lỗi có thể ảnh hưởng đến dữ liệu mạng, tham số và tiêu đề yêu cầu, cookie, biến môi trường, kết quả tra cứu DNS ngược, thành phần URL, email, tệp và tên tệp, cơ sở dữ liệu, kết quả API và dữ liệu từ hệ thống bên ngoài. Các dạng lỗi gồm thiếu hoặc thừa giá trị, cú pháp sai, kiểu không hợp lệ, giá trị ngoài phạm vi, trường độ dài hoặc kích thước không nhất quán, tham chiếu không an toàn và vi phạm quy tắc nghiệp vụ.

Lỗi thường được đưa vào từ giai đoạn kiến trúc và thiết kế khi hiểu sai ranh giới tin cậy, cũng như từ giai đoạn triển khai khi bỏ sót hoặc áp dụng kiểm tra không nhất quán. Cần đặc biệt chú ý tại giao diện giữa các thành phần, ranh giới giữa các ngôn ngữ và quá trình chuyển đổi giữa biểu diễn bên ngoài với dữ liệu nội bộ.

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

Tùy thuộc vào đầu vào và thành phần bị ảnh hưởng, kẻ tấn công có thể gây treo, khởi động lại, tiêu thụ quá mức CPU hoặc bộ nhớ, hoặc gây từ chối dịch vụ theo cách khác. Việc kiểm soát các tham chiếu tài nguyên có thể làm lộ bộ nhớ, tệp hoặc thư mục. Đầu vào độc hại cũng có thể sửa đổi bộ nhớ hoặc dữ liệu, thay đổi luồng điều khiển, hoặc dẫn đến thực thi mã hay lệnh trái phép.

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

Tác động	Phạm vi	Diễn giải
Từ chối dịch vụ: sập, thoát hoặc khởi động lại, Từ chối dịch vụ: tiêu thụ tài nguyên CPU, Từ chối dịch vụ: tiêu thụ bộ nhớ	Tính sẵn sàng	An attacker could provide unexpected values and cause a program crash or arbitrary control of resource allocation, leading to excessive consumption of resources such as memory and CPU.
Đọc bộ nhớ, Đọc tệp hoặc thư mục	Tính bí mật	An attacker could read confidential data if they are able to control resource references.
Thay đổi bộ nhớ, Thực thi mã hoặc lệnh trái phép	Tính toàn vẹn, Tính bí mật, Tính sẵn sàng	An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.

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

Kiến trúc và thiết kế:

Giảm bề mặt tấn công bằng cách xác định mọi đường mà dữ liệu không đáng tin cậy có thể đi vào, bao gồm cả đầu vào gián tiếp nhận được qua các lệnh gọi API.
Cân nhắc kỹ thuật bảo mật dựa trên lý thuyết ngôn ngữ. Sử dụng ngôn ngữ đầu vào hình thức và một lớp phân tích, nhận dạng riêng biệt để tách đầu vào thô khỏi biểu diễn nội bộ.
Sử dụng thư viện hoặc framework xác thực đã được thiết lập như Struts hoặc OWASP ESAPI Validation API, đồng thời kiểm tra cách sử dụng vì framework không tự động loại bỏ mọi lỗi xác thực.
Lặp lại các kiểm tra bảo mật ở máy chủ nếu chúng cũng được thực hiện ở máy khách. Kiểm tra phía máy khách vẫn hữu ích cho phản hồi, phát hiện dấu hiệu xâm nhập và giảm lỗi vô ý, nhưng không thể tự bảo vệ máy chủ.

Triển khai:

Giả định mọi đầu vào đều có thể độc hại và ưu tiên chiến lược allowlist, tức “chấp nhận giá trị đã biết là hợp lệ”. Kiểm tra độ dài, kiểu, toàn bộ phạm vi giá trị, trường thiếu hoặc thừa, cú pháp, tính nhất quán giữa các trường và quy tắc nghiệp vụ. Denylist có thể hỗ trợ phát hiện hoặc loại bỏ đầu vào rõ ràng sai định dạng, nhưng không nên là biện pháp phòng vệ duy nhất.
Xác thực sau khi ghép các giá trị từ nhiều nguồn, vì các phần tử hợp lệ riêng lẻ có thể vi phạm giới hạn khi kết hợp.
Xác thực cẩn thận tại ranh giới ngôn ngữ, bao gồm lời gọi từ mã thông dịch sang mã native.
Chuyển đổi trực tiếp đầu vào sang kiểu mong đợi, sau đó kiểm tra phạm vi cho phép và tính nhất quán với các trường liên quan.
Giải mã và chuẩn hóa đầu vào về biểu diễn nội bộ của ứng dụng trước khi xác thực, tránh giải mã lặp ngoài ý muốn và sử dụng các cơ chế chuẩn hóa như OWASP ESAPI Canonicalization control.
Dùng cùng một mã hóa ký tự giữa các thành phần giao tiếp và nêu rõ mã hóa khi giao thức cho phép.

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

Giảm bề mặt tấn công · Kiến trúc và thiết kếConsider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
Thư viện hoặc framework · Kiến trúc và thiết kếUse an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
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 the product, including but not limited to: 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.
Kiểm tra dữ liệu đầu vào · Hiện thực hóa · Hiệu quả: CaoAssume 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.
Kiến trúc và thiết kếFor any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Hiện thực hóaWhen your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.
Hiện thực hóaBe especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.
Hiện thực hóaDirectly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.
Hiện thực hóaInputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
Hiện thực hóaWhen exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

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

Nên kết hợp nhiều phương pháp vì không phương pháp đơn lẻ nào bao phủ được mọi quy tắc xác thực. Phân tích tĩnh tự động có thể tìm các vị trí thiếu phương thức hoặc framework xác thực đã được nhận diện, nhưng có thể tạo cảnh báo sai khi không hiểu được cơ chế xác thực tùy chỉnh. Phân tích tĩnh thủ công cần thiết cho các quy tắc tùy chỉnh, đặc biệt là logic nghiệp vụ.

Fuzzing nên cung cấp đầu vào bất thường và kiểm tra rằng ứng dụng vẫn ổn định, trả về lỗi do ứng dụng kiểm soát thay vì treo, phát sinh ngoại lệ hoặc thông báo do trình thông dịch tạo ra. Bản ghi cũng nêu phân tích mã nhị phân hoặc bytecode và disassembler, trình quét ứng dụng web, dịch vụ web và cơ sở dữ liệu, trình fuzzing và framework-based fuzzer, quét giao diện ứng dụng, môi trường ảo được giám sát, kiểm tra thủ công tập trung, rà soát mã nguồn, công cụ phân tích điểm yếu mã nguồn, inspection, phương pháp hình thức và mô hình hóa tấn công. Các phương pháp mã nhị phân, bytecode và phương pháp chỉ bao phủ một phần được SOAR liệt kê không bảo đảm bao phủ đầy đủ.

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 tự động	Some instances of improper input validation can be detected using automated static analysis. A static analysis tool might allow the user to specify which application-specific methods or functions perform input validation; the tool might also have built-in knowledge of validation frameworks such as Struts. The tool may then suppress or de-prioritize any associated warnings. This allows the analyst to focus on areas of the software in which input validation does not appear to be present. Except in the cases described in the previous paragraph, automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.	-
Phân tích tĩnh thủ công	When custom input validation is required, such as when enforcing business rules, manual analysis is necessary to ensure that the validation is properly implemented.	-
Kiểm thử fuzzing	Fuzzing techniques can be useful for detecting input validation errors. When unexpected inputs are provided to the software, the software should not crash or otherwise become unstable, and it should generate application-controlled error messages. If exceptions or interpreter-generated error messages occur, this indicates that the input was not detected and handled within the application logic itself.	-
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: ``` Cost effective for partial coverage: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis	SOAR một phần
Phân tích tĩnh tệp nhị phân hoặc bytecode thủ công	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies	SOAR một phần
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 ``` Cost effective for partial coverage: ``` Host Application Interface Scanner Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious	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: ``` Focused Manual Spotcheck - Focused manual analysis of source 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: ``` Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.) Formal Methods / Correct-By-Construction ``` Cost effective for partial coverage: ``` Attack Modeling	Cao

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

Bản ghi chính thức cung cấp các ví dụ đại diện sau, không phải danh sách đầy đủ. Các ví dụ gồm:

CVE-2024-37032: định dạng digest không được xác thực đã cho phép directory traversal tương đối trong công cụ quản lý LLM.
CVE-2022-45918: đường dẫn được xác thực không đúng đã cho phép traversal bằng chuỗi ../.
CVE-2021-30860 và CVE-2021-30663: xác thực đầu vào không đúng dẫn đến tràn số nguyên.
CVE-2021-22205: vượt qua bước xác thực bằng dấu gạch chéo ngược theo sau bởi dòng mới, dẫn đến eval injection.
CVE-2021-21220: xác thực không đầy đủ dẫn đến hỏng heap.
CVE-2020-9054, CVE-2008-5305 và CVE-2008-1625: xác thực không đầy đủ cho phép injection lệnh hoặc eval và thực thi mã.
CVE-2020-3452, CVE-2008-1284 và CVE-2008-3660: lỗi xác thực góp phần gây directory traversal.
CVE-2020-3580, CVE-2008-3843 và CVE-2008-2223: lỗi xác thực góp phần gây XSS hoặc SQL injection.
Các ví dụ khác trong bản ghi liên quan đến trường gói tin sai hoặc không nhất quán, tham số bị thiếu, giá trị có độ dài bằng không, phiên bản không hợp lệ, vòng lặp vô hạn, sự cố, lộ thông tin, đọc vượt hoặc hỏng bộ nhớ, tiêu thụ tài nguyên, HTTP response smuggling, vượt qua cơ chế bảo mật và thực thi mã.

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-20, dựa theo mức độ ưu tiên

Nguồn (2)

MITRE CWE

CWE Terms of Use

CWE-20: Xác thực đầu vào không đúng cách

CWE-20 là gì?

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

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

Đị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

Tài liệu bổ trợ

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

Tìm hiểu các tài nguyên khác từ CyStack

Báo cáo độ an toàn trang Web

Nghiên cứu của CyStack

Kiến thức về An ninh mạng