## SSTI (Server Side Template Injection) là gì?
- Trước khi tìm hiểu về lỗ hổng SSTI, ta cần phải biết được template là gì, và cách hoạt động của một template engine. Template là 1 mẫu bố cục chung cho tất cả các trang có sử dụng lại những thành phần giống nhau mà không phải viết lại toàn bộ, từ đó trên mỗi trang, chỉ cần thay đổi ở một số nơi được chỉ định trên trang từ template. Template engine được sinh ra nhằm mục đích làm sạch những đoạn code PHP trong phần Views, tức là những file HTML, từ đó dễ dàng xây dựng một trang HTML hơn.
- Một template engine sẽ nhận nhiệm vụ nhận thông tin đầu vào là dữ liệu đầu vào và khung mẫu giao diện, rồi sử dụng cú pháp (template syntax) để render thành một file HTML để trả về người dùng. Từ đó SSTI phát sinh.
- Lỗ hổng SSTI (Server Side Template Injection) là lỗ hổng bảo mật xảy ra khi ta có thể lợi dụng cú pháp của một template để thực thi những câu lệnh độc hại ở phía server
## Nguyên nhân dẫn đến SSTI:
- SSTI xảy ra khi dữ liệu nhập liệu của người dùng được kết hợp trực tiếp vào template thay vì đẩy vào như dữ liệu đơn thuần. Khi đó, người dùng hoàn toàn có thể đưa vào những template directive (tạm dịch là những câu lệnh chỉ đạo cho template hành động), từ đó thao túng template engine để chiếm quyền điều khiển ở server
- Lỗi này có thể là do bên phía nhà phát triển đã không kiểm soát kĩ đầu vào của người dùng trước khi render, hoặc là khi trang web cố tình cho phép người dùng submit hoặc edit các template.
- Ta hãy xét đến ví dụ sau: Một trang web cần gửi hàng loạt lời chào, và sử dụng Twig template để thuận tiện cho việc thay đổi tên khách hàng. Trong trường hợp sử dụng template tĩnh, tức là chỉ cung cấp các placeholder để engine lấy rồi xử lý và render ra web như dưới đây, Twig template sẽ hốt cái dữ liệu đẩy vào cái placeholder {first_name} để tạo ra nội dung chào hỏi người dùng theo kiểu:
```php!
$output = $twig->render("Dear {first_name},",array("first_name" => $user.first_name));
```
- Khi đó SSTI sẽ không có cửa nào vì thông tin đưa vào {first_name} chỉ là dữ liệu đơn thuần
- Nhưng nếu với template này, ta cho kết hợp trực tiếp dữ liệu của người dùng nhập vào trước khi xuất ra web page thì mọi chuyện sẽ hoàn toàn khác:
```php!
$output = $twig->render("Dear " . $_GET['name']);
```
- Lúc này, một phần của template không còn tĩnh nữa mà nó sẽ phụ thuộc vào tham số $_GET[‘name’]
- Vì vậy, nếu có một user nào truyền vào một thứ độc hại vào trong tham số này, server sẽ oẳng ngay.
## Hậu quả và cách khai thác lỗ hổng SSTI:
### Hậu quả:
- Với lỗ hổng SSTI, attacker có thể thi triển RCE (Thực thi code từ xa) rồi chiếm trọn quyền điều khiển server và mở rộng sang các đối tượng khác trong hệ thống
- Kể cả khi không thể RCE một cách triệt để, attacker cũng có thể vẫn có thể dùng SSTI để đọc những thông tin nhạy cảm của server, hoặc là lấy làm bàn đạp cho các cuộc tấn công khác như XSS, CSRF,…
### Quá trình khai thác lỗ hổng SSTI:
- Nhìn chung, một cuộc tấn công SSTI sẽ gồm 3 bước: Phát hiện, Nhận diện và Khai thác

1. Detect (Phát hiện):
- Ở bước này , ta sẽ thử nghiệm (fuzzing) ban đầu bằng các ký tự đặc biệt thường được dùng trong template expression như là `${{<%[%'”}}%\`
- Ta sẽ thử nghiệm chúng với một số toán tử như:
```php!=
{{7*7}}
${7*7}
<%=7*7%>
${{7*7}}
#{7*7}
*{7*7}
```
2. Identify (Nhận dạng):
- Sau khi biết được trang web có dính lỗ hổng SSTI, ta sẽ bắt đầu nhận dạng template mà trang web sử dụng theo biểu đồ sau:

3. Exploit (Khai thác):
- Để tiến hành khai thác thành công, ta chia bước khai thác thành 3 bước nhỏ hơn:
- Đầu tiên là Read, tức là cần phải đọc tài liệu về template syntax, về cách thức template xử lý dữ liệu, và tài liệu về những người đã khai thác trước đó đã viết.
- Sau đó là Explore, tìm hiểu về các đối tượng liên quan và môi trường tấn công, đồng thời thử Bruteforce các tên biến. Các object do nhà phát triển cung cấp có khả năng chứa các thông tin nhạy cảm(có thể sử dụng wordlist từ SecLists và Burp Intruder)
- Cuối cùng là attack, áp dụng những gì đã đọc và tìm hiểu để tiến hành thực thi trên trang web
### Demo: Lab SSTI
#### Giới thiệu:
- Đây là lab chứa lỗ hổng SSTI mà em và người đóng góp chủ yếu là [Âu Quang Đức](https://github.com/Twil4) thực hiện nhằm để luyện tập khai thác lỗ hổng này và là tư liệu để em phát triển các trang web khác không bị dính phải lỗ hổng SSTI tương tự như thế này
- Trang web này sử dụng ngôn ngữ PHP, HTML, CSS, JavaScript, Twig template và Dockerfile để chạy trên local
#### Tính năng:
- Đây là một trang web đơn giản chứa hình ảnh mèo và chức năng xem thêm nếu muốn biết thêm thông tin chi tiết về mèo con:

- Khi ấn vào xem thêm thì trang web sẽ hiện ra ảnh full đồng thời một vài mô tả về hình mèo đó:

- Vì bọn em phân loại ID theo tên trực tiếp trên URL để xổ ra tên mèo ở bên trên cùng, cùng với việc GET thẳng thằng này vào trong template Twig nên trang web đã bị dính lỗ hổng SSTI, đầu tiên ta sẽ test với payload kinh điển `{{7*'7'}}`:

- Kết quả ra 49, không còn nghi ngờ gì nữa, trang web đã bị dính SSTI. Sau đó ta sẽ quan sát file Docker, để ý rằng file file flag.txt được copy vào thư mục gốc "/".
```dockerfile!=
COPY flag.txt /
```
- Nên em sẽ sử dụng payload `{{['ls /']|filter('system')}}` nhằm liệt kê ra các file có trong thư mục gốc của hệ thống:

- Đã có sự xuất hiện của flag.txt, giờ ta thực hiện `car /flag.txt` để đọc nội dung và lấy flag:

- Như vậy, flag của lab là: **KMA{3asy_tw1g_php_sst1_la6}**
#### Tổng kết:
- Đây là một lab dính SSTI ở mức độ cơ bản cho ta biết được độ nguy hiểm khi cho thẳng biến `ID` vào bên trong template mà chưa qua kiểm duyệt. Để phòng tránh SSTI, ta cần phải gán vào template theo dạng tĩnh, đồng thời tiến hành kiểm tra và filter đầu vào của người dùng, ví dụ như sử dụng blacklist để lọc các ký tự không an toàn:

- Lưu ý mỗi template sẽ có cách khai thác khác nhau, nên hãy chú ý và blacklist những ký tự đặc biệt tương ứng với template mà ta sử dụng.
- Chi tiết xem thêm tại: https://github.com/yasuololmontage/LabSSTI
## Cách phòng chống:
- Không cho người dùng được phép tạo hoặc edit template. Tuy nhiên trong một số trường hợp thì việc này không thể tránh khỏi
- Kiểm tra và xác thực đầu vào của người dùng bằng cách sử dụng: regex, blacklist, whitelist, ...
- Sử dụng “logic-less” template như Mustache nhằm tránh thực hiện được các biểu thức logic nhất có thể.
- Chỉ thực hiện câu lệnh của người dùng ở trong môi trường cô lập khi những mô đun và chức năng nguy hiểm đã bị loại bỏ. Nhưng việc cô lập câu lệnh chưa xác thực vốn đã khó và thường có thể bị bypass
- Áp dụng cách cô lập của riêng bạn bằng cách tạo môi trường template ở trong một Docker container bị khóa chặt
## Nguồn và tài liệu tham khảo:
- [Nhập Môn SSTI](https://dummytip.com/penetration-testing-step-3-nhap-mon-server-side-template-injection-ssti/)
- [PortSwigger SSTI Guide](https://portswigger.net/web-security/server-side-template-injection#how-to-prevent-server-side-template-injection-vulnerabilities)
- [Viblo ssti](https://viblo.asia/p/server-side-template-injection-YWOZrxvy5Q0)
- [HackMD Mạc Hồng Nam](https://hackmd.io/@machongnam/Task_9_SSTI)
- [Gitbook](https://gitbook.seguranca-informatica.pt/fuzzing-and-web/server-side-template-injection-ssti)
- [HackTricks](https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection)
- [PayloadAllTheThing](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection)
- [Mustache](https://mustache.github.io/mustache.5.html)
- [Template Engine](https://nentang.vn/app/edu/khoa-hoc/thiet-ke-lap-trinh-web-backend/khoa-hoc-backend-thiet-ke-web-voi-laravel/lessons/template-engine-la-gi#_teamplete-engine-la-gi-1)