2.6.

Server-Side Request Forgery (SSRF) (My)

2.6.1. Mô tả
SSRF là một cuộc tấn công cho phép kẻ tấn công gửi các yêu cầu độc hại đến hệ thống
khác thông qua máy chủ web dễ bị tấn công. Các lỗ hổng SSRF được liệt kê trong Top 10 của
OWASP là rủi ro bảo mật ứng dụng lớn có thể dẫn đến việc tiết lộ thông tin nhạy cảm, cho phép
truy cập trái phép vào hệ thống nội bộ và mở đường cho các cuộc tấn công nguy hiểm hơn.
Sai sót dẫn tới SSRF xảy ra bất kỳ khi nào ứng dụng web tiến hành tìm nạp tài nguyên từ
xa mà không có hành động kiểm tra tính hợp lệ của “Hệ thống định vị tài nguyên thống nhất”
(Uniform Resource Locator-URL) do người dùng cung cấp. Điều đó cho phép kẻ tấn công ép
ứng dụng web gửi một yêu cầu tự tạo đến một điểm đích không mong muốn, ngay cả khi ứng
dụng được bảo vệ bởi tường lửa, VPN hoặc những loại kiểm soát truy cập (access control list-
ACL) mạng khác. Khi các ứng dụng web hiện đại ngày càng cung cấp cho người dùng cuối các
tính năng tiện lợi thì việc tìm nạp một URL dần trở thành một tình huống phổ biến. Vì vậy, tỷ lệ
gặp phải SSRF ngày càng tăng cao. Ngoài ra, mức độ nghiêm trọng của SSRF ngày càng cao do
các dịch vụ đám mây (cloud services) và sự phức tạp của kiến trúc.

2.6.2. Kịch bản tấn công

SSRF nhắm mục tiêu máy chủ

Các cuộc tấn công SSRF thường nhắm vào máy chủ, kẻ tấn công sẽ khiến ứng dụng dễ bị tấn
công gửi yêu cầu HTTP đến máy chủ lưu trữ. Trong cuộc tấn công SSRF máy chủ, kẻ tấn công
khai thác một quy trình trong đó trình duyệt hoặc hệ thống máy khách khác truy cập trực tiếp
vào URL trên máy chủ. Kẻ tấn công sẽ thay thế URL gốc bằng một URL khác, thường sử dụng
IP 127.0.0.1 hoặc tên máy chủ “localhost”, trỏ đến hệ thống tệp cục bộ trên máy chủ. Dưới tên
máy chủ này, kẻ tấn công tìm thấy đường dẫn tệp dẫn đến dữ liệu nhạy cảm.

SSRF nhắm mục tiêu vào phần cuối (SSRF Targeting the Back End)

Một biến thể khác của SSRF là khi máy chủ có mối quan hệ đáng tin cậy với thành phần phụ
trợ mà người dùng thường không thể truy cập. Các hệ thống này thường có địa chỉ IP riêng,
không thể định tuyến với mức độ bảo mật nội bộ yếu. Người dùng trái phép có thể truy cập
chức năng được bảo vệ bằng cách tương tác với hệ thống phụ trợ. Nếu khi máy chủ kết nối với
thành phần đó và có toàn quyền truy cập, kẻ tấn công có thể giả mạo yêu cầu và giành quyền
truy cập vào dữ liệu nhạy cảm hoặc thực hiện các hoạt động trái phép. Các thành phần back-
end thường có tính bảo mật yếu vì chúng được coi là được bảo vệ bên trong phạm vi mạng.

SSRF mù (Blind SSRF)

Các cuộc tấn công SSRF mù xảy ra khi máy chủ lưu trữ không trả lại dữ liệu hiển thị cho
kẻ tấn công. Chúng hoạt động bằng cách tập trung thực hiện các hành động độc hại thay vì truy
cập dữ liệu nhạy cảm. Kẻ tấn công có thể giả mạo quyền của người dùng hoặc các tệp nhạy
cảm trên máy chủ. Chẳng hạn, kẻ tấn công có thể thay đổi URL của lệnh gọi API để khiến máy
chủ truy xuất một tệp lớn nhiều lần. Cuối cùng, máy chủ có thể gặp sự cố, gây ra tình trạng từ
chối dịch vụ (DoS).

Các nhà phát triển (Developers) có thể ngăn chặn SSRF bằng cách triển khai một số hoặc tất
cả các biện pháp quản lý theo kỹ thuật phòng thủ chiều sâu (defence in depth) sau:

Từ tầng mạng (network layer):

Phân đoạn chức năng truy cập tài nguyên từ xa ra các mạng riêng biệt để giảm tác động của
SSRF.

Thực thi các chính sách tường lửa “từ chối theo mặc định” hoặc các quy tắc kiểm soát truy cập
mạng để chặn tất cả lưu lượng mạng trừ mạng nội bộ thiết yếu.

Gợi ý:

- Thiết lập quyền sở hữu và vòng đời cho các quy tắc tường lửa dựa trên các ứng dụng

- Ghi nhật ký tất cả các luồng mạng được chấp thuận và bị chặn trên tường lửa (xem

A09: 2021-Security Logging and Monitoring Failures)

- Từ tầng ứng dụng (Application layer)

- Kiểm tra và sàng lọc tất cả dữ liệu đầu vào do người dùng cung cấp

- Thực thi lược đồ URL, cổng và điểm đến với danh sách trắng

- Không gửi phản hồi chưa qua xử lý cho máy khách

- Tắt chuyển hướng HTTP

- Lưu ý về tính nhất quán của URL để tránh các cuộc tấn công như “DNS rebinding” và “thời
gian kiểm tra, thời gian sử dụng” (TOCTOU) “race conditions”

- Không giảm thiểu SSRF thông qua việc sử dụng danh sách từ chối hoặc biểu thức chính quy
(regular expression). Kẻ tấn công có danh sách mã khai thác, công cụ và kỹ năng để vượt qua
danh sách từ chối.

Các biện pháp bổ sung có thể xem xét:

Không triển khai các dịch vụ liên quan đến bảo mật khác trên các hệ thống bên ngoài (ví dụ:
OpenID). Kiểm soát lưu lượng cục bộ trên các hệ thống này (ví dụ: localhost). Đối với giao diện
người dùng với các nhóm người dùng chuyên dụng và có thể quản lý thì sử dụng mã hóa mạng
(ví dụ VPNs) trên các hệ thống độc lập để xem xét nhu cầu bảo vệ rất cao.

2.7. Các tấn công API

Threats Mô tả
Ủy quyền cấp đối APIs thường tiết lộ các điểm cuối (endpoints) xử lý các định danh
tượng có lỗ hổng đối tượng, tạo ra một bề mặt tấn công rộng về các vấn đề kiểm soát
truy cập cấp đối tượng (Object Level Access Control). Kiểm tra xác
thực cấp đối tượng cần được xem xét trong mọi hàm sử dụng
nguồn dữ liệu bằng ID từ người dùng.

Xác thực có lỗ hổng Cơ chế xác thực thường được triển khai một cách không đúng cách,
cho phép kẻ tấn công xâm nhập vào mã thông báo xác thực hoặc
tận dụng các lỗ hổng triển khai để giả mạo danh tính của người
dùng khác tạm thời hoặc vĩnh viễn. Việc làm mất khả năng của hệ
thống xác định người dùng, làm mất tính bảo mật của API tổng thể.

Ủy quyền cấp thuộc Hạng mục này kết hợp API3:2019 Excessive Data Exposure và
tính đối tượng có lỗ API6:2019 - Mass Assignment, tập trung vào nguyên nhân gốc: sự
hổng thiếu hụt hoặc xác thực kiểm soát cấp đối tượng tại cấp thuộc tính
đối tượng. Điều này dẫn đến sự tiết lộ hoặc can thiệp thông tin bởi
các bên chưa được ủy quyền.

Tiêu thụ tài nguyên Để đáp ứng các yêu cầu API, cần sử dụng các tài nguyên như băng
không hạn chế thông mạng, CPU, bộ nhớ và lưu trữ. Các tài nguyên khác như
email/SMS/cuộc gọi điện thoại hoặc xác thực sinh trắc học được
cung cấp bởi nhà cung cấp dịch vụ thông qua tích hợp API và được
trả tiền theo yêu cầu. Các cuộc tấn công thành công có thể dẫn đến
Tấn công Từ Chối Dịch Vụ (Denial of Service) hoặc tăng chi phí hoạt
động.

Ủy quyền cấp chức Các chính sách kiểm soát truy cập phức tạp với các hệ thống phân
năng bị hỏng cấp, nhóm và vai trò khác nhau và sự không rõ ràng trong việc tách
biệt giữa các chức năng quản trị và chức năng thông thường
thường dẫn đến các lỗ hổng xác thực. Bằng cách khai thác những
vấn đề này, kẻ tấn công có thể truy cập vào tài nguyên của người
dùng khác hoặc các chức năng quản trị.
Quyền truy cập không Các API dễ bị tổn thất trong lĩnh vực này tiết lộ một dòng chảy kinh
hạn chế vào các luồng doanh - chẳng hạn như việc mua vé hoặc đăng bình luận - mà
kinh doanh nhạy cảm không bù đắp cho cách chức năng có thể gây hại cho doanh nghiệp
nếu sử dụng quá mức trong một quy trình tự động. Điều này không
nhất thiết phải từ các lỗi triển khai.

Giả mạo yêu cầu phía Các lỗ hổng SSRF (Server-Side Request Forgery) có thể xảy ra khi
máy chủ một API đang truy xuất một nguồn tài nguyên từ xa mà không xác
 thực URI do người dùng cung cấp. Điều này cho phép kẻ tấn công
ép ứng dụng gửi một yêu cầu được tạo ra đến một đích không mong
muốn, ngay cả khi được bảo vệ bởi tường lửa hoặc VPN.

Cấu hình bảo mật sai API và các hệ thống hỗ trợ chúng thường chứa các cấu hình phức
tạp, được thiết kế để làm cho API có khả năng tùy chỉnh hơn. Các
kỹ sư phần mềm và DevOps có thể bỏ lỡ các cấu hình này hoặc
không tuân thủ các tiêu chuẩn bảo mật khi xử lý cấu hình, mở cửa
cho nhiều loại tấn công khác nhau.

Quản lý hàng tồn kho API thường tiết lộ nhiều điểm cuối hơn so với các ứng dụng web
không đúng cách truyền thống, làm cho việc tạo tài liệu đúng và được cập nhật một
phần quan trọng. Việc quản lý chính xác danh sách máy chủ và
phiên bản API triển khai cũng rất quan trọng để giảm thiểu vấn đề
như phiên bản API đã lỗi thời và các điểm cuối gỡ lỗi bị tiết lộ
Sử dụng API không Các nhà phát triển thường tin tưởng dữ liệu nhận được từ các API
an toàn của bên thứ ba hơn là dữ liệu nhập từ người dùng và thường áp
dụng các tiêu chuẩn bảo mật yếu hơn. Để tấn công các API, kẻ tấn
công tìm cách tấn công vào các dịch vụ bên thứ ba tích hợp thay vì
cố gắng tấn công trực tiếp vào API mục tiêu

Các giải pháp phòng tránh tấn công API

 Xác thực và ủy quyền mạnh mẽ: Sử dụng các biện pháp xác thực mạnh mẽ như OAuth, JWT
(JSON Web Tokens) và API Key để đảm bảo rằng chỉ người dùng hoặc ứng dụng được ủy quyền
mới có thể truy cập API của bạn.
 Kiểm soát truy cập: Thiết lập kiểm soát truy cập dựa trên vai trò và quyền, và đảm bảo rằng
người dùng hoặc ứng dụng chỉ có quyền truy cập vào các tài nguyên mà họ cần.
 Mã hóa dữ liệu: Sử dụng mã hóa để bảo vệ dữ liệu trong quá trình truyền và lưu trữ. Sử dụng
giao thức HTTPS để truyền dữ liệu an toàn.
 Bảo vệ chống tấn công SQL Injection: Sử dụng các câu truy vấn tham số hóa và kiểm tra dữ liệu
đầu vào để ngăn chặn cuộc tấn công SQL Injection.
 Bảo vệ chống tấn công Cross-Site Scripting (XSS): Thực hiện kiểm tra và xác thực dữ liệu đầu vào,
và mã hóa dữ liệu trước khi hiển thị nó trong ứng dụng web.
 Bảo vệ chống tấn công Cross-Site Request Forgery (CSRF): Sử dụng các biện pháp như mã thông
báo CSRF để xác định nguồn gốc của các yêu cầu HTTP.
 Giám sát và nhật ký hoạt động: Thực hiện giám sát liên tục và ghi lại hoạt động của API để phát
hiện sớm các hành vi bất thường.
 Bảo vệ chống tấn công DDoS (Distributed Denial of Service): Sử dụng các dịch vụ bảo vệ DDoS để
ngăn chặn các cuộc tấn công DDoS và tăng khả năng chịu tải của hệ thống.
 Cập nhật và quản lý thành phần: Đảm bảo rằng tất cả thành phần của hệ thống, bao gồm cả các
thư viện và phần mềm bên ngoài, được cập nhật thường xuyên để ngăn chặn tấn công thông
qua lỗ hổng đã biết.
 Quản lý và tài liệu API: Cung cấp tài liệu rõ ràng và dễ hiểu về API và đảm bảo rằng bạn hiểu rõ
các điểm cuối API của mình. Điều này giúp ngăn chặn các lỗ hổng về thiết kế.
 Thử nghiệm bảo mật: Thực hiện kiểm tra thử nghiệm bảo mật định kỳ để phát hiện và sửa lỗi
bảo mật.
 Chặn truy cập từ các nguồn không đáng tin cậy: Sử dụng tường lửa và cơ chế kiểm tra danh sách
đen để từ chối truy cập từ các địa chỉ IP không đáng tin cậy hoặc các nguồn không xác định.
 Thiết lập cơ chế giới hạn tần suất yêu cầu: Giới hạn số lượng yêu cầu một người dùng có thể
thực hiện trong một khoảng thời gian cố định để ngăn chặn cuộc tấn công liên tục.
 Tự động khóa và cảnh báo: Thực hiện cơ chế tự động khóa tài khoản sau một số lần đăng nhập
thất bại và cung cấp cảnh báo khi có hoạt động bất thường.
 Đào tạo người dùng cuối: Đào tạo người dùng về các nguy cơ bảo mật và cách sử dụng API một
cách an toàn.