Membongkar Client-Side Encryption: Dari Source Code Review hingga Automated Burp Extension

1. Pendahuluan #

Enkripsi sisi klien (client-side encryption) kerap dianggap sebagai solusi untuk melindungi data yang dikirimkan dari browser pengguna ke server. Namun, asumsi tersebut tidak sepenuhnya benar. Bagi seseorang yang memiliki kemampuan pemrograman, perangkat lunak Burp Suite, dan determinasi yang kuat, enkripsi sisi klien bukanlah penghalang yang signifikan.

Artikel ini mendokumentasikan proses reverse engineering mekanisme enkripsi pada sebuah aplikasi web melalui analisis source code dan keterampilan dasar pemrograman JavaScript (JS) serta Python. Penulis menulis code JavaScript untuk Proof of Concept (PoC) dekripsi, kemudian membuat ekstensi Burp Suite untuk mengotomatisasi proses dekripsi dan enkripsi ulang pada traffic API.

Catatan: Seluruh alur enkripsi-dekripsi fitur web dalam artikel ini telah direkayasa ulang (vibe-coded) untuk menjaga kerahasiaan pemilik aplikasi. Artikel ini disusun untuk tujuan edukasi semata.

2. Latar Belakang #

2.1 Identifikasi Masalah #

Dalam aktivitas pengujian penetrasi (penetration testing) pada sebuah aplikasi web, penulis menemukan bahwa seluruh parameter permintaan (request parameters) yang dikirimkan ke server dienkripsi. Sebagaimana diketahui, pekerjaan sehari-hari seorang Pentester memerlukan manipulasi data dari sisi klien. Keberadaan enkripsi ini secara teoritis akan menghambat proses pengujian tersebut.

2.2 Observasi Awal #

Aplikasi target merupakan sistem manajemen web dengan fungsionalitas login standar pada halaman depan. Setelah memperoleh kredensial yang valid, penulis melakukan percobaan login melalui proxy Burp Suite.

Hasil observasi menunjukkan bahwa request dikirimkan menggunakan Content-Type: multipart/form-data dengan nilai parameter “data” yang telah terenkripsi. Respons menampilkan “Login Berhasil” yang mengindikasikan kredensial valid dan proses autentikasi berhasil.

Temuan menarik lainnya adalah adanya endpoint /check yang dipanggil tepat sebelum proses login dilakukan.

Endpoint tersebut mengembalikan sebuah array bernama password yang berisi tiga indeks string. Hipotesis awal penulis adalah bahwa array tersebut berfungsi sebagai kunci enkripsi yang dihasilkan secara dinamis dari sisi server untuk digunakan pada setiap request POST.

3. Landasan Teori #

3.1 Kriptografi dalam Konteks Keamanan Aplikasi Web #

3.1.1 Definisi dan Tujuan Kriptografi #

Kriptografi berasal dari bahasa Yunani kryptos (tersembunyi) dan graphein (menulis), secara harfiah berarti “tulisan tersembunyi”. Dalam konteks keamanan informasi modern, kriptografi didefinisikan sebagai ilmu dan seni untuk mengamankan komunikasi dengan mentransformasikan data menjadi bentuk yang tidak dapat dibaca oleh pihak yang tidak berwenang (Stallings, 2017).

Tujuan fundamental kriptografi mencakup empat aspek keamanan informasi yang dikenal sebagai CIA Triad plus Authentication:

1. Confidentiality (Kerahasiaan): Memastikan bahwa informasi hanya dapat diakses oleh pihak yang berwenang
2. Integrity (Integritas): Menjamin bahwa data tidak dimodifikasi selama transmisi atau penyimpanan
3. Availability (Ketersediaan): Memastikan data tersedia saat dibutuhkan oleh pengguna yang berwenang
4. Authentication (Autentikasi): Memverifikasi identitas pengirim dan penerima informasi

3.1.2 Klasifikasi Algoritma Kriptografi #

Berdasarkan mekanisme kunci yang digunakan, algoritma kriptografi diklasifikasikan menjadi dua kategori utama:

a. Kriptografi Simetris (Symmetric Cryptography) Pada kriptografi simetris, kunci yang sama digunakan untuk proses enkripsi dan dekripsi. Karakteristik utama:

• Kecepatan proses tinggi (efisien untuk data bervolume besar)
• Kompleksitas distribusi kunci (kunci harus dikirimkan melalui kanal aman)
• Contoh algoritma: AES, DES, 3DES, Blowfish, ChaCha20

b. Kriptografi Asimetris (Asymmetric Cryptography) Menggunakan sepasang kunci berbeda: kunci publik untuk enkripsi dan kunci privat untuk dekripsi. Karakteristik utama:

• Mengatasi masalah distribusi kunci
• Kecepatan proses lebih lambat dibandingkan kriptografi simetris
• Contoh algoritma: RSA, ECC, DSA, ElGamal

Dalam aplikasi target, digunakan kriptografi simetris (AES) dengan mekanisme distribusi kunci melalui endpoint API.

3.2 Advanced Encryption Standard (AES) #

3.2.1 Sejarah dan Standarisasi #

AES merupakan algoritma enkripsi blok (block cipher) yang diadopsi sebagai standar enkripsi oleh National Institute of Standards and Technology (NIST) pada tahun 2001 melalui Federal Information Processing Standards Publication 197 (FIPS-197). AES dikembangkan oleh dua kriptografer Belgia, Vincent Rijmen dan Joan Daemen, dengan nama asli algoritma Rijndael.

AES menggantikan Data Encryption Standard (DES) yang dianggap tidak lagi aman karena panjang kunci 56-bit yang dapat dibobol dengan serangan brute force menggunakan komputasi modern.

3.2.2 Spesifikasi Teknis AES #

AES beroperasi pada blok data berukuran tetap 128 bit (16 byte) dengan tiga opsi panjang kunci:

• AES-128: Panjang kunci 128 bit (10 round)
• AES-192: Panjang kunci 192 bit (12 round)
• AES-256: Panjang kunci 256 bit (14 round)

Setiap round terdiri dari empat transformasi:

1. SubBytes: Substitusi non-linear menggunakan S-Box
2. ShiftRows: Pergeseran siklik pada setiap baris state
3. MixColumns: Pencampuran kolom menggunakan operasi dalam Galois Field
4. AddRoundKey: Operasi XOR antara state dengan round key

Pada aplikasi target, digunakan AES-256 dengan 14 round transformasi.

3.2.3 Mode Operasi Cipher Block Chaining (CBC) #

Karena AES adalah block cipher yang hanya memproses blok 128-bit, diperlukan mode operasi untuk mengenkripsi data yang lebih panjang. Cipher Block Chaining (CBC) merupakan salah satu mode operasi yang paling umum digunakan.

Mekanisme Enkripsi CBC:

C₀ = IV
Cᵢ = Eₖ(Pᵢ ⊕ Cᵢ₋₁)    untuk i = 1, 2, ..., n

Di mana:

• Pᵢ = blok plaintext ke-i
• Cᵢ = blok ciphertext ke-i
• Eₖ = fungsi enkripsi dengan kunci K
• ⊕ = operasi XOR
• IV = Initialization Vector

Mekanisme Dekripsi CBC:

Pᵢ = Dₖ(Cᵢ) ⊕ Cᵢ₋₁    untuk i = 1, 2, ..., n
P₁ = Dₖ(C₁) ⊕ IV

Karakteristik Mode CBC:

1. Dependensi antar blok: Setiap blok ciphertext bergantung pada blok sebelumnya, sehingga modifikasi pada satu blok akan memengaruhi dekripsi blok berikutnya
2. Randomisasi melalui IV: IV yang berbeda menghasilkan ciphertext berbeda meskipun plaintext dan kunci sama
3. Error propagation: Kesalahan pada satu blok ciphertext memengaruhi dekripsi dua blok (blok tersebut dan blok berikutnya)

Kerentanan Padding Oracle pada CBC: Mode CBC rentan terhadap serangan Padding Oracle jika implementasi tidak tepat, memungkinkan penyerang mendekripsi ciphertext tanpa mengetahui kunci (Vaudenay, 2002).

3.3 Key Derivation Function: PBKDF2 #

3.3.1 Entropi dalam Konteks Kriptografi #

Entropi dalam kriptografi mengukur tingkat ketidakpastian atau keacakan suatu nilai. Semakin tinggi entropi, semakin sulit nilai tersebut ditebak. Entropi diukur dalam satuan bit dan dihitung menggunakan formula:

H = log₂(N)

Di mana:

• H = Entropi (dalam bit)
• N = Jumlah kemungkinan kombinasi

Contoh Perhitungan Entropi Kata Sandi:

Perbandingan Entropi Berdasarkan Komposisi Karakter:

Standar Entropi untuk Keamanan:

• < 28 bit: Sangat lemah (dapat di-crack dalam hitungan detik)
• 28-35 bit: Lemah (rentan terhadap serangan brute force)
• 36-59 bit: Sedang (perlindungan minimal)
• 60-127 bit: Kuat (aman untuk sebagian besar aplikasi)
• ≥ 128 bit: Sangat kuat (standar kriptografis)

Kata sandi yang dipilih manusia umumnya memiliki entropi jauh di bawah nilai ideal karena kecenderungan menggunakan pola yang dapat diprediksi (kata umum, tanggal lahir, nama, dll.). Studi menunjukkan rata-rata kata sandi manusia hanya memiliki entropi sekitar 20-40 bit (Bonneau, 2012).

3.3.2 Definisi dan Kebutuhan KDF #

Key Derivation Function (KDF) adalah fungsi kriptografis yang menghasilkan satu atau lebih kunci rahasia dari nilai rahasia awal (seperti kata sandi atau kunci master). KDF dibutuhkan karena:

1. Kata sandi manusia memiliki entropi rendah — Seperti dijelaskan di atas, kata sandi yang dibuat manusia umumnya hanya memiliki 20-40 bit entropi, jauh di bawah 128-256 bit yang dibutuhkan algoritma enkripsi modern
2. Diperlukan kunci dengan panjang spesifik — Algoritma seperti AES-256 memerlukan kunci tepat 256 bit, sedangkan kata sandi memiliki panjang bervariasi
3. Perlu memperlambat serangan brute force — Dengan iterasi berulang, KDF meningkatkan waktu komputasi yang diperlukan untuk mencoba setiap kata sandi

3.3.3 Spesifikasi PBKDF2 #

Password-Based Key Derivation Function 2 (PBKDF2) didefinisikan dalam RFC 8018 (PKCS #5 v2.1). Fungsi ini menggunakan pseudorandom function (PRF) yang diaplikasikan secara iteratif.

Formulasi PBKDF2:

DK = PBKDF2(PRF, Password, Salt, c, dkLen)

Parameter:

• PRF: Pseudorandom function (umumnya HMAC-SHA1 atau HMAC-SHA256)
• Password: Kata sandi input
• Salt: Nilai acak untuk mencegah rainbow table attack
• c: Jumlah iterasi (iteration count)
• dkLen: Panjang kunci turunan yang diinginkan

Proses Derivasi:

DK = T₁ || T₂ || ... || Tₙ

Tᵢ = F(Password, Salt, c, i)
F(Password, Salt, c, i) = U₁ ⊕ U₂ ⊕ ... ⊕ Uₓ

U₁ = PRF(Password, Salt || INT(i))
U₂ = PRF(Password, U₁)
...
Uₓ = PRF(Password, Uₓ₋₁)

3.3.4 Parameter pada Aplikasi Target #

Pada aplikasi target, konfigurasi PBKDF2 yang digunakan:

• PRF: HMAC-SHA1
• Salt: Random 16 bytes (128 bit)
• Iteration count: 500 iterasi
• Output length: 256 bit (32 bytes)

Analisis Keamanan Parameter: Nilai iterasi 500 dianggap sangat rendah berdasarkan standar keamanan modern. OWASP merekomendasikan minimal 310,000 iterasi untuk PBKDF2-HMAC-SHA256 atau 120,000 untuk PBKDF2-HMAC-SHA1 (OWASP, 2023). Parameter yang lemah ini memudahkan serangan brute force pada kata sandi jika penyerang memperoleh hash.

3.4 Prinsip Enkripsi Sisi Klien vs Sisi Server #

3.4.1 Arsitektur Enkripsi Sisi Klien #

Enkripsi sisi klien (client-side encryption) adalah paradigma di mana proses enkripsi dilakukan pada perangkat pengguna (browser, aplikasi mobile) sebelum data dikirimkan ke server.

Komponen Arsitektur:

[Browser/Klien]
    │
    ├── JavaScript Crypto Library (CryptoJS, Web Crypto API)
    ├── Encryption Logic
    ├── Key Material (dari server atau hardcoded)
    │
    ▼
[Encrypted Data] ──HTTP/HTTPS──► [Server]

Skenario Penggunaan yang Tepat:

1. End-to-End Encryption (E2EE): WhatsApp, Signal, di mana server tidak memiliki akses ke kunci
2. Zero-Knowledge Proof: Layanan cloud storage seperti Tresorit
3. Client-Side Password Hashing: Sebelum pengiriman untuk login

3.4.2 Kelemahan Fundamental Enkripsi Sisi Klien #

Sebelum melangkah lebih jauh, perlu ditetapkan sebuah prinsip fundamental: ketika sebuah aplikasi (web maupun mobile) menggunakan enkripsi sisi klien untuk melindungi request-nya, implementasi enkripsi tersebut pasti berada pada sisi klien.

Konsekuensinya, jika kode tersebut berjalan pada perangkat pengguna, maka pengguna memiliki akses penuh terhadap logika tersebut. Kode tersebut, untuk semua keperluan praktis, dapat diinspeksi, direkayasa balik (reverse engineer), dan ditelusuri sepenuhnya.

Vektor Serangan pada Enkripsi Sisi Klien:

3.4.3 Kasus pada Aplikasi Target #

Pada aplikasi target, implementasi enkripsi sisi klien memiliki beberapa kelemahan kritis:

1. Distribusi Kunci melalui API: Kunci (atau komponen pembentuk kunci) didistribusikan melalui endpoint /check yang dapat di-intercept
2. Logika Enkripsi Terbuka: Seluruh algoritma enkripsi tersedia dalam file JavaScript yang dapat diakses
3. Tidak ada Autentikasi Server: Tidak ada verifikasi bahwa request /check dijawab oleh server yang sah
4. Format Ciphertext Terstruktur: Penggunaan delimiter dari array password memungkinkan parsing struktur ciphertext

3.5 Model Keamanan Browser dan JavaScript #

3.5.1 Same-Origin Policy dan Implikasinya #

Same-Origin Policy (SOP) adalah mekanisme keamanan fundamental pada browser yang membatasi interaksi dokumen atau skrip dari satu origin dengan sumber daya dari origin berbeda.

Origin didefinisikan oleh kombinasi:

• Protocol (http/https)
• Host (domain)
• Port

SOP tidak melindungi dari:

• Pengguna yang mengakses DevTools
• Ekstensi browser dengan permission tinggi
• Proxy intercepting (Burp Suite)
• Malware pada perangkat

3.5.2 Aksesibilitas Kode JavaScript #

Seluruh kode JavaScript yang dieksekusi pada browser dapat diakses oleh pengguna melalui:

1. View Source: Ctrl+U/Cmd+U atau menu konteks
2. Developer Tools: F12 atau Ctrl+Shift+I/Cmd+Shift+I
   • Sources/Debugger: Melihat dan men-debug kode
   • Network: Menganalisis lalu lintas jaringan
   • Console: Mengeksekusi JavaScript arbitrary
3. Browser Extensions: Modifikasi DOM dan JavaScript runtime
4. Proxy Tools: Burp Suite, mitmproxy, Fiddler

Obfuskasi Bukan Solusi: Teknik obfuskasi JavaScript (minifikasi, encoding, control flow flattening) hanya memperlambat proses reverse engineering, bukan mencegahnya. Tools seperti de4js, JStillery, dan bahkan AI modern dapat membantu deobfuskasi.

3.6 Pengujian Keamanan Aplikasi Web #

3.6.1 Metodologi Penetration Testing #

Penetration Testing (Pentest) adalah metode evaluasi keamanan sistem dengan mensimulasikan serangan dari perspektif penyerang. Metodologi standar yang diakui industri meliputi:

OWASP Testing Guide:

1. Information Gathering
2. Configuration and Deployment Management Testing
3. Identity Management Testing
4. Authentication Testing
5. Authorization Testing
6. Session Management Testing
7. Input Validation Testing
8. Error Handling Testing
9. Cryptography Testing
10. Business Logic Testing
11. Client-Side Testing

PTES (Penetration Testing Execution Standard):

1. Pre-engagement Interactions
2. Intelligence Gathering
3. Threat Modeling
4. Vulnerability Analysis
5. Exploitation
6. Post Exploitation
7. Reporting

3.6.2 Analisis Kriptografi dalam Konteks Pentest #

Dalam pengujian keamanan, evaluasi implementasi kriptografi mencakup:

1. Identifikasi Algoritma: Menentukan algoritma yang digunakan
2. Analisis Key Management: Bagaimana kunci dihasilkan, didistribusikan, dan disimpan
3. Evaluasi Parameter: Panjang kunci, mode operasi, padding scheme
4. Testing Implementation: Mencari kelemahan implementasi spesifik
5. Protocol Analysis: Menganalisis alur komunikasi enkripsi

3.7 Burp Suite sebagai Platform Pengujian #

3.7.1 Arsitektur Burp Suite #

Burp Suite adalah platform terintegrasi untuk pengujian keamanan aplikasi web yang dikembangkan oleh PortSwigger. Komponen utama:

Perbedaan Proxy History vs Logger:

Pemahaman perbedaan antara Proxy History dan Logger sangat penting dalam konteks penggunaan ekstensi yang memodifikasi request:

Dalam konteks artikel ini, ketika ekstensi Plainmaker mendekripsi request untuk ditampilkan di Proxy Intercept, pengguna melihat plaintext. Namun, sebelum request benar-benar dikirim ke server, ekstensi mengenkripsi ulang data tersebut. Logger mencatat request final yang terenkripsi, sehingga dapat digunakan untuk memverifikasi bahwa:

1. Ekstensi berhasil mengenkripsi ulang data yang dimodifikasi
2. Request yang diterima server tetap dalam format terenkripsi yang valid
3. Tidak ada data sensitif yang bocor dalam bentuk plaintext

3.7.2 Burp Suite Extender API #

Burp Suite Extender menyediakan API untuk mengembangkan ekstensi custom menggunakan Java atau Python (melalui Jython). Interface utama yang relevan:

// Interface utama untuk ekstensi
public interface IBurpExtender {
    void registerExtenderCallbacks(IBurpExtenderCallbacks callbacks);
}

// Interface untuk memodifikasi request/response
public interface IHttpListener {
    void processHttpMessage(int toolFlag, boolean messageIsRequest,
                           IHttpRequestResponse messageInfo);
}

// Interface untuk custom message editor
public interface IMessageEditorTabFactory {
    IMessageEditorTab createNewInstance(IMessageEditorController controller,
                                        boolean editable);
}

Kapabilitas Ekstensi:

• Intersepsi dan modifikasi request/response
• Custom encoding/decoding
• Session handling automation
• Custom scan checks
• Integration dengan tools eksternal

3.7.3 Plainmaker Framework #

Plainmaker adalah framework ekstensi Burp Suite yang dirancang untuk menangani skenario di mana aplikasi web menggunakan enkripsi atau encoding khusus pada request/response.

Fitur Utama Plainmaker:

1. Automatic Decryption: Mendekripsi request/response secara otomatis untuk ditampilkan di Proxy
2. Transparent Re-encryption: Mengenkripsi ulang sebelum request diteruskan ke server
3. Custom Logic Support: Mendukung implementasi logika enkripsi custom
4. Session Key Handling: Manajemen kunci yang berubah per sesi

Alur Kerja Plainmaker:

[Browser] ──Encrypted──► [Burp Proxy] ──► [Plainmaker Extension]
                                              │
                                              ├── decrypt_http_request()
                                              ├── [User modifies plaintext]
                                              └── encrypt_http_request()
                                              │
[Server] ◄──Encrypted──── [Burp Proxy] ◄──────┘

3.8 Manajemen Kunci Kriptografis #

3.8.1 Prinsip Kerckhoffs #

Prinsip Kerckhoffs (1883) menyatakan bahwa sistem kriptografi harus aman meskipun seluruh aspek sistem diketahui publik, kecuali kunci. Dengan kata lain, keamanan harus bergantung pada kerahasiaan kunci, bukan kerahasiaan algoritma.

Implikasi pada aplikasi web:

• Menggunakan algoritma yang sudah terstandarisasi (AES, RSA)
• Tidak mengandalkan obfuskasi kode untuk keamanan
• Fokus pada pengelolaan kunci yang aman

3.8.2 Key Lifecycle Management #

Siklus Hidup Kunci Kriptografis:

1. Key Generation: Pembuatan kunci dengan entropi yang cukup
2. Key Distribution: Distribusi aman ke pihak yang berwenang
3. Key Storage: Penyimpanan aman (HSM, secure enclave, encrypted at rest)
4. Key Usage: Penggunaan sesuai tujuan (enkripsi, signing)
5. Key Rotation: Pergantian kunci secara berkala
6. Key Revocation: Pencabutan kunci yang compromised
7. Key Destruction: Penghancuran kunci yang tidak digunakan

3.8.3 Kelemahan Key Management pada Aplikasi Target #

Pada aplikasi target, terdapat beberapa kelemahan kritis dalam manajemen kunci:

Kesimpulan Analisis: Implementasi pada aplikasi target melanggar prinsip fundamental manajemen kunci: kunci yang didistribusikan melalui kanal tidak aman (dapat di-intercept) tidak dapat memberikan keamanan yang berarti.

4. Konsep Perancangan #

4.1 Analisis Kode Sumber #

Langkah pertama adalah membuka Developer Tools (F12) pada browser. Dari bagian Debugger, terlihat struktur folder assets dan skrip JS. Seluruh berkas pada folder assets dan plugins (beserta subfolder) merupakan berkas pustaka (library), dinilai dari penamaannya. Berkas yang tampaknya berisi seluruh logika JS utama berada pada js/all.js?v=7.

Berdasarkan fakta bahwa sistem memanggil endpoint /check untuk mengambil kunci, maka pasti terdapat pemanggilan fetch/ajax/axios atau upaya pemanggilan API lainnya ke endpoint tersebut. Setelah menelusuri kode, ditemukan bahwa API dipanggil menggunakan ajax.

Dengan mencari pola $.ajax({, ditemukan bahwa endpoint /check dipanggil di dalam fungsi encrypt(). Pendekatan alternatif yang lebih intuitif adalah mencari kata kunci encrypt atau decrypt ketika mencari proses enkripsi.

4.2 Debugging Proses Enkripsi #

Untuk mendalami proses login dan enkripsi, Breakpoint ditempatkan pada baris 9 dan 69.

Breakpoint pada baris 9 merupakan baris pertama yang dieksekusi setelah fungsi dipanggil. Debugger menampilkan nilai setiap argumen: argumen pertama adalah formdata yang berisi plaintext username dan password, argumen kedua adalah callback yang memanggil fungsi submitData dengan parameter encData.

Setelah melanjutkan eksekusi, kode berlanjut ke Breakpoint berikutnya pada baris 69.

Sebelum mencapai baris tersebut, beberapa variabel telah diinisialisasi setelah mengambil array password dari endpoint /check sebagaimana ditunjukkan pada baris 25. Alur kode selanjutnya:

1. Menghasilkan salt menggunakan WordArray acak 16 byte
2. Menghasilkan key256Bits500Iterations yang diturunkan menggunakan PBKDF2
3. Mem-parsing indeks ketiga dari array password (password[2]) sebagai iv
4. Mengenkripsi plaintext username dan password (formdata) beserta iv, parameter tambahan &safer=, dan key256Bits500Iterations yang telah diturunkan ke dalam variabel Object bernama encrypted

Objek encrypted yang telah dihasilkan (terdiri dari ciphertext, iv, dan key) kemudian dikonversi ke base64 dengan variabel masing-masing.

Nilai terenkripsi akhir disimpan pada variabel encData dengan menggabungkan (concatenate) nilai berikut:

1. Base64 data
2. Indeks pertama password
3. Base64 IV
4. Indeks kedua password
5. Base64 Key
6. Indeks terakhir password

Baris 75 memanggil fungsi callback (submitData) untuk meneruskan data (data terenkripsi) ke request POST pada endpoint yang sesuai.

4.3 Perancangan Skrip Dekripsi #

Berdasarkan pemahaman proses enkripsi, dirancang skrip JavaScript untuk membalikkan proses tersebut:

const CryptoJS = require('crypto-js');

function decrypt(encryptedData, passwordArray) {
  const password0 = passwordArray[0];
  const password1 = passwordArray[1];
  const password2 = passwordArray[2];

  const [ciphertextPart, ivPartAndRest] = encryptedData.split(password0);
  console.log("ciphertextPart: ", ciphertextPart);
  console.log("ivPartAndRest: ", ivPartAndRest);

  const [ivPart, keyPartAndTail] = ivPartAndRest.split(password1);
  console.log("ivPart: ", ivPart);
  console.log("keyPartAndTail: ", keyPartAndTail);

  const [keyPart] = keyPartAndTail.split(password2);
  console.log("keyPart: ", keyPart);
  console.log("\n")

  const ciphertext = CryptoJS.enc.Base64.parse(ciphertextPart);
  const iv = CryptoJS.enc.Base64.parse(ivPart);
  const key = CryptoJS.enc.Base64.parse(keyPart);

  const decrypted = CryptoJS.AES.decrypt(
    { ciphertext: ciphertext },
    key,
    { iv: iv }
  );

  const plaintext = decrypted.toString(CryptoJS.enc.Utf8);
  return plaintext;
}

const passwordArray = ["cNNDKwU9zuSYnxxQgwlLaS6jETKvQgEW","ldhlizLJBXYSZ7NUdL7sYnCBRB2EMR0q","PSyyYziYe7CCcvSXWJN2rgd6gv6oHzLo"];

const encryptedData = "eQrCy843Ab5i6VstqZQvo9R9z6pM8wtxC8K+IvZzXPLvt1s7V9xR+XQjCSQzpXuQkxsO4dBevJeN15i9577DUQ==cNNDKwU9zuSYnxxQgwlLaS6jETKvQgEWAAAAAOfMDAAAAADWAAYAAA==ldhlizLJBXYSZ7NUdL7sYnCB";

console.log("plaintext: ", decrypt(encryptedData, passwordArray));

Logika dekripsi merupakan kebalikan dari proses enkripsi:

1. Array password disimpan ke dalam tiga variabel berbeda (password0, password1, password2)
2. encryptedData dipecah berdasarkan indeks pertama array password (password0) menjadi dua indeks
3. Indeks pertama (ciphertextPart) disimpan, sedangkan indeks kedua (ivPartAndRest) diteruskan untuk dipecah selanjutnya
4. ivPartAndRest dipecah berdasarkan indeks kedua array password (password1) menjadi dua indeks
5. Indeks pertama (ivPart) disimpan, sedangkan indeks kedua (keyPartAndTail) diteruskan untuk dipecah selanjutnya
6. keyPartAndTail dipecah berdasarkan indeks ketiga array password (password2), dengan hanya mengambil indeks pertama (keyPart)
7. Setiap bagian yang tersimpan (ciphertextPart, ivPart, dan keyPart) kemudian diteruskan ke argumen CryptoJS untuk didekripsi menjadi plaintext

4.4 Perancangan Ekstensi Burp Suite dengan Plainmaker #

Meskipun skrip dekripsi telah berhasil dibuat, diperlukan upaya tambahan untuk:

1. Mengintersepsi request yang sedang berjalan (terenkripsi)
2. Memperoleh array password dari /check dan memasukkannya ke skrip dekripsi
3. Memperoleh nilai terenkripsi dan memasukkannya ke skrip dekripsi
4. Memodifikasi nilai sesuai kebutuhan
5. Mengenkripsi ulang nilai request yang telah dimodifikasi dan mengirimkannya kembali ke server

Untuk mengotomatisasi proses tersebut, dipilih framework Plainmaker sebagai basis pengembangan ekstensi Burp Suite.

Rencana pengembangan ekstensi meliputi:

1. Mengintersepsi request
2. Mengekstrak kunci dari /check
3. Mendekripsi request
4. Memodifikasi request
5. Mengenkripsi ulang sebelum mengirim ke server

Pengembangan ekstensi ini dilakukan dengan kolaborasi bersama Bill Elim yang membantu proses debugging, kustomisasi kode Plainmaker, serta debugging RegEx.

Kode dasar Plainmaker dapat dilihat pada repositori resmi. Fungsionalitas dasar seperti pembaruan body dan headers pada request maupun respons telah ditangani oleh Plainmaker; fokus pengembangan hanya pada logika bisnis sesuai kasus.

Inisialisasi kelas ekstensi mencakup fungsi save dan load untuk menyederhanakan proses tulis-baca kunci ke berkas txt. Fungsi extract_multipart_field dan replace_multipart_field digunakan untuk mendapatkan pola nilai terenkripsi dalam parameter data pada format multipart/form-data.

Penanganan kasus khusus dilakukan untuk fitur yang mengirimkan request dengan content type application/x-www-form-urlencoded.

Fungsi bawaan Plainmaker untuk enkripsi atau modifikasi request-response diimplementasikan sebagai berikut:

Fungsi get_http_body merupakan fungsi bawaan untuk mendapatkan seluruh body request. Nilai tersebut kemudian diteruskan ke extract_data_param yang menangani content type (multipart field atau urlencoded field), mengenkripsi ulang nilai yang telah dimodifikasi, dan menggantikan nilai menggunakan fungsi replace_data_param.

Pada decrypt_http_request, nilai terenkripsi diekstrak menggunakan RegEx sebelumnya dan diteruskan ke fungsi decrypt_payload. Nilai yang telah didekripsi kemudian menggantikan ciphertext menggunakan fungsi replace_data_param.

Fungsi decrypt_http_response berfungsi untuk mengekstrak array password dari endpoint /check. Fungsi ini mengambil nilai path dari request dan mendeteksi apakah path berakhir dengan “/check”. Jika memenuhi kondisi tersebut dan mengandung string “password”, maka nilai array diekstrak dan disimpan ke berkas eksternal keys.txt.

Fungsi inti decrypt_payload dan encrypt_payload:

Logika utama serupa dengan kode JavaScript yang telah dibuat sebelumnya. Ditambahkan last_key dan last_iv untuk menyimpan bagian yang dipecah guna digunakan pada proses enkripsi, sementara array password yang diperoleh dari endpoint /check dimuat dari berkas keys.txt.

5. Hasil dan Pembahasan #

5.1 Implementasi dan Pengujian #

Setelah menyelesaikan skrip ekstensi, dilakukan pengujian dengan memuat ekstensi dan mencoba memanipulasi request.

Dengan kondisi telah login, dicari request POST lain yang berpotensi untuk dimanipulasi. Request asli yang belum dimodifikasi dikirim dan di-intercept.

Hasil menunjukkan bahwa request asli yang terenkripsi berhasil didekripsi secara otomatis (on the fly).

Dengan demikian, request dapat dimanipulasi secara bebas ke nilai apapun yang diinginkan.

Request yang telah dimodifikasi berhasil diterima oleh server.

5.2 Verifikasi Hasil #

Untuk memverifikasi lebih lanjut, request yang terkirim diperiksa pada tab Logger. Request plaintext yang telah dimodifikasi sebelumnya berhasil dienkripsi ulang secara otomatis oleh ekstensi.

Proses ini memberikan pengalaman yang serupa dengan “memiliki akses level kode sumber terhadap komunikasi black-box.”

5.3 Analisis Kerentanan #

Hasil pengujian mendemonstrasikan bahwa:

1. Enkripsi sisi klien tidak melindungi data dari penyerang yang memiliki akses ke peramban atau perangkat intersepsi
2. Logika kriptografis yang terekspos pada sisi klien dapat direkayasa balik sepenuhnya
3. Kunci yang didistribusikan melalui API (/check) dapat di-intercept dan digunakan untuk dekripsi
4. Ekosistem Burp Suite (dengan perangkat seperti Plainmaker) sangat powerful jika dimanfaatkan secara optimal

6. Kesimpulan dan Saran #

6.1 Kesimpulan #

Berdasarkan penelitian dan implementasi yang telah dilakukan, dapat disimpulkan bahwa:

1. Enkripsi tanpa penanganan kunci yang kuat hanyalah obfuskasi. Enkripsi sisi klien memberikan ilusi keamanan namun tidak memberikan perlindungan substansial terhadap penyerang yang memiliki kemampuan teknis.

2. Enkripsi sisi klien tidak dapat melindungi data dari penyerang yang memiliki akses ke peramban atau perangkat intersepsi lalu lintas jaringan.

3. Seluruh logika kriptografis yang diimplementasikan pada sisi klien dapat dan akan direkayasa balik oleh penyerang yang memiliki determinasi.

4. Otomatisasi proses dekripsi-enkripsi ulang dapat dicapai dengan memanfaatkan framework ekstensi Burp Suite seperti Plainmaker.

6.2 Saran #

1. Inspeksi JavaScript sisi klien harus selalu dilakukan untuk mencari material kunci atau logika kriptografis pada setiap pengujian keamanan aplikasi web.

2. Implementasi keamanan berlapis (defense in depth) sangat direkomendasikan, dengan tidak mengandalkan enkripsi sisi klien sebagai satu-satunya mekanisme perlindungan.

3. Pengelolaan kunci yang aman harus diimplementasikan pada sisi server dengan mekanisme yang tidak dapat diakses atau dimanipulasi dari sisi klien.

4. Tantangan untuk fase berikutnya: Pengembang mungkin akan menemukan isu ini dan melakukan minifikasi/obfuskasi kode sisi klien untuk mempersulit proses reverse engineering. Namun, hal tersebut tidak akan menjadi hambatan signifikan jika logikanya tetap sama, mengingat upaya obfuskasi dapat diatasi dengan memanfaatkan kecerdasan buatan (AI).

Referensi #

Standar dan Spesifikasi #

• NIST. (2001). FIPS 197: Advanced Encryption Standard (AES). National Institute of Standards and Technology.
• Kaliski, B. (2017). RFC 8018: PKCS #5: Password-Based Cryptography Specification Version 2.1. IETF.
• Dworkin, M. (2001). NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation. NIST.

Buku dan Literatur Akademis #

• Stallings, W. (2017). Cryptography and Network Security: Principles and Practice (7th ed.). Pearson.
• Ferguson, N., Schneier, B., & Kohno, T. (2010). Cryptography Engineering: Design Principles and Practical Applications. Wiley.
• Menezes, A. J., van Oorschot, P. C., & Vanstone, S. A. (1996). Handbook of Applied Cryptography. CRC Press.

Jurnal dan Publikasi #

• Bonneau, J. (2012). The Science of Guessing: Analyzing an Anonymized Corpus of 70 Million Passwords. 2012 IEEE Symposium on Security and Privacy, 538–552. https://doi.org/10.1109/SP.2012.49
• Vaudenay, S. (2002). Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS… Advances in Cryptology — EUROCRYPT 2002, LNCS 2332, 534–546.
• Daemen, J., & Rijmen, V. (2002). The Design of Rijndael: AES - The Advanced Encryption Standard. Springer.

Panduan Keamanan #

• OWASP. (2023). Password Storage Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
• OWASP. (2023). OWASP Web Security Testing Guide v4.2. https://owasp.org/www-project-web-security-testing-guide/
• PTES. (2014). Penetration Testing Execution Standard. http://www.pentest-standard.org/

Dokumentasi Teknis #

• PortSwigger. (2023). Burp Suite Documentation. https://portswigger.net/burp/documentation
• CryptoJS. (2023). CryptoJS Documentation. https://cryptojs.gitbook.io/docs/
• NordVPN. (2023). What is Password Entropy?. https://nordvpn.com/blog/what-is-password-entropy/

Sumber Praktis #

• Chrisandoryan. (2023). Plainmaker Framework. GitHub. https://github.com/chrisandoryan/Plainmaker
• Chrisandoryan. (2023). Plainmaker Source Code. GitHub. https://github.com/chrisandoryan/Plainmaker/blob/main/plainmaker.py

Artikel Original #

• Sultan, V. (2026, Maret 17). Web App Encryption Is Cute, Let Me Show You The Plaintext. Pulldown. https://pulldown.lat/web-app-encryption-is-cute-let-me-show-you-the-plaintext-2/