Membongkar Obfuscated JavaScript di Web App: Reversing Client-Side Crypto & Replay Attack

Karjok Pangesty (2026-04-26T20:25:21.788198) on linux

Developer aplikasi web yang paham security punya banyak cara untuk menangkal serangan di website yang mereka buat. Mulai dari nerapin secure code, nambahin mekanisme captcha, pake firewall & WAF, pake csrf, atau bahkan nerapin mekanisme crypto yang kuat.

Tapi nggak sedikit juga yang bodo amat sama security dan berpikir yang penting service dia jalan. Apa lagi era AI yang udah ga masuk akal ini, penggunaan AI di dunia web development juga menambah resiko di dunia cyber security, khususnya bagi developer yang tidak paham dengan security. Mereka cuma tau web nya jadi dan ga paham apa yang sebenarnya bisa jadi celah hacker masuk ke sistem mereka.

Untuk meningkatkan kesadaran akan keamanan siber khususnya di web, gw sudah menyiapkan "secure web" yang sebenernya ngga secure untuk gw jadikan bahan praktik pada artikel gw yang pertama ini. Kalau kalian mau mengikuti langkah demi langkah apa yang gw tulis di artikel ini atau sekedar pengen tau gimana web "secure" yang kita jadikan target kali ini bekerja, bisa kalian cek codenya di github gw: https://github.com/karjok/pentestlab/tree/main/secure-but-unsecure

INFO

Cara yang gw lakukan di artikel ini tidak bisa diterapkan di semua kondisi karena mungkin akan beda-beda di tiap web. Tapi setidaknya kita bisa tau dasar teorinya. Entahlah, intinya gitu. wkwkwk

Apa Itu Reverse Engineering di Aplikasi Web?

Sederhananya, kita membongkar, menganalisa, dan mempelajari software atau program yang sudah ada tanpa memiliki akses ke kode sumber aslinya dengan tujuan memahami cara kerjanya, desain atau fungsionalitasnya. Di dunia cyber security, kegiatan ini penting karena nggak semua aplikasi atau program yang akan dipentest, atau perusahaan yang nyuruh kita buat pentest ngasih kode asli yang bisa kita analisa langsung. Biasanya ketika pentest blackbox atau greybox.

Misalnya, website yang kode JavaScriptnya di obfuscate, ini agak sulit dibaca secara langsung tanpa kita pelajari dulu pelan-pelan apa isinya dan bagaimana cara kerjanya. Selain itu, jadi penghalang juga untuk kegiatan test selanjutnya, misalkan jika webnya menerapkan anti replay attack, yang mana request hanya bisa dikirim sekali dan nggak valid ketika dikirim ulang. Kondisi seperti itu bakalan bikin kita kesulitan untuk testing lanjutan, misalnya test SQL injection, IDOR atau kerentanan lainnya.

Kenapa JavaScript Obfuscation Tidak Menjamin Keamanan Web?

Kalau prinsip gw, Selagi kode itu masih bisa jalan normal, berati masih ada kemungkinan untuk bisa dianalisa bagaimana cara kerjanya. Misalnya obfuscating. Memang kodenya terlihat berantakan dan membingungkan (memang itu tujuannya), tapi kode itu masih bisa jalan. Berarti, masih ada peluang untuk menganalisa kodenya, tergantung dari skill dan pengalaman si pentester itu sendiri. Prinsip ini juga mungkin bisa kalian pakai ketika menganalisa kode yang di obfuscate atau pas lagi reverse engineering.

Memang betul, sekarang ada AI yang bisa berkali-kali lebih cepet ngerjain hal ini, baik ngereversing ataupun analisa kode JavaScript yang di obfuscate. Tapi bayangin kalau misalkan kita selalu ngandelin AI sampe gatau basicnya, dan kebetulan dihadapkan dengan pentest di lingkungan internal yang gaboleh ada internet ? boro-boro minta bantuan AI, browsing tutorial aja gabisa. Nah, inilah alasan kenapa gw bikin artikel ini.

Selain sebagai catatan pribadi, artikel ini dibuat biar kalian yang belum tau dan pengen bisa, mungkin bisa dapet sesuatu dari apa yang gw tulis kali ini: skill.

Implementasi Crypto Hashing untuk Mencegah Replay Attack

Dari pengalaman gw yang baru sedikit ini, nggak jarang web yang selain meng obfuscate kode JavaScriptnya juga nerapin mekanisme crypto untuk menghash payload dengan mekanisme dan kunci tertentu sebagai signature agar aman dari Replay Attack, kondisi dimana request yang sama bisa dikirim berulang-ulang. Mekanisme ini biasanya nambahin header custom seperti X-Signature dan juga nge hash payloadnya biar ngga bisa dimodifikasi/tampering.

Sayangnya, nggak jarang juga developer meng-hardcode secret key nya di dalam kode JavaScript, yang mana semua usaha dia ngelindungi request dengan meng obfuscate kode JavaScript dan nambahin X-Signature dari hash request jadi sia-sia.

Nah, disini letak celah kita untuk melakukan reversing dan analisa ke kode JavaScript yang di obfuscate untuk mengetahui bagaimana web menghash payload dan X-Signature digenerate untuk melindungi request agar tidak bisa diubah dan dikirim ulang (Replay Attack).

Tahap Recon: Menganalisis Behavior dan Request Target Web

Ini step penting. Sebelum kita tentukan apa yang mau kita lakukan, kita harus tau dulu bagaimana perilaku web yang sedang kita ulik. Percuma kita langsung analisa kode JavaScript yang di obfuscate kalau ternyata ngga ada apa-apa di dalamnya.

Tapi lihat gambar di atas. Setelah kita coba login, data dikirim ke endpoint http://localhost:5000/api/data dan reponse nya bilang kalau invalid credentials. Ini normal karena memang kita ngga tau apa username dan password yang bener. Tapi, kalau dilihat request headernya, webnya ngirim request login yang di request headernya ada custom header X-Signature. Apakah ini mekanisme anti Reply Attack ? Belum tentu. Kita perlu coba kirim ulang requestnya. Disini gw coba kirim ulang request yang sama pakai curl (pilih requestnya > klik kanan > copy > copy as curl) lewat terminal:

Bisa dilihat responsnya error:

{
  "error": "Authentication failed"
}

Nah, dari sini kita harus mulai curiga dengan behavior web yang tidak biasa, yaitu awal responnya adalah invalid credentials, tapi setelah coba diulang requestnya, responnya berubah jadi Authentication failed. Berarti ada bagian tertentu yang divalidasi oleh server selain username dan password.

Menyelami Obfuscated JavaScript Menggunakan Browser DevTools

Sampai sini, kita bisa coba mulai untuk melihat kode JavaScriptnya, khususnya di bagian yang mengirim request login. Kalau gw, biasanya dengan cara langsung menekan isi kolom Initiator di DevTools pada request yang mau dilihat dari mana sumber requestnya:

Dan akan langsung diarahkan ke file JavaScript tepat di baris kode yang melakukan aksi tersebut:

Kalau belum biasa, mungkin akan langsung "Waduh, apaan ini ?? kodenya ga jelas". Ya begitulah obfuscate. Memang tujuannya biar kodenya ngga gampang kebaca sama manusia. Jangan panik dulu atau bahkan nyerah. Balik lagi ke prinsip, kalau kodenya masih bisa jalan di browser, berarti masih ada peluang buat dianalisa.

Kalau dilihat sekilas, kode dari fungsi loginWithSignature() masih bisa kita baca meskipun sedikit readable string-nya.

async function loginWithSignature(_0x33360a, _0x35ec32) {
    const _0x140cc2 = _0x25d671
      , _0x3904eb = {
        'username': _0x33360a,
        'password': _0x35ec32,
        'timestamp': Math['floor'](Date[_0x140cc2(0x1e0)]() / 0x3e8),
        'nonce': generateNonce(),
        'action': _0x140cc2(0x214)
    }
      , _0x12e193 = JSON[_0x140cc2(0x1e6)](_0x3904eb)
      , _0x4f55d0 = await generateSignature(_0x12e193, SECRET_KEY)
      , _0x24f686 = await fetch(API_URL, {
        'method': _0x140cc2(0x203),
        'headers': {
            'Content-Type': _0x140cc2(0x1fa),
            'x-signature': _0x4f55d0
        },
        'body': _0x12e193
    })
      , _0x272281 = await _0x24f686['json']();
    return {
        'respon': _0x24f686,
        'result': _0x272281
    };
}

Begitupun dengan fungsi-fungsi lain yang dipanggil dari dalam fungsi loginWithSignature, yaitu generateSignature() dan juga generateNonce()

async function generateSignature(_0x452561, _0x64e268) {
    const _0x1cae77 = _0x25d671;
    try {
        const _0x2f40c7 = new TextEncoder()
          , _0x595669 = _0x2f40c7['encode'](_0x452561)
          , _0x37ef2b = _0x2f40c7[_0x1cae77(0x1f8)](_0x64e268)
          , _0x31b51f = await crypto[_0x1cae77(0x204)][_0x1cae77(0x20f)](_0x1cae77(0x1ed), _0x37ef2b, {
            'name': _0x1cae77(0x209),
            'hash': _0x1cae77(0x1ff)
        }, ![], [_0x1cae77(0x210)])
          , _0x210a6a = await crypto[_0x1cae77(0x204)][_0x1cae77(0x210)](_0x1cae77(0x209), _0x31b51f, _0x595669)
          , _0x59c3d8 = Array[_0x1cae77(0x1e7)](new Uint8Array(_0x210a6a))
          , _0x1a1470 = _0x59c3d8[_0x1cae77(0x1e8)](_0x184aa4 => _0x184aa4[_0x1cae77(0x1ee)](0x10)['padStart'](0x2, '0'))[_0x1cae77(0x1fb)]('');
        return _0x1a1470;
    } catch (_0x14fa5a) {
        console['error']('Error\x20generating\x20signature:', _0x14fa5a);
        throw _0x14fa5a;
    }
}
function generateNonce() {
    const _0xb519c8 = _0x25d671
      , _0x2f816b = new Uint8Array(0x10);
    return crypto[_0xb519c8(0x20c)](_0x2f816b),
    Array[_0xb519c8(0x1e7)](_0x2f816b)[_0xb519c8(0x1e8)](_0x3f8cf3 => _0x3f8cf3[_0xb519c8(0x1ee)](0x10)[_0xb519c8(0x1f4)](0x2, '0'))[_0xb519c8(0x1fb)]('');
}

Coba kita breakdown:

• Fungsi loginWithSignature() punya 2 parameter: username (_0x33360a) dan password (_0x35ec32), diambil dari input form.

• Body request disimpan di variabel _0x12e193, berupa object dengan key: username, password, timestamp, nonce, dan action.

• action sendiri adalah string 'login' (dilihat dari data payload di tab Network)

• timestamp adalah waktu saat ini dalam detik (UNIX timestamp): Math.floor(Date.now() / 1000)

• nonce adalah hasil dari fungsi generateNonce(), yaitu random value dari Uint8Array 16 byte. Tiap byte dikonversi ke hex (2 karakter, dipadding jika perlu), lalu digabung jadi 32 karakter hex string. Jadi intinya: random 16 byte ke representasi hex 32 karakter.

• Header request berisi Content-Type dan x-signature.

• x-signature adalah nilai dari _0x4f55d0, yaitu hasil return fungsi generateSignature() dengan parameter: body request (_0x12e193) dan SECRET_KEY.

• Fungsi generateSignature() sendiri adalah fungsi utama yang digunakan oleh web untuk menggenerate nilai dari header x-signature. Fungsi ini punya 2 variabel yaitu post data (_0x12e193) yang dijadikan JSON string dan juga SECRET_KEY. Akan kita breakdown lebih dalam nanti.

• Untuk URL dan

Dari breakdown di atas, kita bisa simpulkan mau kemana fokus kita: yaitu mencari nilai variable SECRET_KEY. Kalau beruntung, kita tinggal search string SECRET_KEY kedalam kode untuk melihat apa nilainya. Sayangnya, di kasus kita saat ini semua string sudah tidak bisa dibaca karena sudah jadi kode hasil "packer" pada saat di obfuscate.

Lalu, apa yang bisa kita lakukan ?

Memanfaatkan Fitur Debugging Browser DevTools untuk Reversing

Meskipun pencarian SECRET_KEY bisa dilakukan AI secara instan dengan cara deobfuscate JavaScript, di artikel ini kita pakai cara yang lebih hardcore dan keren, yaitu lewat fitur bawaan browser: Developer Tools.

Browser Developer Tools (DevTools) adalah fitur bawaan browser (Chrome, Firefox, Edge, dll) yang memungkinkan kita untuk inspect, edit, dan debug JavaScript, CSS, dan HTML secara real-time. Khususnya JavaScript, kita bisa langsung debugging fungsi atau variabel tertentu, pasang breakpoint buat lihat alur eksekusi di baris tertentu, dan ngecek nilai variabel atau return function secara real-time.

INFO

Karena di artikel ini gw cuma akan bahas fitur-fitur yang kita pakai aja untuk kasus saat ini, gw ga akan jelasin semua fungsi fitur DevTools disini. Untuk tutorial atau penjelasan lengkap bagaimana menggunaan fitur DevTools di browser, kalian bisa tonton dulu di YouTube atau baca dokumentasinya langsung di https://developer.chrome.com/docs/devtools/overview. Untuk tutorial bagaimana cara debugging kode JavaScript pakai DevTools, kalian bisa langsung ke https://developer.chrome.com/docs/devtools/javascript.

Bongkar Nilai Variabel SECRET_KEY yang Tersembunyi

Di proses breakdown kode JavaScript sebelumnya, kita sudah tau fungsi mana yang mengirim request login dan bagaimana fungsi tersebut menyusun body maupun header requestnya yaitu fungsi loginWithSignature.

Karena fokus kita disini adalah mencari nilai asli dari SECRET_KEY, yang mana variable tersebut dipanggil di dalam fungsi loginWithSignature, maka fungsi inilah yang jadi target debugging kita. Tapi coba amati lagi. Variabel SECRET_KEY adalah parameter kedua dari fungsi generateSignature:

// ...
_0x4f55d0 = await generateSignature(_0x12e193, SECRET_KEY)
// ...

Jadi, mana yang bakalan kita jadikan target debugging ? Fungsi loginWithSignature atau generateSignature ? Jawabannya: Bebas. Kedua fungsi tersebut bisa kita jadikan target untuk ngintip isi dari variabel SECRET_KEY.

Karena fitur DevTools ini udah powerful, kita bisa tau langsung apa sebenernya isi dari SECRET_KEY cukup dengan cara menambahkan breakpoint di salah satu fungsi tersebut.

Kalau ngga percaya, nih, kita satu persatu.

1. loginWithSignature

   Kita perlu melakukan aksi login dulu agar request muncul ke tab Network. Di tab Network, langsung klik aja kolom Initiator di baris yang sama dimana request ke endpoint login, lebih tepatnya ke nama file JavaScriptya (secure-login-obfuscated.js). Kita akan langsung diarahkan ke file secure-login-obfuscated.js di tab Sources tepat ke baris dimana fungsi melakukan fetch.

   Disini, cukup klik bagian sisi kiri (nomor baris) dari definisi fungsi loginWithSignature. Maka breakpoint akan aktif. Saat kita melakukan trigger agar fungsi tersebut dipanggil dengan cara submit login ulang, browser akan menghentikan eksekusi kode tepat dimana kita meletakkan breakpoint, dan disinilah ajaibnya.

   Kita hanya perlu mengarahkan mouse atau meng-hover ke variabel SECRET_KEY. Saat di hover, akan muncul isi sebenarnya dari target utama kita sebagai tooltip.

   

   Bisa kita lihat, nilai asli dari variabel SECRET_KEY adalah "ThisIsASecretKeyForHMACSignature12345!" !!

2. generateSignature

   Caranya masih sama dengan sebelumnya, hanya saja, target breakpoint kita adalah fungsi generateSignature

   

   Karena kita sudah tau kalau SECRET_KEY adalah variabel kedua pada fungsi generateSignature, maka yang kita hover adalah variable keduanya. Dan bisa dilihat, nilai variabel yang muncul ketika di hover adalah sama: "ThisIsASecretKeyForHMACSignature12345!". Selain itu, nilai asli juga muncul di tab kanan pada bagian "Block". Bagian ini adalah hasil dari fungsi atau variabel yang sudah dirender oleh browser.

Menganalisis Algoritma dan Struktur Hashing X-Signature

Akhirnya kita tau apa "Kunci Rahasia" yang digunakan oleh website tersebut untuk menggenerate nilai X-Signature. Selain itu, sampai sini kita juga sudah mulai paham bagaimana mekanisme "keamanannya". Tapi, kita masih belum tau bagaimana struktur data yang dihash hingga menjadi nilai dari X-Signature. Untuk itu, kita perlu memahami bagaimana fungsi generateSignature() bekerja.

async function generateSignature(_0x452561, _0x64e268) {
    const _0x1cae77 = _0x25d671;
    try {
        const _0x2f40c7 = new TextEncoder()
          , _0x595669 = _0x2f40c7['encode'](_0x452561)
          , _0x37ef2b = _0x2f40c7[_0x1cae77(0x1f8)](_0x64e268)
          , _0x31b51f = await crypto[_0x1cae77(0x204)][_0x1cae77(0x20f)](_0x1cae77(0x1ed), _0x37ef2b, {
            'name': _0x1cae77(0x209),
            'hash': _0x1cae77(0x1ff)
        }, ![], [_0x1cae77(0x210)])
          , _0x210a6a = await crypto[_0x1cae77(0x204)][_0x1cae77(0x210)](_0x1cae77(0x209), _0x31b51f, _0x595669)
          , _0x59c3d8 = Array[_0x1cae77(0x1e7)](new Uint8Array(_0x210a6a))
          , _0x1a1470 = _0x59c3d8[_0x1cae77(0x1e8)](_0x184aa4 => _0x184aa4[_0x1cae77(0x1ee)](0x10)['padStart'](0x2, '0'))[_0x1cae77(0x1fb)]('');
        return _0x1a1470;
    } catch (_0x14fa5a) {
        console['error']('Error\x20generating\x20signature:', _0x14fa5a);
        throw _0x14fa5a;
    }
}

Fungsi tersebut punya 2 parameter, yaitu payload string (string JSON dari post body yang akan dijadikan payload signature) dan juga secret key (SECRET_KEY) Tapi karena string dan nama fungsi sudah tidak terbaca, kita bisa sekali lagi pakai kesaktian dari DevTools untuk melihat apa sebenernya fungsi dari generateSignature()

Kita letakkan breakpoint di fungsi generateSignature() lalu trigger call dengan submit login lagi. Saat browser sudah berhenti di fungsi yang sudah kita tandai dengan breakpoint, kita bisa menekan tombol "Step over next function call" sembari melihat pada bagian "Block" untuk melihat hasil rendernya.

Bisa dilihat bahwa mekanisme hash ini menggunakan algoritma HMAC dengan fungsi SHA-256 (dilihat dari bagian algorithm pada "Block").

Kalau di breakdown kodenya, kurang lebih seperti ini

• _0x2f40c7 = new TextEncoder() adalah text encoder (UTF-8)

• _0x595669 = _0x2f40c7['encode'](_0x452561) mengenkode data payload (JSON string dari post body)

• _0x37ef2b = _0x2f40c7[_0x1cae77(0x1f8)](_0x64e268) mengenkode secret key (_0x64e268)

• _0x31b51f = await crypto[_0x1cae77(0x204)][_0x1cae77(0x20f)](_0x1cae77(0x1ed), _0x37ef2b, { 'name': _0x1cae77(0x209), 'hash': _0x1cae77(0x1ff) } meng-generate CryptoKey menggunakan SECRET_KEY dengan algoritma HMAC-SHA256

• _0x210a6a = await crypto[_0x1cae77(0x204)][_0x1cae77(0x210)](_0x1cae77(0x209), _0x31b51f, _0x595669) melakukan proses sign terhadap payload menggunakan CryptoKey, menghasilkan HMAC digest (ArrayBuffer)

• _0x59c3d8 = Array[_0x1cae77(0x1e7)](new Uint8Array(_0x210a6a)) , _0x1a1470 = _0x59c3d8[_0x1cae77(0x1e8)](_0x184aa4 => _0x184aa4[_0x1cae77(0x1ee)](0x10)['padStart'](0x2, '0'))[_0x1cae77(0x1fb)](''); mengubah hasil sign (ArrayBuffer) menjadi array byte, lalu mengkonversi tiap byte ke representasi hex (2 karakter), dan menggabungkannya menjadi string hex

• Terakhir, nilai _0x1a1470 di-return, yang merupakan 64 karakter hex string (hasil HMAC-SHA256)

INFO

Pola hashing di website biasanya menggunakan CryptoJS, jadi kalian bisa baca-baca juga dan pelajari gimana mekanismenya biar makin gampang menganalisanya.

Pusing ? sama, gw juga :)

Tapi percayalah, ilmu ini berguna. Pendekatan ini biasa gw pake juga ketika menghadapi mekanisme keamanan yang sama di mobile app.

Melakukan Replay Attack dan Forge Request Menggunakan Python

Oke, sejauh ini, coba kita rangkum dulu biar fresh ingatannya:

• Web nge-post data ke endpoint http://localhost:5000/api/data, dengan payload: {"username":"test","password":"test","timestamp":<current_time>,"nonce":"<32 hex char>","action":"login"}

• X-Signature di-generate dengan cara nge-sign JSON string payload pakai HMAC-SHA256 dan secret key: "ThisIsASecretKeyForHMACSignature12345!"

Dari sini keliatan kalau mekanisme keamanannya ada di x-signature (HMAC), timestamp dannonce.

Secara teori, kombinasi timestamp + nonce dipakai buat mencegah Replay Attack. Tapi ini cuma efektif kalau validasi di server bener.

Kalau server gak ngecek timestamp (expired atau enggak) atau gak nyimpen nonce yang udah dipakai, maka request bisa direplay atau bahkan di-forge ulang selama kita bisa generate signature valid.

Karena di sini SECRET_KEY ketauan (hardcoded di client), kita bisa:

• generate signature sendiri
• bikin request custom sesuka kita

Jadi langkah selanjutnya bukan sekadar “replay”, tapi lebih ke fully replicate & forge request.

Biar bisa lanjut testing tanpa kehalang mekanisme ini, kita tinggal bikin script yang niru flow:

• generate timestamp
• generate nonce
• generate X-Signature (HMAC-SHA256)
• kirim request

Di artikel ini, gw pakai Python buat ngerapihin proses tersebut. Dari hasil reversing dan analisa kode JavaScript yang di-obfuscate di atas, kurang lebih kode persamaannya kalau di Python seperti berikut:

import hashlib
import hmac
import json
import secrets
import time
import requests

API_URL = 'http://localhost:5000/api/data'
SECRET_KEY = 'ThisIsASecretKeyForHMACSignature12345!'

def generate_signature(data_string, secret_key):
    signature = hmac.new(
        secret_key.encode('utf-8'),
        data_string.encode('utf-8'),
        hashlib.sha256
    ).hexdigest()
    return signature

def generate_nonce():
    return secrets.token_hex(16)

def login_with_signature(username, password):
    payload = {
        'username': username,
        'password': password,
        'timestamp': int(time.time()),
        'nonce': generate_nonce(),
        'action': 'login'
    }
    
    json_data = json.dumps(payload)
    signature = generate_signature(json_data, SECRET_KEY)
    
    headers = {
        'Content-Type': 'application/json',
        'x-signature': signature
    }
    
    response = requests.post(API_URL, json=payload, headers=headers)
    return response
if __name__ == "__main__":
    response = login_with_signature("test","test")
    print(response.json())

Nah, tinggal kita coba eksekusi request login dengan kode python di atas:

Sekarang response menjadi Invalid credentials, yang menandakan bahwa request valid (x-signature dan nonce valid), tapi kredensial yang digunakan salah (username atau password).

Kesimpulan: Pentingnya Fondasi Basic Cyber Security

Dari semua proses di atas, keliatan jelas kalo cuma modal DevTools, kita udah bisa reverse kode JavaScript yang di-obfuscate, ngerti flow security yang dipake, terus lanjut ke testing yang impact-nya lebih gede daripada sekadar nemu "Hardcoded Secret".

Kalo kita paham dasarnya, kita nggak bakal gampang telan mentah-mentah hasil dari AI yang kadang ngaco, apalagi kalo kondisi nggak ideal. Insting pentester juga bakal keasah karena kita beneran mikir, bukan cuma spam tools/prompt doang.

Ini emang basic, simpel, dan mungkin keliatan receh buat yang udah lama di dunia ini. Tapi ya itu, fondasi tetep penting. Btw kalo ada yang salah atau kurang pas, benerin aja. Kalo ngerasa kepake, share.

Makasih udah baca sampe sini. Sampai jumpa di next article.

INFO

Artikel lanjutan: Membuat Custom Tamper SQLMap: Bypass Request Signature & Anti Replay Attack pada SQL Injection

self.related_posts()

Membuat Custom Tamper SQLMap: Bypass Request Signature & Anti Replay Attack pada...

self.popular_posts()

Membuat Custom Tamper SQLMap: Bypass Request Signature & Anti Replay Attack pada...hello_world("print")