CWE-113: Vô hiệu hóa không đúng các chuỗi CRLF trong tiêu đề HTTP

CWE-113 là gì?

CWE-113 là Vô hiệu hóa không đúng các chuỗi CRLF trong tiêu đề HTTP. Lỗi phát sinh khi Sản phẩm nhận dữ liệu từ một tác nhân hoặc thành phần HTTP nhưng không vô hiệu hóa, hoặc vô hiệu hóa không đúng, các ký tự CR và LF trước khi đưa dữ liệu vào tiêu đề HTTP gửi đi. Hiện có 43 lỗ hổng trong kho dữ liệu liên quan đến CWE-113 và không có lỗ hổng nào nằm trong danh mục khai thác thực tế của CISA.

THỨ HẠNG OWASP TOP 10:20255 — A05:2025 — Injection
Tổng số CVE liên quan (365 ngày)43
Mức trừu tượngBiến thể
Khả năng khai thác-

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

43 lỗ hổngTăng 617% so với cùng kỳ

Không có dữ liệu

Chưa có dữ liệu về lỗ hổng trong CISA KEV cho CWE-113

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

TheoMitre CWE

Chi tiết kỹ thuật

Các thành phần HTTP như máy chủ web, bộ cân bằng tải, proxy ngược, proxy bộ nhớ đệm, tường lửa ứng dụng và trình duyệt cần duy trì trạng thái giao tiếp nhất quán giữa các thành phần. Khi dữ liệu bất ngờ được đưa vào tiêu đề, tác nhân HTTP phía máy khách hoặc phía máy chủ có thể diễn giải thông điệp theo cách khác với ý định của ứng dụng.

Nếu yêu cầu HTTP chứa các ký tự CR và LF bất ngờ, luồng đầu ra có thể bị tách thành hai thông điệp HTTP thay vì một. CR là carriage return, có thể được biểu diễn bằng %0d hoặc \r; LF là line feed, có thể được biểu diễn bằng %0a hoặc \n. Ngoài ra, các ký tự đặc biệt hợp lệ theo RFC và các cách mã hóa riêng, như HT được biểu diễn bằng %09 hoặc \t, và SP được biểu diễn bằng dấu cộng hoặc %20, cũng có thể ảnh hưởng đến cách dữ liệu được diễn giải.

Khi thông điệp thứ hai sau khi tách nằm dưới sự kiểm soát của kẻ tấn công, dữ liệu này có thể được dùng để thực hiện các cuộc tấn công như giả mạo yêu cầu phía máy chủ, cross-site scripting hoặc đầu độc bộ nhớ đệm.

Đặc điểm

Điểm yếu này thường xuất hiện trong các thành phần web hoặc không phụ thuộc ngôn ngữ, bao gồm máy chủ web và các tác nhân trung gian HTTP. Dữ liệu từ nguồn không tin cậy được đưa vào tiêu đề HTTP mà không được xử lý đúng, đặc biệt khi chứa CR hoặc LF. Các tên gọi liên quan gồm HTTP request splitting và HTTP response splitting; vấn đề có thể ảnh hưởng đến cả thông điệp yêu cầu và thông điệp phản hồi.

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

Các ký tự CR và LF trong tiêu đề HTTP có thể cho phép kẻ tấn công kiểm soát các tiêu đề và phần thân còn lại của thông điệp mà ứng dụng định gửi hoặc nhận, hoặc tạo thêm các thông điệp hoàn toàn dưới quyền kiểm soát của chúng. Các tác động được ghi nhận gồm sửa đổi dữ liệu ứng dụng và đạt được đặc quyền hoặc giả danh một danh tính khác. Hành vi tách thông điệp cũng có thể hỗ trợ giả mạo yêu cầu phía máy chủ, cross-site scripting hoặc đầu độc bộ nhớ đệm.

Dữ liệu MITRE CWE chính thức
Tác độngPhạm viDiễn giải
Thay đổi dữ liệu ứng dụng, Chiếm đặc quyền hoặc mạo danhTính toàn vẹn, Kiểm soát truy cậpCR and LF characters in an HTTP header may give attackers control of the remaining headers and body of the message that the application intends to send/receive, as well as allowing them to create additional messages entirely under their control.

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

Xây dựng tiêu đề an toàn: Tạo tiêu đề HTTP một cách cẩn trọng và tránh đưa dữ liệu đầu vào chưa được kiểm tra vào tiêu đề.

Xác thực theo allowlist: Coi mọi dữ liệu đầu vào là có khả năng độc hại. Sử dụng danh sách giá trị được chấp nhận, tuân thủ nghiêm ngặt đặc tả; xem xét độ dài, kiểu, toàn bộ miền giá trị, trường bị thiếu hoặc thừa, cú pháp, tính nhất quán giữa các trường liên quan và quy tắc nghiệp vụ. Từ chối hoặc chuyển đổi dữ liệu không phù hợp. Không chỉ tìm các chuỗi độc hại hoặc sai định dạng, vì cách này có thể bỏ sót dữ liệu không mong muốn; denylist vẫn có thể hỗ trợ phát hiện hoặc loại bỏ dữ liệu sai nghiêm trọng.

Chuẩn hóa trước khi kiểm tra: Giải mã và chuẩn hóa đầu vào về biểu diễn nội bộ hiện tại của ứng dụng trước khi xác thực. Không giải mã cùng một đầu vào nhiều lần, vì điều đó có thể làm xuất hiện dữ liệu nguy hiểm sau khi bước kiểm tra đã hoàn tất.

Đồng nhất mã hóa đầu ra: Chỉ định một kiểu mã hóa mà thành phần nhận phía sau có thể xử lý, chẳng hạn ISO-8859-1, UTF-7 hoặc UTF-8, và duy trì cách hiểu nhất quán về mã hóa giữa các thành phần. Sự không nhất quán có thể khiến thành phần phía sau diễn giải một số ký tự hoặc chuỗi byte như ký tự đặc biệt.

Dữ liệu MITRE CWE chính thức
  1. Kiểm tra dữ liệu đầu vào · Hiện thực hóaConstruct HTTP headers very carefully, avoiding the use of non-validated input data.
  2. 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. If an input does not strictly conform to specifications, reject it or transform it into something that conforms. 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.
  3. Mã hóa ký tự đầu ra · Hiện thực hóaUse and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.
  4. Kiểm tra dữ liệu đầu vào · Hiện thực hóaInputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

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

Phân tích tĩnh tự động, còn gọi là SAST, có thể phát hiện một số trường hợp bằng cách lập mô hình luồng dữ liệu và luồng điều khiển trong mã nguồn hoặc mã đã biên dịch. Phương pháp này tìm các đường đi từ nguồn dữ liệu đầu vào đến các đích mà dữ liệu tương tác với thành phần bên ngoài hoặc tầng thấp hơn, nhưng không nhất thiết phát hiện mọi trường hợp phụ thuộc vào hành vi thời gian chạy hoặc cấu hình của thành phần HTTP.

Dữ liệu MITRE CWE chính thức
Phương phápCách làmHiệu quả
Phân tích tĩnh tự độngAutomated 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

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

Các ví dụ sau là những trường hợp tiêu biểu được hồ sơ chính thức tuyển chọn, không phải danh sách đầy đủ:

  • CVE-2020-15811: Proxy tìm kiếm chuỗi con thay vì phân tích tiêu đề Transfer-Encoding, dẫn đến request splitting và cache poisoning.
  • CVE-2021-41084: Giao diện HTTP dựa trên Scala cho phép request splitting và response splitting qua tên tiêu đề, giá trị tiêu đề, lý do trạng thái và URI.
  • CVE-2018-12116: Framework dựa trên JavaScript cho phép request splitting thông qua tùy chọn đường dẫn của một yêu cầu HTTP.
  • CVE-2004-2146: Ứng dụng chấp nhận CRLF trong mã định danh đối tượng, cho phép HTTP response splitting.
  • CVE-2004-1656: Ứng dụng giỏ hàng cho phép HTTP response splitting và chèn HTML thông qua CRLF trong một tham số URL.
  • CVE-2005-2060: Bảng tin cho phép response splitting thông qua CRLF trong tham số.
  • CVE-2004-2512: Có thể thực hiện response splitting thông qua PHPSESSID.
  • CVE-2005-1951: Ứng dụng thương mại điện tử cho phép response splitting bằng CRLF trong các tham số mã định danh đối tượ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-113, dựa theo mức độ ưu tiên

Nguồn (2)
MITRE CWE
CWE Terms of Use

Tài liệu bổ trợ

CWE™ Program, operated by The MITRE Corporation. Copyright © 2006–2026, The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. CWE Terms of Use.

Tìm hiểu thêm

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

Giải pháp CyStack VulnScan liên tục phát hiện tài sản, xác minh lỗ hổng và giúp đội ngũ bảo mật ưu tiên khắc phục cho toàn bộ doanh nghiệp.

Khám phá CyStack VulnScan
Tài nguyên & Thông tin khác

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

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

Đánh giá mức độ an toàn và các đề xuất tới từ CyStack cho các trang Web

Xem thêm

Nghiên cứu của CyStack

Tìm hiểu các nghiên cứu của đội ngũ chuyên gia chúng tôi trong an ninh mạng

Xem thêm

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

Tìm hiểu về giải pháp tình báo mối đe doạ và phát hiện lộ lọt dữ liệu tới từ CyStack

Xem thêm