Nhầm lẫn selector và HTML trong jQuery cho phép Cross-site Scripting

jQuery trước phiên bản 1.9.0 dễ bị tấn công Cross-site Scripting (XSS). Hàm jQuery(strInput) không phân biệt selector với HTML một cách đáng tin cậy. Trong các phiên bản bị ảnh hưởng, jQuery xác định đầu vào có phải là HTML hay không bằng cách tìm ký tự "<" ở bất kỳ vị trí nào trong chuỗi, giúp kẻ tấn công linh hoạt hơn khi xây dựng payload độc hại. Trong các phiên bản đã sửa, jQuery chỉ coi đầu vào là HTML nếu đầu vào bắt đầu rõ ràng bằng ký tự "<", từ đó giới hạn khả năng khai thác vào những kẻ tấn công có thể kiểm soát phần đầu của chuỗi, một trường hợp ít phổ biến hơn nhiều.

• jQuery core: Bản ghi xác định jQuery trước 1.9.0 là bị ảnh hưởng. Bug tracker của dự án gắn lỗi với thành phần core và mốc sửa trong nhánh 1.9; bản sửa được mô tả là thay đổi nhận diện HTML để chuỗi phải bắt đầu bằng <.
• Package npm jquery: Advisory của Snyk dành cho package npm sử dụng ranh giới rộng hơn, đánh dấu các bản <1.9.1 là bị ảnh hưởng và hướng dẫn nâng cấp lên 1.9.1 hoặc cao hơn. Đây là ranh giới theo package, không nên tự động đồng nhất với ranh giới jQuery core trong bản ghi.
• Package RubyGems jquery-rails: Advisory downstream xác định các bản >=2.0.1 và <2.2.0 là bị ảnh hưởng, với mốc sửa 2.2.0 hoặc cao hơn theo hướng dẫn của advisory đó.
• Các bản đóng gói khác: Bản ghi và các advisory được kiểm tra không cung cấp một ranh giới duy nhất cho mọi bản phân phối, bản backport của nhà cung cấp hoặc sản phẩm tích hợp. Cần xác minh theo package và sản phẩm thực tế thay vì coi một mốc sửa của nhánh này là bằng chứng cho mọi nhánh khác.

Thành phần bị ảnh hưởng là logic khởi tạo của jQuery, cụ thể là lời gọi jQuery(strInput) dùng để phân biệt CSS selector với chuỗi HTML. Trong các bản bị ảnh hưởng, biểu thức nhận diện HTML có thể tìm thấy ký tự < ở bất kỳ vị trí nào trong chuỗi, kể cả khi ký tự này nằm bên trong một selector hoặc dữ liệu khác. Điều này khiến đầu vào do kẻ tấn công kiểm soát có thể bị diễn giải như HTML thay vì selector, tạo điều kiện cho Cross-site Scripting trong ứng dụng sử dụng kết quả đó.

Bản sửa đổi thay đổi quy tắc nhận diện để nhánh HTML chỉ khớp khi chuỗi bắt đầu bằng <; thay đổi này được gắn với thành phần core và vấn đề selector được diễn giải thành HTML. Điều kiện khai thác là ứng dụng phải đưa dữ liệu do kẻ tấn công kiểm soát vào jQuery(strInput), đồng thời nạn nhân phải thực hiện luồng trình duyệt liên quan. Bằng chứng hiện có không xác định sink cụ thể của từng ứng dụng, payload hoàn chỉnh, hay cấu hình trình duyệt và ứng dụng cụ thể.

Lỗ hổng có thể được tiếp cận qua mạng khi một ứng dụng web nhận dữ liệu do kẻ tấn công kiểm soát và truyền dữ liệu đó vào jQuery(strInput). Bản ghi đánh giá điều kiện là không cần quyền xác thực, độ phức tạp thấp và cần tương tác của người dùng, vì trình duyệt của nạn nhân phải xử lý luồng bị ảnh hưởng.

Bản ghi đánh dấu đã có public exploit, và advisory của Snyk cho biết có proof of concept hoặc phần giải thích khai thác chi tiết. Bằng chứng được cung cấp không xác nhận một chiến dịch đang hoạt động, nạn nhân cụ thể, hay việc khai thác thực tế trong môi trường của tổ chức. Không nên xem việc thiếu thông tin quan sát được trong bản ghi là bằng chứng rằng chưa từng có khai thác.

Khi khai thác thành công, đầu vào được xử lý trong trình duyệt có thể bị diễn giải theo cách cho phép thực thi JavaScript trong phạm vi ứng dụng web bị ảnh hưởng. Điều này có thể ảnh hưởng đến tính bí mật và toàn vẹn của dữ liệu mà origin hoặc phiên người dùng có quyền truy cập, phù hợp với việc bản ghi mô tả tác động confidentiality và integrity ở mức giới hạn.

Lỗ hổng không được xác định là gây ảnh hưởng trực tiếp đến tính sẵn sàng. Điều kiện cần gồm một luồng ứng dụng truyền dữ liệu do kẻ tấn công kiểm soát vào jQuery(strInput) và một người dùng xử lý luồng đó trong trình duyệt. Phạm vi cuối cùng, dữ liệu có thể truy cập và hành động có thể thực hiện phụ thuộc vào quyền người dùng, origin, kiểm soát ứng dụng và các cơ chế phòng vệ khác; những chi tiết này chưa được xác định chung trong bằng chứng hiện có.

Một ứng dụng web còn dùng bản jQuery bị ảnh hưởng có thể cho phép script không được tin cậy chạy trong ngữ cảnh của origin ứng dụng khi các điều kiện khai thác phù hợp. Hệ quả có thể gồm đọc hoặc thay đổi dữ liệu mà phiên trình duyệt được phép truy cập, thay đổi giao diện và luồng thao tác, hoặc thực hiện hành động thay mặt người dùng, nhưng phạm vi cụ thể phụ thuộc vào quyền của tài khoản và thiết kế ứng dụng.

Lỗ hổng không được mô tả là gây mất sẵn sàng trực tiếp. Rủi ro vận hành lớn nhất là các bản jQuery cũ thường nằm trong asset đã bundle hoặc trong sản phẩm downstream, khiến việc nhận diện bản thực tế và kiểm tra các luồng đầu vào trở nên quan trọng. Bản ghi không cung cấp bằng chứng về một vụ rò rỉ dữ liệu hoặc xâm nhập cụ thể, nên không nên diễn giải lỗ hổng như bằng chứng rằng một tổ chức đã bị xâm phạm.

1. Nâng cấp jQuery core lên 1.9.0, là mốc sửa được bản ghi và lịch sử lỗi của dự án xác nhận cho thay đổi nhận diện selector và HTML. Với package npm jquery, áp dụng hướng dẫn package-specific của Snyk là nâng cấp lên 1.9.1 hoặc cao hơn; không giả định rằng 1.9.0 đủ cho mọi cách đóng gói.
2. Nếu sử dụng jquery-rails, nâng cấp khỏi nhánh bị ảnh hưởng theo hướng dẫn của advisory package, cụ thể là dùng 2.2.0 hoặc cao hơn. Kiểm tra lockfile và asset đã bundle để bảo đảm ứng dụng thực sự đang dùng bản đã sửa.
3. Rà soát và sửa các luồng đưa dữ liệu không tin cậy vào jQuery(strInput). Khi ứng dụng thực sự cần parse HTML, dùng API hoặc cách parse HTML rõ ràng theo thiết kế của ứng dụng, đồng thời kiểm tra lại việc xử lý và trung hòa dữ liệu; thay đổi API mà không kiểm tra compatibility không được xem là biện pháp hoàn chỉnh.
4. Sau khi nâng cấp, chạy kiểm thử hồi quy cho selector có chứa ký tự < không nằm ở đầu chuỗi, dữ liệu người dùng và các template HTML hiện có. Xác nhận rằng ứng dụng không còn phụ thuộc vào hành vi nhận diện cũ.
5. Nếu chưa thể nâng cấp ngay, cô lập các luồng sử dụng jQuery cũ, giảm dữ liệu không tin cậy đi vào constructor và ưu tiên thay thế asset trong bản phát hành gần nhất. Đây chỉ là biện pháp giảm rủi ro tạm thời, không thay thế việc nâng cấp hoặc áp dụng bản sửa của nhà cung cấp.

1. Kiểm kê mọi bản sao jQuery được nhúng trực tiếp, đóng gói trong bundle, hoặc kéo theo từ dependency. Xác định phiên bản từ manifest, lockfile, metadata của package, banner trong tệp JavaScript và nội dung thực tế của asset đã triển khai.
2. Kiểm tra riêng package jquery, các bản jQuery core được bundle, và các wrapper hoặc downstream package như jquery-rails nếu tổ chức sử dụng chúng. Không suy luận trạng thái an toàn chỉ từ tên tệp hoặc kết quả scanner khi chưa xác minh phiên bản thực tế.
3. Tìm các luồng gọi jQuery(strInput) hoặc tương đương trong đó chuỗi đầu vào có thể bắt nguồn từ tham số HTTP, fragment, query string, dữ liệu người dùng, nội dung API hoặc dữ liệu do bên thứ ba cung cấp. Ưu tiên các luồng đưa chuỗi chứa ký tự < vào vị trí không bắt đầu chuỗi.
4. Đối chiếu từng nhánh package với ranh giới affected và fixed tương ứng, vì advisory cho các hệ sinh thái khác nhau có thể dùng mốc phiên bản khác nhau.
5. Có thể rà soát telemetry trình duyệt và cảnh báo Content Security Policy như một biện pháp phòng ngừa để tìm hành vi script bất thường. Bằng chứng hiện có không cung cấp IOC hoặc mẫu log đặc thù cho lỗ hổng này, và việc không thấy log không chứng minh hệ thống an toàn.