Các ứng dụng web thường sử dụng công nghệ tạo templating phía máy chủ (Jinja2, Twig, FreeMaker, v.v.) để tạo các phản hồi HTML động. Lỗ hổng Chèn mẫu phía máy chủ (SSTI) xảy ra khi đầu vào của người dùng được nhúng vào mẫu theo cách không an toàn và dẫn đến việc thực thi mã từ xa trên máy chủ. Bất kỳ tính năng nào hỗ trợ đánh dấu nâng cao do người dùng cung cấp có thể dễ bị tấn công bởi SSTI bao gồm các trang wiki, đánh giá, ứng dụng tiếp thị, hệ thống CMS, v.v. Một số công cụ mẫu sử dụng các cơ chế khác nhau (ví dụ: hộp cát, cho phép liệt kê, v.v.) để bảo vệ chống lại SSTI.
Các bài viết liên quan:
Example – Twig
Ví dụ sau đây là một đoạn trích từ dự án Ứng dụng web cực kỳ dễ bị tổn thương.
public function getFilter($name)
{
[snip]
foreach ($this->filterCallbacks as $callback) {
if (false !== $filter = call_user_func($callback, $name)) {
return $filter;
}
}
return false;
}Trong hàm getFilter, call_user_func ($ callback, $ name) dễ bị tấn công bởi SSTI: tham số name được tìm nạp từ yêu cầu HTTP GET và được thực thi bởi máy chủ:
Example – Flask/Jinja2
Ví dụ sau sử dụng công cụ tạo templating Flask và Jinja2. Hàm trang chấp nhận tham số “name” từ một yêu cầu HTTP GET và hiển thị phản hồi HTML với nội dung biến name:
@app.route("/page")
def page():
name = request.values.get('name')
output = Jinja2.from_string('Hello ' + name + '!').render()
return outputĐoạn mã này dễ bị tấn công bởi XSS nhưng nó cũng dễ bị tấn công bởi SSTI. Sử dụng phần sau làm trọng tải trong tham số tên:
$ curl -g 'http://www.target.com/page?name={{7*7}}'
Hello 49!Mục tiêu kiểm tra
Phát hiện các điểm dễ bị tổn thương khi tiêm mẫu.
Xác định động cơ tạo templating.
Xây dựng khai thác.
Làm thế nào để kiểm tra
Các lỗ hổng SSTI tồn tại trong văn bản hoặc ngữ cảnh mã. Trong ngữ cảnh văn bản rõ ràng, người dùng được phép sử dụng “văn bản” dạng tự do với mã HTML trực tiếp. Trong ngữ cảnh mã, đầu vào của người dùng cũng có thể được đặt trong một câu lệnh mẫu (ví dụ: trong một tên biến)
Xác định lỗ hổng Template Injection
Bước đầu tiên trong việc kiểm tra SSTI trong ngữ cảnh văn bản rõ ràng là xây dựng các biểu thức mẫu phổ biến được sử dụng bởi các công cụ mẫu khác nhau làm trọng tải và theo dõi phản hồi của máy chủ để xác định biểu thức mẫu nào đã được máy chủ thực thi.
Các ví dụ về biểu thức mẫu phổ biến:
a{{bar}}b
a{{7*7}}
{var} ${var} {{var}} <%var%> [% var %]Trong bước này, bạn nên sử dụng danh sách chuỗi / tải trọng thử nghiệm biểu thức mẫu mở rộng.
Kiểm tra SSTI trong ngữ cảnh mã hơi khác một chút. Đầu tiên, người kiểm tra xây dựng yêu cầu dẫn đến phản hồi trống hoặc phản hồi của máy chủ lỗi. Trong ví dụ bên dưới, thông số HTTP GET được chèn vào thông tin biến cá nhân_greeting trong một câu lệnh mẫu:
personal_greeting=username Hello user01
Sử dụng trọng tải sau – phản hồi của máy chủ trống “Xin chào”:
personal_greeting=username<tag> Hello
Trong bước tiếp theo là thoát ra khỏi câu lệnh mẫu và chèn thẻ HTML sau thẻ bằng cách sử dụng trọng tải sau
personal_greeting=username}}<tag> Hello user01 <tag>
Xác định Templating Engine
Dựa trên thông tin từ bước trước, bây giờ người thử nghiệm phải xác định công cụ mẫu nào được sử dụng bằng cách cung cấp các biểu thức mẫu khác nhau. Dựa trên phản hồi của máy chủ, người thử nghiệm suy ra công cụ mẫu được sử dụng. Cách tiếp cận thủ công này được thảo luận chi tiết hơn trong bài viết PortSwigger này. Để tự động hóa việc xác định lỗ hổng SSTI và công cụ tạo templating, có nhiều công cụ khác nhau bao gồm Tplmap hoặc tiện ích mở rộng Backslash Powered Scanner Burp Suite.
Xem thêm Kiểm tra lỗ hổng bảo mật Weak Transport Layer Security
Xây dựng RCE Exploit
Mục tiêu chính trong bước này là xác định để giành được quyền kiểm soát hơn nữa trên máy chủ bằng cách khai thác RCE bằng cách nghiên cứu và nghiên cứu tài liệu mẫu. Các lĩnh vực quan tâm chính là:
- Đối với các phần tác giả mẫu bao gồm cú pháp cơ bản.
- Các phần cân nhắc về bảo mật.
- Danh sách các phương thức, hàm, bộ lọc và biến được tích hợp sẵn.
- Danh sách các tiện ích mở rộng / plugin.
Người kiểm tra cũng có thể xác định những đối tượng, phương pháp và thuộc tính nào khác có thể được tiếp xúc bằng cách tập trung vào đối tượng chính. Nếu đối tượng self không có sẵn và tài liệu không tiết lộ các chi tiết kỹ thuật, thì nên sử dụng tên biến. Khi đối tượng được xác định, bước tiếp theo là lặp qua đối tượng để xác định tất cả các phương thức, thuộc tính và thuộc tính có thể truy cập thông qua công cụ mẫu. Điều này có thể dẫn đến các loại phát hiện bảo mật khác bao gồm báo cáo đặc quyền, tiết lộ thông tin về mật khẩu ứng dụng, khóa API, cấu hình và biến môi trường, v.v.
