SSRF do tin tưởng header trong Angular @angular/ssr cho phép điều hướng request nội bộ

Angular SSR là một công cụ kết xuất phía máy chủ cho các ứng dụng Angular. Các phiên bản trước 21.2.0-rc.1, 21.1.5, 20.3.17 và 19.2.21 có lỗ hổng Server-Side Request Forgery (SSRF) trong pipeline xử lý request của Angular SSR. Lỗ hổng tồn tại vì logic tái tạo URL nội bộ của Angular trực tiếp tin tưởng và sử dụng các HTTP header do người dùng kiểm soát, cụ thể là Host và nhóm X-Forwarded-*, để xác định base origin của ứng dụng mà không xác thực domain đích. Cụ thể, framework không có kiểm tra đối với domain của host, việc làm sạch path và ký tự, cũng như việc xác thực port. Lỗ hổng biểu hiện theo hai cách chính: phân giải URL tương đối ngầm định và tạo URL thủ công một cách tường minh. Khi khai thác thành công, lỗ hổng này cho phép điều hướng tùy ý các request nội bộ. Điều đó có thể dẫn đến việc đánh cắp credential, thăm dò mạng nội bộ và vi phạm tính bảo mật. Để trở nên dễ bị tấn công, ứng dụng nạn nhân phải sử dụng Angular SSR (Server-Side Rendering), ứng dụng phải thực hiện các request HttpClient bằng URL tương đối HOẶC tự tạo URL bằng các header Host / X-Forwarded-* chưa được xác thực thông qua đối tượng REQUEST, máy chủ ứng dụng phải có thể truy cập bởi attacker có khả năng tác động đến các header này mà không bị proxy phía trước xác thực nghiêm ngặt, và hạ tầng (Cloud, CDN hoặc Load Balancer) không được làm sạch hoặc xác thực các header đến. Các phiên bản 21.2.0-rc.1, 21.1.5, 20.3.17 và 19.2.21 có bản vá. Có một số biện pháp thay thế. Tránh sử dụng req.headers để tạo URL. Thay vào đó, sử dụng các biến tin cậy cho base API path. Những bên chưa thể nâng cấp ngay nên triển khai middleware trong server.ts để bắt buộc port ở dạng số và hostname đã được xác thực.

• @angular/ssr: Advisory của nhà phát triển xác định các nhánh bị ảnh hưởng là >= 21.2.0-next.0, < 21.2.0-rc.1, >= 21.0.0-next.0, < 21.1.5, >= 20.0.0-next.0, < 20.3.17, >= 19.0.0-next.0, < 19.2.21 và <= 18.2.21. Bản đã vá được nêu là 21.2.0-rc.1, 21.1.5, 20.3.17 và 19.2.21; advisory không liệt kê bản vá cho nhánh <= 18.2.21.
• @nguniversal/common: Các phiên bản <= 16.2.0 bị ảnh hưởng; advisory không liệt kê bản vá.
• @nguniversal/express-engine: Các phiên bản <= 16.2.0 bị ảnh hưởng; advisory không liệt kê bản vá.

Các ranh giới trên lấy theo advisory của Angular, trong đó package bị ảnh hưởng được gọi là @angular/ssr. Nhãn sản phẩm angular-cli trong bản ghi chuẩn hóa không nên được dùng thay cho việc kiểm tra package runtime thực tế.

Angular SSR xây dựng lại base origin của ứng dụng từ các HTTP header do client kiểm soát, đặc biệt là Host và nhóm X-Forwarded-*, nhưng không kiểm tra đầy đủ domain đích, path, ký tự đặc biệt hoặc port. Trong luồng xử lý URL nội bộ, điều này có thể làm thay đổi origin được dùng để phân giải các URL tương đối hoặc làm sai lệch URL do ứng dụng tự tạo từ REQUEST. Hai đường dẫn chính đã được mô tả là HttpClient dùng URL tương đối và mã ứng dụng tự xây dựng URL cho fetch hoặc third-party SDK dựa trên các header chưa được xác thực. Một báo cáo kỹ thuật của dự án xác định logic liên quan là createRequestUrl() trong packages/angular/ssr/node/src/request.ts, với ảnh hưởng đến production SSR server; báo cáo này phân biệt với dev server ng serve, nơi có cơ chế kiểm tra host riêng. Điều kiện khai thác gồm ứng dụng phải dùng Angular SSR, attacker phải tác động được đến các header, proxy phía trước không xác thực chặt chẽ, và hạ tầng không loại bỏ hoặc làm sạch các header đó. Cách ứng dụng cụ thể gửi request và dịch vụ downstream nào có thể bị truy cập vẫn phụ thuộc vào mã ứng dụng và cấu hình triển khai.

Lỗ hổng có thể bị khai thác qua mạng khi máy chủ SSR có thể nhận request từ attacker. Theo hồ sơ và advisory, attacker không cần xác thực, không cần người dùng tương tác, và điều kiện khai thác có độ phức tạp thấp khi các điều kiện triển khai cần thiết đã tồn tại. Attacker phải có khả năng đưa giá trị do mình chọn vào Host hoặc các header X-Forwarded-*, trực tiếp hoặc thông qua proxy được cấu hình không an toàn. Hồ sơ được cung cấp đặt known_exploited là null và public_exploit là false; các trường này không chứng minh rằng việc khai thác đang vắng mặt trong thực tế.

Khi các điều kiện triển khai phù hợp tồn tại, attacker có thể điều khiển base origin mà Angular SSR dùng để phân giải URL. Request server-side sau đó có thể được gửi đến máy chủ bên ngoài do attacker chọn hoặc đến tài nguyên nội bộ, tùy theo URL mà ứng dụng tạo và credential mà request mang theo. Hậu quả kỹ thuật chính là mất tính bảo mật của dữ liệu trong ngữ cảnh SSR, bao gồm credential, response từ service nội bộ và thông tin cloud metadata; advisory cũng mô tả khả năng có tác động hạn chế đến tính toàn vẹn thông qua việc thay đổi đích request hoặc dữ liệu được render. Lỗ hổng không tự động cho phép truy cập mọi mạng nội bộ, vì kết quả còn phụ thuộc vào quyền mạng của máy chủ, logic request của ứng dụng và các lớp lọc phía trước. Một báo cáo kỹ thuật riêng nêu thêm rủi ro cache poisoning trong một số cấu hình CDN, nhưng đây là hậu quả phụ thuộc triển khai chứ không phải điều kiện cần cho mọi trường hợp.

Lỗ hổng có thể tạo ra các hậu quả vận hành và dữ liệu sau:

• Lộ dữ liệu và credential: Request bị chuyển hướng có thể làm lộ Authorization header, session cookie hoặc dữ liệu mà SSR xử lý.
• Mở rộng khả năng quan sát mạng nội bộ: Máy chủ SSR có thể bị lợi dụng để thăm dò service nội bộ, database hoặc endpoint metadata của cloud mà Internet không truy cập trực tiếp được.
• Rủi ro đối với ranh giới tin cậy: Một request từ máy chủ ứng dụng đến đích không mong muốn có thể vượt qua các kiểm soát mạng vốn chỉ cho phép máy chủ truy cập tài nguyên nội bộ.
• Phạm vi giới hạn: Không phải mọi ứng dụng Angular đều bị ảnh hưởng. Phải đồng thời có Angular SSR, cách sử dụng URL hoặc header phù hợp, và đường truyền header không được proxy hoặc hạ tầng xác thực chặt chẽ.

1. Nâng cấp @angular/ssr theo đúng nhánh phát hành: dùng 21.2.0-rc.1 cho nhánh 21.2, 21.1.5 cho nhánh 21.1, 20.3.17 cho nhánh 20 và 19.2.21 cho nhánh 19. Không suy ra rằng mọi nhánh mới hơn hoặc nhánh song song đều an toàn nếu advisory không xác nhận nhánh đó.
2. Với @nguniversal/common và @nguniversal/express-engine ở các phiên bản bị ảnh hưởng, advisory không cung cấp bản vá cụ thể. Áp dụng biện pháp giảm thiểu, đánh giá kế hoạch chuyển sang package được hỗ trợ và lấy hướng dẫn trực tiếp từ Angular trước khi coi việc nâng cấp package khác là đã khắc phục.
3. Không dùng req.headers để tạo URL. Dùng biến tin cậy cho base API path hoặc absolute URL đã được cấu hình trước, thay vì lấy origin từ Host hoặc X-Forwarded-*.
4. Nếu chưa thể nâng cấp, thêm middleware trong server.ts trước Angular engine để chỉ cho phép hostname đã allowlist, từ chối path hoặc ký tự không hợp lệ trong giá trị host, và yêu cầu X-Forwarded-Port phải là số.
5. Cấu hình reverse proxy, CDN, load balancer hoặc ingress để xác thực, ghi đè hoặc loại bỏ các header forwarding đến từ client không đáng tin cậy. Kiểm tra lại cấu hình sau mỗi thay đổi hạ tầng, vì proxy không được coi là an toàn chỉ dựa trên tên sản phẩm.

1. Kiểm kê dependency và lockfile để xác định các ứng dụng dùng @angular/ssr, @nguniversal/common hoặc @nguniversal/express-engine, sau đó đối chiếu từng phiên bản với các nhánh bị ảnh hưởng trong advisory.
2. Rà soát mã server và application để tìm việc dùng REQUEST, req.headers, Host, X-Forwarded-Host, X-Forwarded-Proto hoặc X-Forwarded-Port trong quá trình tạo URL, cùng các request HttpClient dùng URL tương đối trong SSR.
3. Xác định các deployment đang chạy production SSR thay vì chỉ chạy dev server, đồng thời kiểm tra đường đi của các header qua reverse proxy, CDN, load balancer hoặc ingress.
4. Kiểm tra telemetry của proxy và ứng dụng để tìm request có host, path hoặc port bất thường và các request SSR bị từ chối sau khi áp dụng validation. Đây là tín hiệu phòng ngừa, không phải IOC được advisory xác nhận.
5. Advisory không cung cấp một IOC đáng tin cậy riêng cho lỗ hổng này. Không nên coi việc không thấy dấu hiệu trong log là bằng chứng hệ thống an toàn.