flawopen.com/SSTI/Jinja2
Apakah render_template_string() Jinja2 aman?
Gunakan render_template_string() hanya jika kode aplikasi menetapkan string template secara tetap. Jika masukan yang tidak tepercaya disisipkan ke string itu sebelum Jinja mem-parsing-nya, terjadi SSTI. Pada lingkungan Jinja Flask bawaan tanpa sandbox, dampaknya dapat mencakup eksekusi kode, bergantung pada objek yang dapat dijangkau, konfigurasi, dan aplikasinya; hal ini tidak otomatis terjadi pada setiap deployment.
# All four are the same bug render_template_string(f"Hi {name}") render_template_string("Hi " + name) render_template_string("Hi %s" % name) render_template_string("Hi {}".format(name)) # A very common real-world shape: @app.errorhandler(404) def not_found(e): return render_template_string( f"<h1>No such page: " f"{request.path}</h1>" ), 404 # The URL path is attacker-controlled.
# Template is a literal; the user value # arrives as a named context variable render_template_string( "Hi {{ name }}", name=name ) # Better still, a real template file render_template("greeting.html", name=name) # For the 404 case, no template # evaluation is needed at all: return render_template("404.html", path=request.path), 404
Mengapa sumber template yang dikendalikan penyerang berisiko
Secara default, Flask menyediakan global aplikasi seperti config, request, dan session ke template. Jika penyerang mengendalikan sumber template, Jinja mengevaluasi ekspresinya menggunakan objek yang tersedia di lingkungan tersebut. Dampaknya bergantung pada objek dan kemampuan yang diekspos aplikasi. Ekspresi aritmetika yang tidak berbahaya dapat mengonfirmasi evaluasi, tetapi tidak dengan sendirinya membuktikan eksekusi kode atau data apa yang dapat diakses.
Template dapat mengekspos nilai sensitif jika aplikasi menaruhnya di konteks. Misalnya, config Flask dapat berisi SECRET_KEY atau pengaturan database, tetapi setiap deployment berbeda. Jangan menaruh rahasia dalam data yang terlihat oleh template dan jangan menganggap escaping output sebagai batas terhadap evaluasi template.
CVE-2024-56201 adalah kasus yang berbeda
Ini adalah kerentanan compiler Jinja yang terpisah dan bukan prasyarat SSTI biasa: CVE-2024-56201 berdampak pada Jinja 3.0.0 hingga 3.1.4 ketika penyerang dapat mengendalikan isi sekaligus nama template. Dalam kondisi tersebut, eksekusi kode Python arbitrer dimungkinkan meskipun sandbox digunakan. Jinja 3.1.5 memperbaikinya. Periksa advisori dan lakukan upgrade jika aplikasi menerima template atau nama dari penyerang.
Lokasi yang umum
Pola ini dapat muncul pada halaman error yang menampilkan path permintaan, fitur admin untuk template email, kustomisasi per tenant, serta endpoint pratinjau atau debug yang seharusnya tidak dipublikasikan.
Pertanyaan umum
Tidak. Autoescape meng-escape nilai yang dirender untuk mengurangi XSS pada output. Fitur ini tidak mencegah string dari pengguna dikompilasi sebagai sumber template. Keduanya menangani tahap yang berbeda.
Jinja menyediakan SandboxedEnvironment untuk template buatan pengguna, tetapi dokumentasinya memperingatkan bahwa sandbox bukan keamanan sempurna. Berikan hanya data yang diperlukan, hindari objek dengan efek samping, dan batasi CPU, memori, serta proses di luar mesin template. Sandbox tidak membuat interpolasi masukan tak tepercaya sebelum parsing menjadi aman.
Cari render_template_string dan pastikan argumen pertama merupakan string tetap yang dikendalikan aplikasi. Kirim nilai pengguna sebagai variabel konteks bernama atau gunakan file template. Tinjau juga API yang mengompilasi template secara dinamis dan jalur yang memungkinkan nama template dikendalikan.