Mengapa JSON.stringify Tidak Seaman yang Terlihat?
Para pengembang menggunakan JSON.stringify setiap hari untuk menserialisasi data, mengirim objek melalui jaringan, menyimpan status dalam file, atau menyimpan konfigurasi. Namun, panggilan ke JSON.stringify yang tampaknya tidak berbahaya itu dapat menimbulkan deserialisasi yang tidak aman jika data tersebut kemudian dihidrasi kembali tanpa validasi.
Masalahnya bukan pada JSON.stringify itu sendiri, tetapi bagaimana kita salah menggunakannya. Ketika Anda menserialisasi objek kompleks (terutama dengan prototipe atau instance kelas) dan kemudian secara membabi buta mendeserialisasinya menggunakan JSON.uraiAnda berisiko mengaktifkan muatan berbahaya di dalam aplikasi Anda.
Dalam JavaScript, mudah untuk berasumsi bahwa apa yang di-serialisasi itu aman karena "hanya" JSONNamun JSON adalah data, bukan logika. Jika penyerang mengendalikan data tersebut, mereka dapat mengeksploitasi batasan kepercayaan dalam kode Anda. Di sinilah deserialisasi yang tidak aman dimulai.
Kesalahan Umum Pengembang yang Memungkinkan Deserialisasi yang Tidak Aman
Deserialisasi yang tidak aman biasanya berasal dari kebiasaan yang tampak tidak berbahaya dalam tinjauan kode. Tetapi ketika JSON.stringify digunakan secara sembarangan, permukaan serangan meluas.
Praktik tidak aman: Melakukan serialisasi input pengguna yang belum divalidasi
⚠️Peringatan: Pola ini menserialisasi input yang dikendalikan penyerang tanpa validasi apa pun. Hal ini dapat menyebabkan deserialisasi yang tidak aman jika data tersebut kemudian dipercaya.
// Node.js example const userData = req.body; // attacker-controlled fs.writeFileSync('userdata.json', JSON.stringify(userData)); ⚠️Peringatan: Melakukan deserialisasi data yang sama tanpa validasi dapat memasukkan kembali muatan data ke dalam aplikasi Anda.
const input = JSON.parse(fs.readFileSync('userdata.json')); doSomething(input); // Trusting it blindly Pola berbahaya: Menggunakan kembali JSON di seluruh batasan kepercayaan.
JSON yang diserialisasi yang dibuat dalam satu layanan (lingkungan pengembangan) digunakan kembali di layanan lain (produksi), tanpa validasi. Hal ini sering terjadi pada alat internal atau layanan mikro.
Contoh risiko tersembunyi dalam Python:
⚠️Peringatan: Baik langkah serialisasi maupun deserialisasi di bawah ini menangani data yang berpotensi tidak tepercaya tanpa validasi.
import json def save_user_input(data): with open('input.json', 'w') as f: f.write(json.dumps(data)) def process_input(): with open('input.json') as f: data = json.loads(f.read()) execute_logic(data) # Dangerous if data structure is assumed Kedua contoh tersebut melakukan serialisasi dan deserialisasi data yang dikontrol pengguna tanpa penegakan skema. Ini adalah lahan subur bagi eksploitasi deserialisasi yang tidak aman yang dipicu oleh penggunaan JSON.stringify yang ceroboh.
Risiko Nyata dalam Pipelines: Dari Kode ke CI/CD Alur Deserialisasi
Sekarang, terapkan perilaku tersebut ke dalam sebuah pipeline. Ketika JSON.stringify disalahgunakan di dalam CI/CD Dengan menggunakan alur kerja, Anda mengekspos proses build Anda pada risiko deserialisasi yang tidak aman. Hal ini sering terjadi pada metadata artefak, perlengkapan pengujian, dan snapshot konfigurasi.
Umum CI/CD jebakan:
- Pembuatan artefak yang tidak aman: Artefak build mencakup objek yang diserialisasi yang digunakan kembali di berbagai job tanpa validasi.
- Variabel lingkungan yang diserialisasi: Tim menyimpan variabel lingkungan sebagai JSON yang diserialisasi dan menggunakannya kembali di berbagai tahapan atau bahkan proyek.
- Data uji yang disuntikkan: Data uji yang dideserialisasi dari sumber yang tidak tepercaya commitatau cabang yang dieksekusi tanpa pemeriksaan tipe.
Pola-pola ini memudahkan penyerang untuk menyuntikkan muatan berbahaya ke dalam sistem tepercaya. pipelinemenggunakan logika stringifikasi JSON yang dimanipulasi.
⚠️Peringatan:Alur kerja ini meneruskan data yang telah diserialisasi tanpa validasi. Jika test-runner.js tidak memvalidasi input, ada risiko deserialisasi yang tidak aman.
# YAML example in GitHub Actions steps: - name: Load test data run: | echo '${{ secrets.TEST_JSON }}' > test.json node test-runner.js test.jsonIf test-runner.js Jika memuat dan mengurai JSON tanpa validasi, hal itu dapat memicu deserialisasi yang tidak aman.
Mengamankan JSON.stringify dengan Validasi dan Penguraian yang Aman
Solusinya bukanlah menghindari JSON.stringify, tetapi menggunakannya dengan hati-hati dan menerapkan pemeriksaan keamanan secara konsisten. Jika ditangani dengan benar, itu aman, tetapi di era modern pipelines, asumsi-asumsi cepat runtuh.
Praktik DevSecOps untuk mengamankan JSON.stringify:
- Gunakan skema JSON untuk memvalidasi data yang diserialisasi dan dideserialisasi.
- Terapkan pengetikan yang ketat, hindari pengetikan sembarangan atau asumsi tentang bentuk objek.
- Gunakan pustaka penguraian yang aman yang mendukung penegakan skema atau pengaman tipe.
- Perlakukan data yang diserialisasi sebagai data yang tidak tepercaya, meskipun berasal dari repositori tepercaya.
- Instrumen pipelineuntuk mendeteksi pola JSON.stringify yang berisiko sejak dini.
Praktik Terbaik: Contoh ini menggunakan validasi skema JSON untuk mencegah deserialisasi yang tidak aman. Contoh penggunaan ajv di Node.js:
const Ajv = require("ajv"); const ajv = new Ajv(); const schema = { type: "object", properties: { id: { type: "number" } }, required: ["id"] }; const validate = ajv.compile(schema); const input = JSON.parse(fs.readFileSync('input.json')); if (!validate(input)) throw new Error("Invalid input"); Deserialisasi yang aman berarti memvalidasi sebelum Percaya. Jangan mengandalkan JSON. Secara default, stringify dirancang untuk menjaga keamanan Anda; tentukan seperti apa keamanan itu.
Mendeteksi Risiko Serialisasi dengan Xygeni
Audit manual hanya dapat mendeteksi sebagian kecil masalah. Xygeni memberikan visibilitas tentang bagaimana JSON.stringify digunakan di seluruh basis kode Anda dan pipelines.
Apa yang dilakukan Xygeni:
- Jejak JSON.stringify penggunaan dari kode sumber hingga penerapan.
- Mendeteksi alur deserialisasi yang tidak aman, terutama di seluruh layanan mikro dan pipeline tahapan.
- Menandai serialisasi data yang tidak aman seperti variabel lingkungan, input pengguna, atau artefak.
- Peringatan tentang penyimpangan pola, yang menunjukkan kapan data serial berubah bentuk atau melampaui batas kepercayaan.
Visibilitas semacam ini sangat penting ketika berurusan dengan risiko deserialisasi yang tidak aman yang ditimbulkan oleh JSON.stringify, terutama dalam CI/CD sistem di mana data serial bergerak cepat dan senyap.
Mengamankan JSON.stringify: Perisai Anda Terhadap Deserialisasi yang Tidak Aman
JSON.stringify sendiri tidaklah tidak aman. Namun, jika digunakan tanpa kehati-hatian, ia menjadi pintu gerbang menuju deserialisasi yang tidak aman.
Jika Anda seorang pengembang yang bekerja dengan JSON:
- Lakukan audit terhadap penggunaan fitur tersebut di seluruh layanan, pipelines, dan alat-alat.
- Perlakukan data yang telah dideserialisasi sebagai data yang tidak tepercaya.
- Terapkan validasi skema, tegakkan tipe data, dan integrasikan keamanan ke dalam sistem Anda. CI/CD.
Dan jangan hanya berhenti pada praktik terbaik, gunakan Xygeni untuk melacak, mendeteksi, dan menghentikan risiko deserialisasi yang tidak aman sebelum sampai ke lingkungan produksi. Serialisasi bukanlah hal yang netral. Manfaatkanlah hal tersebut dengan bijak. JSON.stringify aman.
