Lỗi Server-Side Request Forgery trong Angular SSR do phân giải URL độc hại

Lưu ý: Dữ liệu này chỉ có tính chất tham khảo, phục vụ nghiên cứu an ninh mạng.CyStack khuyến nghị người dùng không sử dụng các thông tin này nhằm các mục đích bất hợp pháp

Lỗ hổng CVE-2025-62427 là gì?

Lỗ hổng CVE-2025-62427 là lỗ hổng Server-Side Request Forgery (SSRF) ảnh hưởng tới angular-cli (phiên bản bị ảnh hưởng: >=19.0.0-next.0, < 19.2.18, >=20.0.0-next.0, < 20.3.6 và các phiên bản bị ảnh hưởng khác). Lỗ hổng này được xếp hạng ở mức Cao, với điểm CVSS 8.7. Lỗ hổng này đã có mã hoặc bằng chứng khai thác công khai, nhưng điều đó chưa xác nhận việc khai thác trong thực tế.

Giới thiệu chung

Dữ liệu gốc

Angular SSR là một công cụ kết xuất phía máy chủ cho các ứng dụng Angular. Lỗ hổng là lỗi Server-Side Request Forgery (SSRF) trong cơ chế phân giải URL của package Server-Side Rendering của Angular (@angular/ssr), trước 19.2.18, 20.3.6 và 21.0.0-next.8. Hàm createRequestUrl sử dụng native URL constructor. Khi path của request đầu vào, chẳng hạn originalUrl hoặc url, bắt đầu bằng hai dấu gạch chéo xuôi (//) hoặc backslash (\), URL constructor sẽ xử lý nó như một schema-relative URL. Hành vi này ghi đè base URL được cung cấp làm đối số thứ hai vì mục đích bảo mật, gồm protocol, host và port, rồi phân giải URL theo scheme của base URL nhưng sử dụng hostname do kẻ tấn công kiểm soát. Điều này cho phép kẻ tấn công chỉ định một domain bên ngoài trong URL path, lừa môi trường Angular SSR đặt virtual location của trang, có thể truy cập qua các token DOCUMENT hoặc PlatformLocation, thành domain do kẻ tấn công kiểm soát. Mọi HTTP request tương đối tiếp theo được thực hiện trong quá trình SSR, chẳng hạn bằng HttpClient.get('assets/data.json'), sẽ bị phân giải sai đến domain của kẻ tấn công, buộc server giao tiếp với một endpoint bên ngoài tùy ý. Lỗ hổng này được sửa trong 19.2.18, 20.3.6 và 21.0.0-next.8.

Sản phẩm và phạm vi ảnh hưởng

Bản ghi chuẩn hóa xác định vendor angular, product angular-cli, còn advisory của vendor xác định package bị lỗi là @angular/ssr.

  • Nhánh >=19.0.0-next.0, <19.2.18 bị ảnh hưởng. Bản sửa tương ứng là 19.2.18.
  • Nhánh >=20.0.0-next.0, <20.3.6 bị ảnh hưởng. Bản sửa tương ứng là 20.3.6.
  • Nhánh >=21.0.0-next.0, <21.0.0-next.8 bị ảnh hưởng. Bản sửa tương ứng là 21.0.0-next.8.

Các giới hạn trên áp dụng cho package @angular/ssr; trạng thái của các nhánh khác không được suy ra ngoài phạm vi bằng chứng này.

Chi tiết kỹ thuật

Lỗi nằm trong cơ chế tạo URL của package @angular/ssr, cụ thể là hàm createRequestUrl. Hàm này dùng native URL constructor với protocol, hostname và port của request làm base URL, nhưng giá trị từ originalUrl hoặc url bắt đầu bằng // hoặc backslash lại được xử lý như một schema-relative URL. Khi đó, hostname do kẻ tấn công kiểm soát có thể ghi đè hostname trong base URL, trong khi vẫn sử dụng scheme của base URL. Angular SSR sau đó đặt virtual location của trang, có thể truy cập qua các token DOCUMENT hoặc PlatformLocation, thành domain do kẻ tấn công chỉ định. Những HTTP request tương đối phát sinh trong quá trình SSR, chẳng hạn HttpClient.get('assets/data.json'), có thể được phân giải đến domain đó thay vì máy chủ dự kiến. Điều kiện khai thác là ứng dụng Angular SSR phải nhận request do kẻ tấn công kiểm soát và thực hiện request tương đối trong quá trình render; bằng chứng hiện có không xác định các request cụ thể, credential hoặc đích mạng nào sẽ có thể truy cập trong từng deployment.

Khả năng khai thác

Lỗ hổng có thể bị kích hoạt qua network bằng cách gửi request đến endpoint Angular SSR có đường dẫn được tạo phù hợp. Theo các thuộc tính khai thác trong bản ghi, attacker không cần authentication và không cần user interaction; độ phức tạp được đánh giá là thấp. Việc khai thác thành công còn phụ thuộc vào việc ứng dụng thực hiện các HTTP request tương đối trong quá trình server-side rendering. Bản ghi đánh dấu rằng public exploit tồn tại, nhưng không nêu tên exploit cụ thể. Bản ghi không xác định một campaign, nạn nhân, hoặc chỉ dấu khai thác cụ thể nào.

Tác động kỹ thuật

Khai thác thành công làm thay đổi virtual location mà Angular SSR sử dụng để phân giải URL tương đối, từ đó khiến server gửi HTTP request đến hostname do attacker kiểm soát. Hậu quả kỹ thuật chính là SSRF và khả năng tiết lộ dữ liệu mà tiến trình SSR có thể đưa vào request hoặc nhận từ response. Attacker không cần có tài khoản và không cần người dùng khác tương tác, nhưng deployment phải có endpoint SSR có thể truy cập và phải phát sinh request tương đối trong lúc render. Quyền truy cập đến mạng nội bộ, credential hoặc tài nguyên đặc quyền phụ thuộc vào cấu hình ứng dụng và egress policy, không được bản ghi xác nhận. Bản ghi không mô tả khả năng thực thi mã, sửa đổi dữ liệu hoặc làm gián đoạn dịch vụ như hậu quả trực tiếp.

Tác động đến tổ chức

Lỗi có thể làm server SSR gửi request đến một endpoint bên ngoài do kẻ tấn công chọn thay vì endpoint mà ứng dụng dự kiến.

  • Dữ liệu mà SSR đưa vào request hoặc nhận từ endpoint bên ngoài có thể bị tiết lộ nếu ứng dụng đưa dữ liệu đó vào response, log hoặc một luồng xử lý khác.
  • Hệ thống có thể phát sinh outbound traffic, DNS lookup và kết nối HTTP ngoài dự kiến, gây khó khăn cho kiểm soát egress và phân tích sự cố.
  • Phạm vi dữ liệu bị ảnh hưởng phụ thuộc vào các request tương đối mà ứng dụng thực hiện trong quá trình render và chính sách mạng của deployment.
  • Bằng chứng hiện có không xác định việc truy cập được các endpoint nội bộ, credential cụ thể, thay đổi dữ liệu hoặc gián đoạn dịch vụ.

Cách khắc phục

  1. Nâng cấp @angular/ssr lên bản sửa đúng với nhánh đang sử dụng: 19.2.18 cho nhánh 19, 20.3.6 cho nhánh 20, hoặc 21.0.0-next.8 cho nhánh 21 prerelease. Xác nhận lockfile, artifact build và image runtime đều dùng bản đã sửa.
  2. Nếu chưa thể nâng cấp, thêm middleware trước Angular SSR handler trên Node.js hoặc Express để reject hoặc sanitize request path bắt đầu bằng //. Logic bảo vệ cũng cần ngăn path được diễn giải thành schema-relative URL, bao gồm các dạng backslash được mô tả trong cơ chế lỗi.
  3. Rà soát cấu hình reverse proxy và framework adapter để bảo đảm chúng không khôi phục hoặc truyền nguyên các path nguy hiểm vào originalUrl hoặc url sau lớp middleware.
  4. Sau khi sửa, kiểm tra rằng virtual location của SSR vẫn giữ hostname dự kiến và các relative HTTP request trong quá trình render không thể chuyển sang hostname do request cung cấp.

Cách phát hiện

  1. Kiểm kê các ứng dụng Angular có bật server-side rendering và xác định package @angular/ssr được cài đặt trực tiếp hoặc gián tiếp.
  2. Đối chiếu phiên bản package trong lockfile, image container và thư mục runtime với các nhánh bị ảnh hưởng và các bản đã sửa được nêu trong affected_summary.
  3. Rà soát code SSR để tìm việc sử dụng DOCUMENT, PlatformLocation, HttpClient hoặc các cơ chế khác tạo HTTP request tương đối trong lúc render.
  4. Kiểm tra access log và proxy log để tìm request path bắt đầu bằng // hoặc backslash, đồng thời kiểm tra outbound DNS và HTTP telemetry của SSR để phát hiện hostname bên ngoài không nằm trong allowlist dự kiến.
  5. Việc không thấy log bất thường không chứng minh hệ thống an toàn; các kiểm tra outbound ở trên là biện pháp giám sát phòng ngừa, không phải IOC đã được xác nhận cho lỗ hổng này.
Nguồn (13)
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.