SSRF và làm lộ credential xuyên origin trong Angular @angular/platform-server do sai lệch xử lý URL

Angular là một nền tảng phát triển để xây dựng các ứng dụng web cho thiết bị di động và máy tính để bàn bằng TypeScript/JavaScript cùng các ngôn ngữ khác. Trước các phiên bản 20.3.30, 21.2.22 và 22.1.4, Angular Server-Side Rendering trong @angular/platform-server xử lý các resource URL hoặc request URL do người dùng kiểm soát thông qua HttpClient sau khi code của ứng dụng xác thực chúng bằng WHATWG URL parsing. Các utility resolveUrl và parseUrl đã gọi String.prototype.trim(), loại bỏ Unicode whitespace ở đầu như U+00A0 hoặc U+FEFF sau khi input vượt qua kiểm tra same-origin, qua đó biến relative path thành protocol-relative URL do attacker kiểm soát. Trong các ứng dụng có gắn credential nhạy cảm phía máy chủ như Authorization header vào các request được phê duyệt, relativeUrlsTransformerInterceptorFn sau đó gửi request đến origin do attacker kiểm soát, gây SSRF và làm lộ credential. Vấn đề này đã được sửa trong các phiên bản 20.3.30, 21.2.22 và 22.1.4.

Lỗ hổng ảnh hưởng đến Angular Server-Side Rendering trong package @angular/platform-server theo các nhánh sau:

• <= 19.2.25: bị ảnh hưởng. CNA advisory đánh dấu nhánh này đã hết hỗ trợ/LTS và sẽ không được vá.
• >= 20.0.0, < 20.3.30: bị ảnh hưởng; bản sửa được xác nhận là 20.3.30.
• >= 21.0.0, < 21.2.22: bị ảnh hưởng; bản sửa được xác nhận là 21.2.22.
• >= 22.0.0, < 22.1.4: bị ảnh hưởng; bản sửa được xác nhận là 22.1.4.

Các phiên bản nằm ngoài những phạm vi được nêu rõ ở trên chưa được xác định trong hồ sơ này.

Lỗi nằm trong cơ chế phân giải URL của @angular/platform-server, cụ thể là các tiện ích resolveUrl và parseUrl, và được phân loại là CWE-918. Ứng dụng có thể dùng WHATWG URL parsing để kiểm tra rằng URL do người dùng kiểm soát vẫn cùng origin với origin tin cậy, trong khi String.prototype.trim() của Angular lại loại bỏ Unicode whitespace ở đầu chuỗi, chẳng hạn U+00A0 hoặc U+FEFF. Sự khác biệt này có thể biến một relative path đã vượt qua kiểm tra thành một protocol-relative URL trỏ đến origin do kẻ tấn công kiểm soát. Trong quá trình SSR, relativeUrlsTransformerInterceptorFn sau đó có thể gửi request qua HttpClient đến origin này. Điều kiện khai thác là input phải ảnh hưởng đến resource hoặc request URL, ứng dụng phải thực hiện kiểm tra same-origin trước khi gửi request, và request được phép mang credential nhạy cảm phía máy chủ như API key, Bearer token hoặc Authorization header. Các route cụ thể của ứng dụng và phạm vi quyền của credential bị ảnh hưởng phụ thuộc vào từng deployment và không được xác định trong hồ sơ.

Lỗi có thể bị khai thác qua mạng khi một ứng dụng Angular SSR xử lý URL do người dùng kiểm soát theo luồng nêu trên. Hồ sơ mô tả rằng attacker không cần xác thực trước và attack complexity thấp, nhưng request SSR hoặc quy trình xử lý tương ứng phải được kích hoạt. User interaction được mô tả là passive, nghĩa là nạn nhân không nhất thiết phải thực hiện một thao tác bảo mật riêng ngoài việc ứng dụng xử lý request. CNA advisory có công bố một proof of concept cho cơ chế bypass same-origin và chuyển request sang origin khác. Bằng chứng được cung cấp không xác nhận một campaign hoặc hoạt động khai thác cụ thể ngoài thực tế.

• Kết quả kỹ thuật chính là bypass kiểm tra same-origin và SSRF từ tiến trình Angular SSR đến một origin do attacker kiểm soát.
• Nếu request đã được gắn credential, credential đó có thể bị tiết lộ; attacker sau đó có thể sử dụng quyền của credential trong phạm vi mà hệ thống đích chấp nhận.
• Ảnh hưởng đến confidentiality là rõ ràng đối với credential được gửi nhầm. Ảnh hưởng đến integrity là khả dĩ nếu credential cho phép thay đổi dữ liệu hoặc thực hiện hành động, nhưng phụ thuộc vào quyền cụ thể.
• Hồ sơ không mô tả arbitrary code execution hoặc một cơ chế trực tiếp gây mất availability. Các ứng dụng Angular phía client không dùng SSR và không có luồng request thỏa các điều kiện nêu trên không thuộc phạm vi được xác nhận.

• Máy chủ SSR có thể gửi request đến origin không được ứng dụng dự định, làm suy yếu kiểm soát outbound request và domain allowlist ở tầng ứng dụng.
• Authorization header, API key, Bearer token hoặc credential tương tự có thể bị gửi đến origin do attacker kiểm soát nếu chúng được thêm sau bước kiểm tra same-origin.
• Credential bị lộ có thể cho phép truy cập dữ liệu hoặc thực hiện hành động trong phạm vi quyền của credential đó; khả năng ảnh hưởng đến integrity phụ thuộc vào quyền cụ thể.
• Không nên suy diễn rằng mọi ứng dụng Angular đều làm lộ secret. Rủi ro tập trung vào deployment SSR có đủ điều kiện về input URL, kiểm tra same-origin và credential phía máy chủ.

1. Nâng cấp @angular/platform-server lên đúng bản sửa của nhánh đang sử dụng: 20.3.30 cho nhánh 20.x, 21.2.22 cho nhánh 21.x hoặc 22.1.4 cho nhánh 22.x.
2. Với 19.2.25 hoặc cũ hơn, không chờ bản vá 19.x vì advisory đánh dấu nhánh này đã hết hỗ trợ và sẽ không được vá. Chuyển sang một nhánh có bản sửa được liệt kê và áp dụng đúng boundary của nhánh đó.
3. Nếu chưa thể nâng cấp, loại bỏ leading Unicode whitespace như U+00A0 và U+FEFF trước khi kiểm tra origin hoặc truyền URL vào HttpClient. Không chỉ dựa vào new URL(input, trustedOrigin).origin nếu chuỗi có thể được utility khác chuẩn hóa whitespace theo cách khác.
4. Rà soát các request SSR có gắn credential phía máy chủ. Nếu có bằng chứng request bị gửi đến destination không được phép, đánh giá và thay credential liên quan theo quy trình ứng phó sự cố.
5. Không coi một bản sửa cụ thể là bao phủ cho các nhánh song song hoặc phiên bản về sau nếu trạng thái của chúng không được xác nhận riêng.

1. Kiểm kê các deployment có bật Angular Server-Side Rendering và xác định phiên bản của @angular/platform-server.
2. Đối chiếu từng phiên bản với các nhánh bị ảnh hưởng trong affected_summary, thay vì chỉ kiểm tra tên package.
3. Rà soát code nơi input từ request hoặc resource URL đi vào HttpClient, đặc biệt các luồng sử dụng resolveUrl, parseUrl hoặc relativeUrlsTransformerInterceptorFn.
4. Kiểm tra các interceptor hoặc lớp request có thêm Authorization, API key, Bearer token hoặc credential phía máy chủ sau khi kiểm tra same-origin.
5. Nếu có telemetry cho outbound SSR requests, tìm các request có đích đến khác với trusted origin, cùng các path bắt đầu bằng Unicode whitespace như U+00A0 hoặc U+FEFF. Đây là kiểm tra phòng ngừa dựa trên cơ chế lỗi, không phải IOC được Angular công bố.
6. Bổ sung regression test cho các URL có leading Unicode whitespace để xác nhận chúng vẫn được xử lý như relative path trên cùng origin. Không thấy log bất thường không chứng minh deployment an toàn.