# Server-side request forgery (SSRF)

## Khái niệm

Là lỗ hổng bảo mật web cho phép kẻ tấn cống làm máy chủ ứng dụng thực hiện request đến một vị trí không mong muôn (dịch vụ chỉ danh cho nội bộ tổ chức/hệ thống bên ngoài tùy ý) nhằm rò rỉ dữ liệu nhạy cảm chẳng hạn như authorization credential.

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FZVzi1DB3zt99LkJELGt4%2Fimage.png?alt=media&#x26;token=026ee13a-cbd6-4344-b5ff-1798af903efb" alt=""><figcaption></figcaption></figure>

## Tác động

* Hành động trái phép hoặc truy cập dữ liệu nội bộ (do lỗ hổng trong ứng hoặc trong các back-end system mà ứng dụng có thể giao tiếp với)
* Thực thi lệnh tùy ý RCE
* Gấy ra kết nối đến hệ thống của bên thứ ba bên ngoài có thể dẫn đến các cuộc tấn công ác ý tiếp theo (thường bắt nguồn từ việc tổ chức lưu trữ ứng dụng dễ bị tấn công)

## Các cuộc tấn công SSRF phổ biến

SSRF thường khai thác trust relationship liên quqn đến máy chủ hoặc các hệ thông back-end khác trong cùng một tổ chưc

### Tấn công SSRF vào máy chủ

Khiến ứng dụng thực hiện HTTP request trở lại máy chủ hosting ứng dụng, thông qua loopback[^1] (thường liên quan đến việc cung cấp một URL với hostname như 127.0.0.1[^2] hoặc localhost[^3]).

Ví du: Khi người dùng stock status một item, trình duyệt sẽ thực hiện request sau:

```
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1
```

Kẻ tấn công có thể điều chỉnh request để chỉ định URL local máy chủ

```
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin
```

&#x20;Máy chủ sẽ lấy nội dụng `/admin` và trả về cho người dùng.

Nếu yêu cầu đến URL `/admin`đến từ máylocal, access control 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 có vẻ như bắt nguồn từ một vị trí đáng tin cậy.

**NOTE: Lý do các ứng dụng hoạt động theo cách này và ngầm tin tưởng các yêu cầu đến từ máy cục bộ:**

* Có thể kiểm soát truy cập chỉ được triển khai trong một thành phần nằm trước ứng dụng.
* Với mục đích phục hồi sau 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 với bất kỳ user từ máy cục bộ
* Giao diện quản trị có thể lắng nghe trên một số cổng khác với ứng dụng chính và người dùng có thể không thể truy cập trục tiếp

{% embed url="<https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost>" %}

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FO21OdBXBBI3ZJnSVNFwU%2Fimage.png?alt=media&#x26;token=538ab7e0-2a25-4249-9d1c-8e727879ac37" alt=""><figcaption></figcaption></figure>

**Giải pháp:**

Intercept khi request chức năng xem stock status

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FxGvtSUvuF2q5scc7vqvR%2Fimage.png?alt=media&#x26;token=4d545dfb-a49b-4b91-90f1-e56f8effdaac" alt=""><figcaption></figcaption></figure>

Request này gọi trực tiệp đến máy chủ thông qua URL. Sửa stockApi

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2Fq0VpJjnX1ndjodvYSfMM%2Fimage.png?alt=media&#x26;token=4678b9a3-bcec-49fa-bbbd-cb89b71c7120" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FC7LGKV7IJwWKmwv7czk6%2Fimage.png?alt=media&#x26;token=02d36a5b-b045-47fd-a385-325d8392c548" alt=""><figcaption></figcaption></figure>

Đây là request khi xóa tài khoản carlos

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FHnDyKiD4BM5czy38VSSS%2Fimage.png?alt=media&#x26;token=b1a4a265-e4b0-4758-9160-33a88a46a99c" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FxaldPb23k1T6e6cbyA7a%2Fimage.png?alt=media&#x26;token=1132d48d-9a6f-459a-9b2d-ea6d09af20d2" alt=""><figcaption></figcaption></figure>

Lặp lại request check stock status và sửa stockApi như sau

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FS3WBLstogzEOMcInjcP0%2Fimage.png?alt=media&#x26;token=f32fb27f-8a50-4390-8bc7-c807c2eeede9" alt=""><figcaption></figcaption></figure>

Gửi và nhận kết quả&#x20;

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FsWgcCLZbL1Uim2URrMYz%2Fimage.png?alt=media&#x26;token=b211ea99-e0c8-40fd-8d44-0e9e7171867d" alt=""><figcaption></figcaption></figure>

### Tấn công SSRF vào các back-end system khác

Trong một  số trường hợp, application server có thể tương tác với các back-end sysem mà không thể truy cập trực tiếp bởi người dùng. Các hệ thống này thường có địa chỉ IP private không thể định tuyến, bảo vệ bởi network topology nên thường có bảo mật yếu hơn. Đôi khi chúng còn chưa thông tin nhạy cảm mà có thể truy cập không cần xác thực bởi bất kỳ ai mà có thể tương tác với chúng.

Ví dụ: Nếu biết được địa chỉ ip riêng tư, attacker có thể sửa truy vấn api hợp lệ để truy cập

```
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin
```

{% embed url="<https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-backend-system>" %}

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FQumIE4jizkJwrmDok4G5%2Fimage.png?alt=media&#x26;token=703de6f8-9e53-4ca3-8d1e-3ab41bd927b5" alt=""><figcaption></figcaption></figure>

Sử dụng chức năng stock check,&#x20;

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FmhK2mUrFTdKoFlEkT4Dq%2Fimage.png?alt=media&#x26;token=0c45dc48-932d-4d27-a383-a2797fd0f590" alt=""><figcaption></figcaption></figure>

Giá trị stockApi trỏ đến IP là 192.168.0.1

Từ đây có thể dự đoán rằng dải mạng nội bộ của máy chủ là 192.168.0.x

Brute-force nhằm tìm địa chỉ hợp lệ cho SSRF

Tìm và gửi request `POST /product/stock` đến Intruder. Sửa giá trị sockApi như sau:

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2F0dW594f7BDQbunnoJc8i%2Fimage.png?alt=media&#x26;token=dd98d457-ed90-44aa-8a0d-fc570de32503" alt=""><figcaption></figcaption></figure>

Trong tab Payload

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FdTZSD78TB7AZwUJzGsjh%2Fimage.png?alt=media&#x26;token=c1bc15ee-99ad-4841-97c0-c07dbbb4274f" alt=""><figcaption></figcaption></figure>

Attack và tìm status code 200

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FhRRUJNlKfRItTSGvrx8C%2Fimage.png?alt=media&#x26;token=2165045d-4fdb-469a-b0d8-95fc2e2774ee" alt=""><figcaption></figcaption></figure>

Intercept một request POST /product/stock và sửa thành

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2F5JmFm9S4nW1qX1GDyB5m%2Fimage.png?alt=media&#x26;token=304ac458-2d9b-4e05-9606-c20b3e5bed72" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FoY4sofJxyk7x7BCoqsh8%2Fimage.png?alt=media&#x26;token=7285d227-0af9-4b1f-9dad-bed1b14e5d88" alt=""><figcaption></figcaption></figure>

## Bỏ qua các biện pháp phòng thủ SSRF phổ biến

### SSRF với bộ lọc đầu vào dựa trên blacklist

Blacklist gồm`127.0.0.1` và `localhost`, hoặc URL nhạy cảm như `/admin`.

* Sử dụng biểu diễn IP thay thể của `127.0.0.1`, như `2130706433`, `017700000001`, hoặc `127.1`.
* Đăng ký tên miên riêng mà resolve  tới `127.0.0.1` (có thể sử dụng `spoofed.burpcollaborator.net`)
* Làm mờ các chuỗi bị chặn bằng cách sử dụng mã hóa URL (admin thành %61%64%6D%69%6E) hoặc thay đổi chữ hoa chữ thường.
* Cung cấp một URL bạn kiểm soát, cái mà chuyển hướng đến URL mục tiêu. Thử sử dụng các mã chuyển hướng khác nhau, cũng như các giao thức khác nhau cho URL mục tiêu (như chuyển  URL từ `http:` thành `https:` )

{% embed url="<https://portswigger.net/web-security/ssrf/lab-ssrf-with-blacklist-filter>" %}

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2Fq9MSGM5DWPBitiGqdHAj%2Fimage.png?alt=media&#x26;token=e80a5530-5c08-488a-b9d6-6ced0e3580f3" alt=""><figcaption></figcaption></figure>

Sử dụng chức năng stock check,  gửi request POST /product/stock đến Repeater.

Thử sửa stockApi thành <http://localhost>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2F17SVtU7xwid2e0hoHmJw%2Fimage.png?alt=media&#x26;token=a122c157-7f77-4655-be29-d0c47f09498f" alt=""><figcaption></figcaption></figure>

Có thể đoán rằng ứng dụng sử dụng blacklist để chặn một số hostname

Sử dụng hostname thay thế 127.1

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FgGtz7pzpz7YmQZeeKPig%2Fimage.png?alt=media&#x26;token=bf2078d7-6335-4732-bcb6-563867363ba7" alt=""><figcaption></figcaption></figure>

Thành công vượt qua. Nhưng khi thêm đường dân `/admin` thì tiếp tục bị chặn

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FWtPnKMmtS3Siv6TKMY5Z%2Fimage.png?alt=media&#x26;token=50a0119f-3557-4a10-bb00-1c1012a1cff5" alt=""><figcaption></figcaption></figure>

Thử làm mờ chuỗi admin bằng URL encode hoặc thay đổi chữ hoa thường. Ở đây thử với Admin thì thành công

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FSuOTInFVeWN4a7DWXvTc%2Fimage.png?alt=media&#x26;token=92cc5f4b-182d-4a60-824a-3edd986c11ea" alt=""><figcaption></figcaption></figure>

Xóa tài khoản carlos bằng cách sửa stockApi như sau&#x20;

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FagdVT6L5kEV0hBpX4caL%2Fimage.png?alt=media&#x26;token=8f2b582b-5ae2-47a0-9c91-2d38742915aa" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2Fgkp7L4IDAXn6eXGA3agd%2Fimage.png?alt=media&#x26;token=788de4c0-7fff-4dc8-8ec3-f947a852a322" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2Fnec8d8pDOuC2x1qfXvlr%2Fimage.png?alt=media&#x26;token=bb240a9d-b23c-4e98-8e8b-a0f990ebdf97" alt=""><figcaption></figcaption></figure>

### SSRF với bộ lọc đầu vào dựa trên whitelist

Một số ứng dụng chỉ cho phép các đầu vào khớp với danh sách giá trị hợp lệ (whitelist). Bộ lọc có thể kiểm tra sự khớp ở đầu chuỗi hoặc ở bất kỳ vị trí nào trong chuỗi đầu vào. Có thể bỏ qua bộ lọc này bằng cách khai thác các điểm không nhất quán trong việc phân tích cú pháp URL.

Cụ thể, tiêu chuẩn URL có một số tính năng dễ bị bỏ qua khi thực hiện kiểm tra và xác thực URL:

* **Chèn thông tin xác thực trước hostname** bằng ký tự `@`, ví dụ: `https://expected-host:fakepassword@evil-host`.
* **Sử dụng ký tự `#`** để chỉ định phần fragment của URL, ví dụ: `https://evil-host#expected-host`.
* **Khai thác hệ thống phân cấp tên DNS** để chèn đầu vào yêu cầu vào một tên DNS đầy đủ do bạn kiểm soát, ví dụ: `https://expected-host.evil-host`.
* **Mã hóa URL (URL-encoding)** để gây nhầm lẫn cho mã phân tích cú pháp URL, hoặc sử dụng mã hóa kép khi có sự khác biệt trong việc xử lý ký tự URL-encoded giữa bộ lọc và hệ thống back-end.

Kết hợp các kỹ thuật này với nhau để gia tăng khả năng vượt qua các bộ lọc bảo mật.

{% embed url="<https://portswigger.net/web-security/ssrf/lab-ssrf-with-whitelist-filter>" %}

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FwtOhKACiYPiEqSvjPIDn%2Fimage.png?alt=media&#x26;token=368dd132-1087-4ccb-9757-5ab2d32d7ca3" alt=""><figcaption></figcaption></figure>

1. Sử dụng chức năng stock check, gửi request `POST /product/stock` đến Repeater.&#x20;

Đầu tiên, sửa stockApi=<http://127.1>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2F4uQoe19Z4mOheoSqv3uN%2Fimage.png?alt=media&#x26;token=a105ff87-bcfd-471a-92c9-1ed01bbcac35" alt=""><figcaption></figcaption></figure>

Nhận được lỗi **External stock check host must be stock.weliketoshop.net.** Có thể&#x20;

hiểu rằng phải là truy vấn trong stock.weliketoshop.net

2. Sửa stockapi thành stock.weliketoshop.net

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2F11aqAMTw91qtdBzR8JYh%2Fimage.png?alt=media&#x26;token=81399eb2-f92b-40aa-b7ba-d4224e74c225" alt=""><figcaption></figcaption></figure>

Nhận được mã lỗi 500 Internal Server Error

3. Thử kết nối external stock với username bất kỳ ví dụ như <http://hacking@stock.weliketoshop.net>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FbOtsDkC3iP33HbbdM6IW%2Fimage.png?alt=media&#x26;token=3d90c843-4ee9-49fc-a93e-3587d604f424" alt=""><figcaption></figcaption></figure>

Mã lỗi 500 giống như trên cho thấy máy chủ đang cố kết nối với tài khoản hacking, cho ta cách bypass cách phòng thủ này

4. Đặt stockApi=<http://127.1#@stock.weliketoshop.net>  ('#' để 127.1 không được hiểu là username )

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2Ffxqn9RhH93rRXmJj2has%2Fimage.png?alt=media&#x26;token=57c9b2a9-94e4-4c72-9a88-bd846e2a59d4" alt=""><figcaption></figcaption></figure>

Lỗi “ **400 Bad Request** ” và “External stock check host must be stock.weliketoshop.net”. Có vẻ dấu # là nguyên nhân, cần làm mờ nó

5. Thực hiện mã hóa lần nữa với dấu #,  thành `%2523`

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FNKicDeXTNkEY3vyi8BRH%2Fimage.png?alt=media&#x26;token=1e47bd39-3c0b-4b28-b6b4-19eea902b468" alt=""><figcaption></figcaption></figure>

Thành công vào trang quản trị.

6. Xóa người dùng carlos: <http://127.1%23@stock.weliketoshop.net/admin/delete?username=carlos>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FXo7T0kfpTzJt6Qg4F0O8%2Fimage.png?alt=media&#x26;token=4bddcf0b-1a39-4d89-9c61-ada40bf494b0" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FcRWdtFAT3eLBElPaWCEX%2Fimage.png?alt=media&#x26;token=21fa2a62-c978-4e86-b854-97dd53708bb0" alt=""><figcaption></figcaption></figure>

### Bypass bộ lọc SSRF thông qua open redirection

Ví dụ, khi ứng dụng cho phép người dùng nhập URL nhưng thực hiện kiểm tra chặt chẽ để ngăn chặn việc khai thác SSRF (Server-Side Request Forgery), nếu ứng dụng có lỗ hổng chuyển hướng mở, có thể tạo ra một URL thỏa mãn bộ lọc nhưng vẫn dẫn đến mục tiêu mong muốn.

* Ví dụ, ứng dụng có lỗ hổng chuyển hướng mở với URL:

  ```
  /product/nextProduct?currentProductId=6&path=http://evil-user.net
  ```

  sẽ trả về một chuyển hướng đến:

  ```
  http://evil-user.net
  ```
* Ccó thể lợi dụng lỗ hổng này để vượt qua bộ lọc và khai thác lỗ hổng SSRF như sau:

  ```plaintext
  POST /product/stock HTTP/1.0
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 118

  stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin
  ```

Khai thác này thành công vì ứng dụng kiểm tra URL của `stockAPI` nằm trong domain hợp lệ, sau đó yêu cầu URL được cung cấp, dẫn đến chuyển hướng mở và cuối cùng truy cập vào URL nội bộ mà kẻ tấn công mong muốn.

{% embed url="<https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection>" %}

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FNMV461R1RjVfJ3A9zWob%2Fimage.png?alt=media&#x26;token=af04ef32-fc36-4bbe-b1af-5381248770b6" alt=""><figcaption></figcaption></figure>

**Giải pháp:**&#x20;

1. Sử dụng chức năng stock check, gửi request `POST /product/stock` đến Repeater.&#x20;

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FDGknNxESrt2GkkQ5u6ei%2Fimage.png?alt=media&#x26;token=ffcb6b81-3e00-4c49-9d9e-2c59d88e2677" alt=""><figcaption></figcaption></figure>

Không còn hostname trong api call, cho thấy rằng tính năng này chỉ giới hạn cho phép truy cập local application

2. Cuối trang có tính năng Next product

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2Fapnv4C7XOxN8aKs3RL5u%2Fimage.png?alt=media&#x26;token=17d86e06-90c1-486a-8826-e5300aa7245c" alt=""><figcaption></figcaption></figure>

Tạo ra request như dưới đây

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FySYEJaWh3j1bfXLB5NJA%2Fimage.png?alt=media&#x26;token=6ffc068e-70a2-492f-9baa-fea931ef01be" alt=""><figcaption></figcaption></figure>

Đây có thể là lỗ hổng open direction

3. Sửa stockApi= /product/nextProduct?currentProductId=1\&path=<http://192.168.0.12:8080/admin/delete?username=carlos>

Điều này cho phép chuyển hướng hợp lệ để xóa tài khoản carlos

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FkIKUmPTLsFrNzTLN5Mdm%2Fimage.png?alt=media&#x26;token=0795b5e2-f01f-4c70-a3a1-02972e333b3c" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2F7jrv0XNEAbLf0BsQVFfo%2Fimage.png?alt=media&#x26;token=1036bff5-f1a3-427d-831d-c7242051081c" alt=""><figcaption></figcaption></figure>

## Lỗ hổng Blind SSRF&#x20;

### Khái niệm

Blind SSRF xảy ra khi một ứng dụng có thể bị lừa để thực hiện HTTP request đến một URL do người dùng cung cấp, nhưng response từ yêu cầu đó không được trả về phía người dùng ở frontend

### Tác động

Thường thấp hơn so với SSRF thông thường vì bản chất một chiều của nó: không dễ dàng khai thác để lấy dữ liệu nhạy cảm từ hệ thống back-end, mặc dù đôi khi có thể được khai thác để RCE

### Các phát hiện và khai thác

**Phát hiện:** Cách đáng tin cậy nhất để phát hiện lỗ hổng Blind SSRF là sử dụng các kỹ thuật **out-of-band (OAST):** gửi HTTP request đến một hệ thống bên ngoài mà bạn kiểm soát và giám sát các tương tác mạng với hệ thống đó. Sử dụng Burp Collaborator, tạo ra các tên miền duy nhất và gửi chúng dưới dạng payload đến ứng dụng. Nếu quan sát thấy có yêu cầu HTTP đến từ ứng dụng, thì ứng dụng đó có lỗ hổng SSRF.

**Lưu ý:** Thường khi kiểm tra lỗ hổng SSRF, có thể thấy DNS lookup cho tên miền của Burp Collaborator nhưng không thấy HTTP request tiếp theo. Điều này thường xảy ra khi ứng dụng cố gắng thực hiện HTTP request nhưng bị chặn bởi bộ lọc ở cấp độ mạng.

**Khai thác:** Vì không thể xem phản hồi từ back-end request, nên không thể sử dụng lỗ hổng này để khám phá nội dung trên các hệ thống mà máy chủ ứng dụng có thể tiếp cận. Tuy nhiên, có thể sử dụng Blind SSRF để thăm dò các lỗ hổng khác trên máy chủ hoặc hệ thống back-end, bằng cách quét địa chỉ IP nội bộ và gửi các payload được thiết kế để phát hiện các lỗ hổng đã biết.

Một cách khác là yêu cầu ứng dụng kết nối đến hệ thống do kẻ tấn công kiểm soát và trả về phản hồi độc hại. Nếu có thể khai thác lỗ hổng nghiêm trọng ở phía máy chủ HTTP, bạn có thể đạt được khả năng thực thi mã từ xa (RCE) trong cơ sở hạ tầng ứng dụng.

{% embed url="<https://portswigger.net/web-security/ssrf/blind/lab-out-of-band-detection>" %}

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FeRYWa6RTzLDTAFGZmt0R%2Fimage.png?alt=media&#x26;token=b18e0f9b-3222-438f-9af2-3b825441196b" alt=""><figcaption></figcaption></figure>

**Giải pháp:**

1. Truy cập một sản phẩm, chặn yêu cầu trong Burp Suite và gửi nó đến Burp Repeater.
2. Trong tab Repeater, chọn header `Referer`, nhấp chuột phải và chọn "Insert Collaborator Payload" để thay thế tên miền ban đầu bằng một tên miền được tạo bởi Burp Collaborator. Gửi yêu cầu.
3. Chuyển đến tab Collaborator và nhấn "Poll now". Nếu không thấy bất kỳ tương tác nào, chờ vài giây và thử lại, vì lệnh phía máy chủ được thực thi không đồng bộ.
4. Bạn sẽ thấy một số tương tác DNS và HTTP được khởi tạo bởi ứng dụng kết quả từ payload của bạn.

{% embed url="<https://portswigger.net/web-security/ssrf/blind/lab-shellshock-exploitation>" %}

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FvL22r3wqNCcVAhf8flik%2Fimage.png?alt=media&#x26;token=166bcfa6-62c2-4df9-8e7f-36bcba1da729" alt=""><figcaption></figcaption></figure>

**Giải pháp: Tham khảo**

{% embed url="<https://viblo.asia/p/server-side-request-forgery-vulnerabilities-ssrf-cac-lo-hong-gia-mao-yeu-cau-phia-may-chu-phan-5-obA466GG4Kv>" %}

**Shellshock**

**Shellshock** là một lỗ hổng bảo mật nghiêm trọng được phát hiện vào năm 2014 trong Bash, một trình shell phổ biến được sử dụng rộng rãi trên các hệ thống Unix/Linux và macOS. Lỗ hổng này cho phép kẻ tấn công thực thi các lệnh tùy ý trên máy chủ từ xa thông qua việc khai thác cách Bash xử lý các biến môi trường

**Xây dựng một payload để kiểm thử lỗ hỏng Shellshock** như sau:

**`env x='() { :;}; echo vulnerable' bash -c "echo this is a test"`**

<figure><img src="https://images.viblo.asia/d6743800-01a9-4fa1-90b4-889d7c6fb671.png" alt=""><figcaption></figcaption></figure>

Tại phiên bản **Bash 4.3** nó đã hoạt động, giải thích về câu payload trên:

* **`env`**: đặt biến môi trường sau đó thực thi luôn câu lệnh phía sau
* **`bash -c`**: mở một tiến trình con bash sau đó thực thi lệnh phía sau

sau khi mở tiến trình con bash, hệ thống đặt biến môi trường **`x`** và hiểu **`x`** là một hàm tự động, do không có quy định việc kết thúc của hàm nên hệ thống đã thực thi luôn câu lệnh phía sau và in ra **vulnerable**, tiếp theo thực thi in ra **this is a test**.

<figure><img src="https://2733582939-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnePar6ARbmno0NDI8DDU%2Fuploads%2FLvbZHt6x9jzIegkPXM0v%2Fimage.png?alt=media&#x26;token=4b5a20a1-d303-443a-b9f8-c99a377165d7" alt=""><figcaption></figcaption></figure>

## Tìm bề mặt tấn công ẩn cho lỗ hổng SSRF

**1. URL không đầy đủ trong các yêu cầu:**

* **Mô tả:** Một số ứng dụng chỉ chèn tên máy chủ hoặc phần của đường dẫn URL vào các tham số yêu cầu. Giá trị này sau đó được tích hợp vào URL đầy đủ mà máy chủ sẽ yêu cầu.
* **Khó khăn:** Nếu bạn không kiểm soát toàn bộ URL được yêu cầu, khả năng khai thác có thể bị hạn chế.
* **Chiến lược:** Phân tích cách mà URL được tạo ra từ các tham số và kiểm tra xem có thể thay đổi hoặc điều chỉnh giá trị của các tham số này để thực hiện tấn công SSRF không.

**2. URL trong các định dạng dữ liệu:**

* **Mô tả:** Một số ứng dụng truyền dữ liệu theo các định dạng có thể bao gồm các URL, mà sau đó có thể được yêu cầu bởi trình phân tích định dạng dữ liệu.
* **Ví dụ:** Định dạng XML có thể chứa các URL và nếu ứng dụng phân tích XML, có thể xảy ra các lỗ hổng XXE (XML External Entity) và SSRF thông qua XXE.
* **Chiến lược:** Xem xét các định dạng dữ liệu mà ứng dụng chấp nhận và phân tích các cách mà URL có thể được xử lý trong các định dạng này.

**3. SSRF qua tiêu đề Referer:**

* **Mô tả:** Một số ứng dụng sử dụng phần mềm phân tích phía máy chủ để theo dõi các lượt truy cập. Phần mềm này thường ghi lại tiêu đề Referer trong các request, và có thể request các URL từ tiêu đề này&#x20;
* **Chiến lược:** Tạo các request với tiêu đề Referer chứa các URL độc hại hoặc không mong muốn và kiểm tra xem ứng dụng có thực hiện các yêu cầu tới những URL đó không.

[^1]: **Loopback Network Interface** là một giao diện mạng ảo được sử dụng để kiểm tra và phát triển phần mềm mà không cần kết nối thực với mạng bên ngoài

[^2]: reserved IP address trỏ tới loopback adapter

[^3]: Tên thường được dùng cho loopback adapter
