1.Giả mạo yêu cầu phía máy chủ (còn được gọi là SSRF)
- Là một lỗ hổng bảo mật web cho phép kẻ tấn công khiến ứng dụng phía máy chủ thực hiện các yêu cầu đến một vị trí ngoài ý muốn.
- Trong một cuộc tấn công SSRF điển hình, kẻ tấn công có thể khiến máy chủ tạo kết nối với các dịch vụ chỉ dành cho nội bộ trong cơ sở hạ tầng của tổ chức. Trong các trường hợp khác, họ có thể buộc máy chủ kết nối với các hệ thống bên ngoài tùy ý, có khả năng làm rò rỉ dữ liệu nhạy cảm, chẳng hạn như thông tin đăng nhập ủy quyền.
2.Tác động của các cuộc tấn công SSRF là gì?
- Một cuộc tấn công SSRF thành công thường có thể dẫn đến các hành động trái phép hoặc truy cập vào dữ liệu trong tổ chức, trong chính ứng dụng dễ bị tấn công hoặc trên các hệ thống phụ trợ khác mà ứng dụng có thể giao tiếp. Trong một số trường hợp, lỗ hổng SSRF có thể cho phép kẻ tấn công thực hiện lệnh tùy ý.
- Việc khai thác SSRF khiến kết nối với hệ thống bên thứ ba bên ngoài có thể dẫn đến các cuộc tấn công độc hại tiếp theo dường như bắt nguồn từ tổ chức lưu trữ ứng dụng dễ bị tấn công.
3.Các cuộc tấn công SSRF vào chính máy chủ.
Trong một cuộc tấn công SSRF nhằm vào chính máy chủ, kẻ tấn công sẽ khiến ứng dụng thực hiện yêu cầu HTTP quay lại máy chủ đang lưu trữ ứng dụng, thông qua giao diện mạng vòng lặp của nó. Điều này thường liên quan đến việc cung cấp URL có tên máy chủ như 127.0.0.1 (địa chỉ IP dành riêng trỏ đến bộ điều hợp loopback) hoặc localhost (tên thường được sử dụng cho cùng một bộ điều hợp).
Ví dụ: hãy xem xét một ứng dụng mua sắm cho phép người dùng xem liệu một mặt hàng có còn hàng ở một cửa hàng cụ thể hay không. Để cung cấp thông tin về hàng tồn kho, ứng dụng phải truy vấn nhiều REST API phụ trợ khác nhau, tùy thuộc vào sản phẩm và cửa hàng được đề cập. Chức năng này được triển khai bằng cách chuyển URL đến điểm cuối API back-end có liên quan thông qua yêu cầu HTTP front-end. Vì vậy, khi người dùng xem trạng thái tồn kho của một mặt hàng, trình duyệt của họ sẽ đưa ra yêu cầu như sau:
POST /product/stockHTTP/ 1.0Content Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://shop.net:8080/check%3FproductId%3D6%26storeId%3D1
Điều này khiến máy chủ đưa ra yêu cầu tới URL được chỉ định, truy xuất trạng thái tồn kho và trả lại trạng thái này cho người dùng.
Trong trường hợp này, kẻ tấn công có thể sửa đổi yêu cầu chỉ định URL cục bộ cho chính máy chủ. Ví dụ:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/admin
Tại đây, máy chủ sẽ lấy nội dung của /adminURL và trả lại cho người dùng.
Tất nhiên, bây giờ kẻ tấn công có thể truy cập /admintrực tiếp vào URL. Nhưng chức năng quản trị thường chỉ có thể truy cập được đối với người dùng được xác thực phù hợp. Vì vậy, kẻ tấn công chỉ truy cập trực tiếp vào URL sẽ không thấy bất kỳ điều gì đáng quan tâm. Tuy nhiên, khi yêu cầu tới /adminURL xuất phát từ chính máy cục bộ, các biện pháp kiểm soát truy cập thông thường sẽ bị bỏ qua. Ứng dụng cấp quyền truy cập đầy đủ vào chức năng quản trị vì yêu cầu dường như bắt nguồn từ một vị trí đáng tin cậy.
Tại sao các ứng dụng hoạt động theo cách này và hoàn toàn tin tưởng các yêu cầu đến từ máy cục bộ? Điều này có thể phát sinh vì nhiều lý do:
- Kiểm tra kiểm soát truy cập có thể được triển khai trong một thành phần khác nằm phía trước máy chủ ứng dụng. Khi một kết nối được thực hiện trở lại chính máy chủ, quá trình kiểm tra sẽ bị bỏ qua.
- Đối với mục đích khắc phục thảm họa, ứng dụng có thể cho phép truy cập quản trị mà không cần đăng nhập đối với bất kỳ người dùng nào đến từ máy cục bộ. Điều này cung cấp một cách để quản trị viên khôi phục hệ thống trong trường hợp họ mất thông tin đăng nhập. Giả định ở đây là chỉ người dùng hoàn toàn đáng tin cậy mới đến trực tiếp từ chính máy chủ.
- Giao diện quản trị có thể đang lắng nghe trên một số cổng khác với ứng dụng chính và do đó người dùng có thể không truy cập trực tiếp được.
