Rate this post

Chào mọi người! Trong bài viết hôm nay, chúng ta sẽ cùng nhau khám phá một khái niệm có thể còn mới mẻ nhưng vô cùng quan trọng trong lĩnh vực an ninh mạng: Server-side Template Injection (SSTI). Bạn đã bao giờ nghe nói về nó chưa? Nếu chưa, đừng lo lắng, bởi chúng ta sẽ cùng nhau hiểu rõ hơn về nó ngay bây giờ.

Đầu tiên, hãy cùng nhau tìm hiểu định nghĩa cơ bản về SSTI. Một cách ngắn gọn, SSTI là một loại lỗ hổng bảo mật xảy ra khi một ứng dụng web sử dụng các template engine (một công cụ xử lý mẫu trong lập trình web) một cách không an toàn. Điều này cho phép kẻ tấn công có thể ‘chèn’ hoặc ‘inject’ mã độc vào trong template, và từ đó thực thi các lệnh không mong muốn trên máy chủ. Nghe có vẻ phức tạp? Hãy nghĩ đến nó như việc viết một câu chuyện ngắn, nhưng ai đó lại thêm vào đó một đoạn văn không liên quan, làm thay đổi hoàn toàn ý nghĩa của câu chuyện.

Giờ đây, bạn có thể tự hỏi, SSTI khác gì so với các loại Injection khác như SQL Injection hay XSS? Điểm khác biệt chính nằm ở “sân chơi” của chúng. Trong khi SQL Injection tập trung vào việc tấn công các cơ sở dữ liệu thông qua các truy vấn SQL, và XSS nhắm vào việc chèn mã độc vào trang web, thì SSTI lại tập trung vào việc thao túng template engine của máy chủ. Điều này có nghĩa là SSTI có thể trực tiếp tác động đến cách máy chủ xử lý và hiển thị thông tin, mở ra một loạt các rủi ro bảo mật khác nhau.

Vậy là chúng ta vừa cùng nhau khám phá sơ lược về SSTI – một khái niệm không chỉ thú vị mà còn vô cùng quan trọng trong thế giới an ninh mạng. Hiểu rõ về SSTI không chỉ giúp chúng ta bảo vệ thông tin cá nhân và doanh nghiệp mình một cách hiệu quả hơn, mà còn giúp chúng ta tiếp cận và xử lý các vấn đề an ninh mạng một cách thông minh hơn. Hãy tiếp tục theo dõi những bài viết tiếp theo để tìm hiểu sâu hơn về SSTI và cách để phòng tránh nó nhé!

Giới thiệu về Server-side Template Injection

Đầu tiên, hãy bắt đầu với cái nhìn tổng quan về Template Engines. Trong lập trình web, ‘Template Engine’ là một công cụ giúp chúng ta tạo ra các trang web động một cách dễ dàng và hiệu quả. Bạn có thể hiểu đơn giản rằng, thay vì viết mã HTML cứng nhắc, Template Engine cho phép chúng ta sử dụng các mẫu (templates) có thể tái sử dụng và thêm dữ liệu động vào trang web của mình. Điều này giúp cho việc phát triển web trở nên linh hoạt và nhanh chóng hơn rất nhiều.

Tiếp theo, cách thức hoạt động của một Template Engine như thế nào? Khi một trang web được yêu cầu, Template Engine sẽ ‘xử lý’ template, thay thế các placeholder bằng dữ liệu thực tế, và tạo ra mã HTML cuối cùng để gửi về trình duyệt. Quy trình này diễn ra ở phía máy chủ (server-side), nên chúng ta gọi nó là ‘Server-side Template Engine’.

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.

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!

Vậy là chúng ta đã cùng nhau tìm hiểu một số thông tin cơ bản về Server-side Templates và Template Engines. Hiểu rõ về những công cụ này không chỉ giúp chúng ta tạo ra các trang web động và hấp dẫn hơn, mà còn là nền tảng quan trọng để phòng chống các loại tấn công như SSTI. Hãy tiếp tục theo dõi để khám phá thêm nhiều thông tin hữu ích khác trong lĩnh vực phát triển web!

Cơ chế và nguyên nhân của Server-side Template Injection

Đầu tiên, chúng ta cần hiểu cách thức mà SSTI xảy ra. Điều này thường diễn ra trong quá trình xử lý của template engine. Khi một ứng dụng web nhận dữ liệu đầu vào từ người dùng và chuyển nó qua template engine mà không có bất kỳ kiểm soát hoặc lọc dữ liệu nào, đó là lúc SSTI có thể xảy ra. Một ví dụ điển hình là khi dữ liệu đầu vào được đưa trực tiếp vào template mà không kiểm tra hoặc thoát khỏi các ký tự đặc biệt, cho phép các script độc hại được thực thi.

Bây giờ, hãy nói về nguyên nhân phổ biến dẫn đến lỗ hổng này. Một trong những nguyên nhân chính là việc nhập liệu không được xác thực hoặc lọc kỹ lưỡng. Khi các nhà phát triển không áp dụng các biện pháp bảo mật như kiểm tra và lọc dữ liệu đầu vào, họ tạo ra một cơ hội cho kẻ tấn công. Một nguyên nhân khác có thể là do sử dụng các template engine lỗi thời hoặc cấu hình không chính xác, điều này có thể tạo ra các lỗ hổng không dễ dàng nhận biết.

Điều quan trọng cần nhớ là SSTI không chỉ đơn giản là một sơ hở nhỏ; nó có thể mở ra cánh cửa cho các loại tấn công nghiêm trọng khác như thực thi mã độc từ xa hoặc chiếm quyền kiểm soát hệ thống máy chủ. Điều này làm tăng đáng kể mức độ rủi ro và nguy hiểm mà SSTI có thể mang lại.

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.

Công cụ

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Contact Me on Zalo
Call now