Panduan Lengkap: Replay Request pada Telerik Fiddler & Manajemen X-Authorization
Panduan Komprehensif: Cara Melakukan Replay Request pada Telerik Fiddler dan Manajemen Header X-Authorization
Eksplorasi mendalam dari teori HTTP, instalasi, debugging API, hingga manipulasi token autentikasi tingkat lanjut untuk keperluan Development dan Security Testing.
1. Pendahuluan
Dalam ekosistem pengembangan perangkat lunak modern, Application Programming Interface (API) bertindak sebagai tulang punggung yang menghubungkan berbagai sistem, aplikasi mobile, web frontend, hingga layanan pihak ketiga (third-party services). Keandalan, performa, dan keamanan sebuah API sangat krusial. Oleh karena itu, pengembang (Developer), penguji kualitas (Quality Assurance/QA), serta analis keamanan (Security Analyst) membutuhkan alat yang mumpuni untuk melakukan inspeksi lalu lintas data (traffic inspection), proses debugging, serta analisis kerentanan sistem.
Salah satu alat yang paling kuat dan dihormati di industri perangkat lunak untuk keperluan ini adalah Telerik Fiddler. Fiddler bertindak sebagai web debugging proxy yang menangkap (intercept) semua lalu lintas HTTP dan HTTPS antara komputer Anda dan internet. Alat ini memungkinkan Anda untuk menginspeksi lalu lintas masuk dan keluar, memanipulasi permintaan (request) dan respons (response), serta melakukan serangkaian pengujian mendalam yang mustahil dilakukan hanya melalui browser standar.
Artikel ini ditulis secara khusus, mendalam, dan komprehensif (setidaknya mencakup 4000 kata eksplorasi teknis) untuk membahas satu teknik krusial dalam penggunaan Fiddler: Replay Request. Selain itu, kita akan membedah secara rinci bagaimana menangani, memanipulasi, dan memperbarui header autentikasi kustom, dengan fokus utama pada X-Authorization. Panduan ini dirancang mulai dari pemahaman teoretis hingga implementasi praktis langkah demi langkah, beserta otomatisasi tingkat lanjut menggunakan FiddlerScript.
2. Memahami Konsep Proxy dan Telerik Fiddler
Sebelum kita terjun ke dalam teknis Replay Request, sangat penting untuk memiliki landasan konseptual mengenai cara kerja Fiddler. Secara arsitektur, Telerik Fiddler adalah sebuah Forward Proxy. Ketika Fiddler dijalankan, ia akan mendaftarkan dirinya ke sistem operasi Windows (atau macOS/Linux untuk versi Fiddler Everywhere) sebagai proxy sistem dengan mendengarkan pada port tertentu (secara default adalah port 8888).
2.1. Bagaimana Fiddler Bekerja di Bawah Kap?
Ketika Anda membuka sebuah browser (seperti Google Chrome, Mozilla Firefox, atau Microsoft Edge) atau menjalankan aplikasi klien API (seperti Postman atau aplikasi mobile pada emulator), aplikasi tersebut biasanya akan membaca konfigurasi proxy sistem operasi. Karena Fiddler telah menyuntikkan dirinya sebagai proxy sistem, alur permintaan HTTP/HTTPS menjadi seperti berikut:
- Aplikasi Klien mengirimkan permintaan HTTP(S) yang ditujukan ke server (misalnya:
https://api.example.com/data).
- Permintaan ini tidak langsung menuju internet, melainkan ditangkap oleh Fiddler terlebih dahulu.
- Fiddler mencatat (log) seluruh detail permintaan tersebut: URL, metode HTTP (GET, POST, dll), header (termasuk
X-Authorization), dan body/payload permintaan.
- Fiddler kemudian meneruskan (forward) permintaan tersebut ke Server Tujuan.
- Server memproses permintaan dan mengirimkan respons kembali.
- Respons ditangkap kembali oleh Fiddler, dicatat (status code, header respons, body respons).
- Fiddler meneruskan respons tersebut kembali ke Aplikasi Klien.
2.2. Varian Fiddler: Classic vs Everywhere
Saat ini, Telerik menyediakan Fiddler dalam dua varian utama yang relevan bagi profesional IT:
- Fiddler Classic: Ini adalah versi legasi asli yang ditulis di atas .NET Framework. Hanya berjalan secara native di Windows. Memiliki fitur yang sangat kaya, antarmuka yang sangat padat informasi, dan dukungan FiddlerScript (JScript.NET) yang memungkinkan otomatisasi tingkat rendah. Fiddler Classic sangat disukai oleh pengguna tingkat lanjut yang membutuhkan kontrol absolut.
- Fiddler Everywhere: Versi modern yang dibangun ulang dari awal (menggunakan teknologi web/desktop cross-platform). Dapat berjalan di Windows, macOS, dan Linux. Antarmukanya jauh lebih bersih, modern, dan intuitif (mirip Postman), serta mendukung kolaborasi tim berbasis cloud. Namun, bagi sebagian pengguna lama, Fiddler Everywhere mungkin terasa berbeda dalam hal scripting dibandingkan Fiddler Classic.
Dalam panduan ini, kita akan membahas cara melakukan replay request di kedua versi tersebut agar Anda dapat beradaptasi terlepas dari lingkungan kerja yang Anda gunakan.
3. Apa Itu Replay Request?
Replay Request (memutar ulang permintaan) adalah salah satu fitur paling revolusioner dalam alat debugging proksi. Pada dasarnya, fitur ini memungkinkan pengguna untuk mengambil sebuah permintaan HTTP yang pernah dikirim ke server di masa lalu (yang telah ditangkap oleh Fiddler), dan kemudian mengirimkannya kembali ke server yang sama (atau memodifikasinya terlebih dahulu sebelum dikirim).
3.1. Mengapa Replay Request Sangat Penting?
Bayangkan Anda sedang mengembangkan aplikasi web yang memiliki fitur "Checkout Keranjang Belanja". Proses checkout ini melibatkan pengiriman payload JSON kompleks dengan puluhan parameter ke endpoint API. Saat Anda menekan tombol "Checkout" di antarmuka pengguna (UI), ternyata API merespons dengan error 500 Internal Server Error.
Tanpa Fiddler, untuk mereproduksi masalah tersebut, Anda harus:
- Menyegarkan (refresh) halaman.
- Mencari produk kembali.
- Memasukkan produk ke keranjang.
- Mengisi form alamat dan data pembayaran ulang.
- Menekan tombol checkout lagi.
Proses ini memakan waktu menit demi menit. Namun, dengan Fiddler, Anda cukup mengklik kanan permintaan checkout yang gagal tersebut, memilih menu Replay, dan permintaan yang sama persis (termasuk semua header kompleks dan cookie) akan dikirim dalam hitungan milidetik. Hal ini mempercepat siklus debug-fix-test secara eksponensial.
3.2. Skenario Penggunaan Replay Request
- Debugging Cepat: Menemukan bug di sisi backend dengan mengirim ulang payload yang menyebabkan error (crash).
- Penetrasi (Security Testing): Melakukan manipulasi terhadap harga barang dalam payload, memodifikasi peran pengguna, atau menguji serangan Brute Force.
- Pengujian Idempotensi: Mengirimkan permintaan POST (seperti transfer uang) berkali-kali untuk melihat apakah backend menangani duplikasi dengan benar atau justru uang terpotong dua kali (Race Condition).
- Manipulasi Autentikasi: Mengganti token lama dengan token baru untuk memvalidasi mekanisme Session Management pada server. Di sinilah interaksi dengan
X-Authorization terjadi.
4. Anatomi Autentikasi: Membedah Header X-Authorization
Protokol HTTP sejatinya bersifat stateless (tidak menyimpan keadaan). Setiap permintaan yang dikirim ke server dianggap sebagai transaksi independen. Agar server mengetahui "siapa" yang sedang meminta data, klien harus menyertakan semacam identitas atau "tiket masuk" pada setiap permintaan. Tiket inilah yang sering kita sebut sebagai Token Autentikasi (Authentication Token).
4.1. Standar Header vs Custom Header
Berdasarkan spesifikasi resmi Internet Engineering Task Force (IETF) melalui dokumen RFC 7235, cara standar untuk mengirimkan kredensial dalam HTTP adalah menggunakan header bernama Authorization. Format umumnya adalah: Authorization: (misalnya: Authorization: Bearer eyJhbGci...).
Lalu, apa itu X-Authorization?
Dalam konvensi HTTP historis, header apa pun yang diawali dengan huruf X- (kependekan dari eXperimental atau eXtension) menandakan bahwa header tersebut adalah header kustom (non-standar). Meskipun standar IETF (RFC 6648) pada tahun 2012 menghentikan rekomendasi penggunaan awalan "X-" untuk header baru, praktiknya masih sangat luas digunakan di industri hingga saat ini.
Developer dan arsitek perangkat lunak menggunakan X-Authorization karena beberapa alasan taktis:
- Menghindari Konflik dengan Autentikasi Bawaan Server: Terkadang, infrastruktur server (seperti Nginx, Apache, atau Load Balancer tingkat jaringan) secara agresif memotong atau memproses header
Authorization standar (misalnya untuk Basic Auth). Dengan menggunakan X-Authorization, aplikasi di layer backend (Node.js, Java Spring, PHP Laravel) dapat menerima token utuh tanpa gangguan dari infrastruktur di depannya.
- Sistem Multi-Tenant / Multi-Autentikasi: Sebuah API mungkin melayani banyak jenis klien. Header
Authorization mungkin digunakan untuk token OAuth2 standar pihak ketiga, sementara X-Authorization digunakan untuk token internal/kustom milik aplikasi native mereka sendiri.
- Keamanan Obscurity (meskipun bukan praktik terbaik): Mencoba menyamarkan proses autentikasi dari bot sederhana yang hanya mencari header standar.
4.2. Jenis Token yang Sering Disematkan pada X-Authorization
Ketika Anda melakukan inspeksi pada Fiddler, nilai (value) dari X-Authorization biasanya akan mengambil salah satu dari bentuk berikut:
- JWT (JSON Web Token): Format paling populer saat ini. Terlihat seperti deretan teks panjang yang dipisahkan oleh dua buah titik (contoh:
eyJhbGciOiJIUzI1Ni... . eyJzdWIiOiIxMj... . SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c). JWT menyimpan klaim data pengguna dan telah ditandatangani secara kriptografis (misalnya dengan algoritma HS256 atau RS256).
- Opaque Token (Random String): Token yang murni dihasilkan secara acak oleh server dan disimpan di database server (seperti Redis). Klien tidak dapat membaca isi token ini, ia hanya sebuah referensi (contoh:
X-Authorization: abc123def456ghi789).
- API Key: Kunci statis yang sering digunakan untuk komunikasi antar server (Server-to-Server) atau autentikasi layanan publik.
Catatan Penting Tentang Kadaluarsa Token (Expiration):
Sebagian besar token otorisasi modern (terutama JWT) memiliki batasan waktu hidup atau Time-To-Live (TTL). Artinya, token tersebut hanya valid selama periode tertentu (misal: 1 jam). Jika Anda melakukan Replay Request pada Fiddler keesokan harinya menggunakan permintaan yang ditangkap kemarin, server pasti akan merespons dengan status 401 Unauthorized karena token di dalam X-Authorization telah usang (expired). Inilah alasan mengapa modifikasi header saat melakukan replay sangat diperlukan.
5. Persiapan Teknis: Instalasi dan Konfigurasi Dekripsi HTTPS
Untuk dapat melihat konten permintaan HTTP dan header X-Authorization, Anda wajib mengkonfigurasi Fiddler agar dapat mendekripsi lalu lintas HTTPS (HTTPS Decryption). Hampir 100% API modern saat ini menggunakan HTTPS. Tanpa dekripsi, Fiddler hanya akan melihat saluran terenkripsi (Tunnel) dan gagal menampilkan isinya.
5.1. Instalasi Telerik Fiddler
- Kunjungi situs resmi Telerik Fiddler di
https://www.telerik.com/fiddler.
- Pilih versi yang ingin Anda gunakan. Jika Anda menggunakan Windows dan ingin fitur kustomisasi mendalam, unduh Fiddler Classic. Jika Anda ingin antarmuka modern atau menggunakan Mac/Linux, unduh Fiddler Everywhere.
- Jalankan installer dan ikuti instruksi standar (Next, Agree, Install).
5.2. Mengaktifkan Dekripsi HTTPS (Fiddler Classic)
Langkah ini sangat krusial. Fiddler bertindak sebagai serangan Man-in-the-Middle (MITM) yang legal terhadap komputer Anda sendiri. Ia membuat sertifikat root (Root Certificate) palsu dan menandatangani setiap lalu lintas yang lewat dengannya.
- Buka Fiddler Classic.
- Pada menu bar di atas, klik Tools > Options...
- Akan muncul jendela dialog. Navigasikan ke tab HTTPS.
- Centang kotak bertuliskan Capture HTTPS CONNECTs.
- Selanjutnya, centang kotak Decrypt HTTPS traffic.
- Segera setelah Anda mencentang opsi tersebut, sebuah peringatan keamanan Windows (atau dari Fiddler) akan muncul. Jendela ini meminta izin untuk menginstal "DO_NOT_TRUST_FiddlerRoot" ke dalam penyimpanan sertifikat OS (Certificate Store) komputer Anda.
- Klik Yes (atau OK) pada semua peringatan tersebut. Jika Anda menolak, browser Anda akan memblokir semua koneksi karena menganggap koneksi tidak aman (Certificate Error).
- Pada opsi dropdown (...from all processes), pastikan Anda memilihnya agar Fiddler menangkap dari semua aplikasi.
- Klik OK untuk menyimpan pengaturan. Muat ulang (Restart) Fiddler untuk memastikan konfigurasi berjalan sempurna.
Peringatan Keamanan:
Sertifikat Root Fiddler sangat berkuasa atas sistem Anda. Setelah Anda selesai melakukan sesi pengujian dan analisis, sangat disarankan untuk masuk kembali ke menu Tools > Options > HTTPS > Actions dan memilih Remove Interception Certificates, atau setidaknya mematikan Fiddler saat tidak digunakan untuk aktivitas perbankan atau hal sensitif lainnya di komputer yang sama.
6. Langkah-Langkah Melakukan Replay Request di Fiddler Classic
Setelah persiapan selesai, saatnya melakukan aksi inti: memutar ulang permintaan (Replay Request) menggunakan Fiddler Classic. Terdapat dua metode utama dalam Fiddler Classic: Replay Langsung (Unmodified) dan Replay dengan Modifikasi (Composer).
Metode 1: Replay Cepat (Tanpa Modifikasi)
Metode ini digunakan jika Anda hanya ingin mengulang permintaan yang persis sama, ke server yang sama, dan dengan payload/header yang sama (biasanya untuk mengecek apakah server masih merespons, atau menguji idempotensi masalah race condition).
- Pastikan Fiddler dalam mode Capturing (Lihat pojok kiri bawah jendela aplikasi Fiddler, pastikan ada tulisan "Capturing" atau tekan
F12).
- Buka browser atau klien aplikasi Anda, lalu lakukan tindakan yang ingin Anda tangkap (misal: memuat halaman profil atau mengirimkan form).
- Beralih ke jendela Fiddler. Di panel sebelah kiri (Web Sessions list), Anda akan melihat daftar semua permintaan yang masuk.
- Cari dan identifikasi permintaan API target Anda (Anda dapat melihat kolom Host dan URL untuk memudahkan pencarian).
- Klik kanan pada sesi (baris) tersebut.
- Arahkan kursor ke menu Replay.
- Pilih Reissue Requests (atau Anda cukup menekan tombol pintas
R pada keyboard).
- Anda akan melihat baris baru muncul di paling bawah daftar Web Sessions. Itu adalah permintaan yang baru saja dikirim ulang. Anda bisa mengklik ganda baris baru tersebut untuk menginspeksi di tab Inspectors apakah server mengembalikan status HTTP
200 OK, 401 Unauthorized, atau 500 Server Error.
Tip Pro: Jika Anda ingin membanjiri (flood) server untuk uji beban ringan (Load Testing / Rate Limit Testing), tekan Shift + R secara bersamaan. Fiddler akan memunculkan popup yang menanyakan berapa kali Anda ingin mengulang permintaan ini (misal: masukkan angka 50). Fiddler akan mengeksekusi 50 permintaan berturut-turut dengan sangat cepat.
Metode 2: Menggunakan Tab "Composer" (Replay dengan Modifikasi)
Ini adalah metode yang akan paling sering Anda gunakan, terutama saat Anda berurusan dengan API yang menggunakan header X-Authorization. Jika token autentikasi telah kadaluarsa, melakukan "Replay Cepat" di atas akan percuma karena server akan menolak permintaan tersebut. Anda harus memodifikasi header terlebih dahulu menggunakan Composer.
- Temukan permintaan target di panel kiri (Web Sessions list) Fiddler.
- Tahan klik (Klik kiri dan tahan) pada baris tersebut, lalu Drag and Drop (seret dan lepaskan) ke tab Composer yang berada di panel sebelah kanan atas Fiddler. (Sebagai alternatif, klik kanan sesi -> Unlock for Editing, atau cukup Drag to Composer).
- Setelah permintaan dilepaskan di Composer, Anda akan melihat detail permintaan terbuka dalam mode edit teks (Parsed mode).
- Di bagian atas, Anda dapat melihat metode HTTP (GET/POST/PUT) dan URL tujuan.
- Di kotak teks besar bagian tengah, Anda akan melihat kumpulan Request Headers. Susunannya menyerupai teks biasa yang dipisahkan baris.
- Temukan baris yang bertuliskan
X-Authorization: Bearer [TOKEN_ANDA].
- Di sini Anda dapat mengedit teks tersebut. Ganti token yang kadaluarsa dengan token yang baru Anda peroleh. Anda juga dapat menambah, menghapus, atau mengubah header lain (misalnya memodifikasi
User-Agent atau Content-Type).
- Jika permintaan tersebut adalah POST atau PUT, di bagian paling bawah (Request Body), Anda bisa memodifikasi payload JSON atau Form Data yang akan dikirim.
- Setelah selesai memodifikasi, klik tombol Execute di bagian kanan atas tab Composer.
- Permintaan hasil manipulasi tersebut akan dikirimkan, dan hasilnya akan muncul sebagai baris baru di Web Sessions list panel kiri.
7. Langkah-Langkah Melakukan Replay Request di Fiddler Everywhere
Fiddler Everywhere memiliki alur kerja yang mirip secara konsep, namun secara antarmuka pengguna (UI) jauh lebih bersahabat dan menyerupai aplikasi klien API modern. Proses menangkap dan memodifikasi permintaan lebih intuitif.
7.1. Mengaktifkan Mode Dekripsi (Fiddler Everywhere)
- Buka Fiddler Everywhere.
- Klik ikon roda gigi (Settings) di pojok kanan atas.
- Pilih tab HTTPS.
- Centang opsi Trust root certificate (Sistem mungkin akan meminta kata sandi admin OS Anda untuk menginstal sertifikat).
- Centang Capture HTTPS traffic.
- Klik tombol Save atau Apply, dan tutup jendela Settings.
7.2. Melakukan Replay melalui "Composer" di Fiddler Everywhere
- Pastikan sakelar Live Traffic berada di posisi ON (aktif). Lakukan interaksi di browser agar Fiddler Everywhere merekam aktivitas Anda.
- Pilih permintaan yang ingin Anda putar ulang dari daftar Live Traffic.
- Di panel kanan (Inspectors), Anda akan melihat detail dari permintaan yang dipilih.
- Untuk melakukan Replay langsung, Anda bisa mengklik ikon panah melingkar (Replay) di bilah alat (toolbar) di atas permintaan tersebut.
- Namun, untuk memodifikasi header
X-Authorization, klik kanan pada baris sesi di Live Traffic, lalu pilih Edit in Composer (atau tekan pintasan keyboard E).
- Fiddler Everywhere akan membuka tab baru bernama Composer. Di sinilah letak perbedaan besarnya. Tidak seperti Fiddler Classic yang menggunakan tampilan teks polos untuk header, Fiddler Everywhere menggunakan tabel (Key-Value pairs) layaknya Postman.
- Di bagian Headers, cari baris (Key) yang bernama
X-Authorization.
- Klik pada kolom Value di sebelahnya, hapus token lama, dan tempelkan (Paste) token yang baru dan masih valid.
- Anda bisa menonaktifkan/mengaktifkan header tertentu hanya dengan mencentang/menghapus centang pada kotak (checkbox) di samping nama header. Sangat berguna untuk menguji apa respons API jika header
X-Authorization dihilangkan secara sengaja (Testing Otorisasi Terbuka / Broken Authentication).
- Klik tombol biru Execute. Respons akan langsung muncul di bagian bawah jendela Composer (di panel Response) tanpa perlu mencari sesi baru di daftar Live Traffic.
8. Modifikasi Lanjutan: Menyuntikkan dan Memanipulasi X-Authorization
Memahami bagaimana memanipulasi X-Authorization adalah inti dari pengujian keamanan dan fungsionalitas API. Seringkali, developer tidak sekadar mengganti token yang kadaluarsa, melainkan secara aktif "bermain-main" dengan token tersebut untuk menguji keandalan sistem backend.
8.1. Tantangan dengan JWT pada X-Authorization
Jika token yang digunakan oleh API adalah JSON Web Token (JWT), Anda tidak bisa sekadar mengubah nilai di dalam token dengan harapan mendapat hak akses baru. JWT memiliki 3 bagian yang dipisahkan oleh tanda titik (.): Header, Payload, dan Signature.
Contoh skenario pengujian menggunakan Composer:
- Menguji "None" Algorithm Attack: Penyerang (atau Anda, sebagai Pentester) mencoba menghapus bagian Signature dari JWT, dan mengganti algoritma di Header menjadi "none". Jika backend API Anda tidak terkonfigurasi dengan aman, API akan menerima token palsu tersebut tanpa memverifikasi tanda tangannya. Anda dapat menggunakan Fiddler Composer untuk memodifikasi string JWT tersebut dan melakukan "Execute".
- Menguji Eskalasi Hak Istimewa (Privilege Escalation): Anda menangkap permintaan dari akun "User Biasa" yang memiliki
X-Authorization. Anda kemudian menyalin token dari permintaan akun "Administrator" (yang Anda miliki pada sesi terpisah), lalu memasukkannya (Replay) ke endpoint yang awalnya diakses oleh "User Biasa". Tujuannya untuk melihat apakah endpoint (URL) tersebut mengecek otoritas di level operasi (CORS/IDOR check).
- Menguji Token Usang (Expired Token Testing): Mengambil token lama yang sudah expired, melakukan Replay, dan memastikan respons server tidak hanya
500 Error (yang merupakan bad practice dan dapat menyebabkan Information Leakage), melainkan respons JSON yang terstruktur baik: {"status": "error", "message": "Token expired", "code": 401}.
8.2. Di mana Mendapatkan Token Baru untuk Replay?
Ketika Anda menguji dan menyadari token Anda kadaluarsa di tengah jalan, Anda tidak perlu menutup Fiddler. Lakukan hal berikut:
- Lakukan proses Login kembali pada aplikasi/browser Anda.
- Amati Fiddler, cari permintaan POST ke endpoint login (misal:
/api/v1/auth/login).
- Klik permintaan login tersebut, lihat panel Inspectors > Response > JSON.
- Biasanya, server akan mengembalikan nilai token di dalam body respons. (Contoh:
{"accessToken": "eyJhbGciOi..."}).
- Blok dan salin (Copy) nilai tersebut.
- Kembali ke tab Composer di Fiddler, buka permintaan yang sebelumnya ingin Anda Replay.
- Tempel (Paste) di nilai
X-Authorization dan jalankan kembali permintaan tersebut.
9. Otomatisasi dengan FiddlerScript (JScript.NET)
Bagi Anda yang berurusan dengan siklus pengembangan panjang, menyalin-tempel token X-Authorization berkali-kali sangatlah melelahkan dan rentan terhadap kesalahan (human error). Fiddler Classic memiliki senjata pamungkas bernama FiddlerScript.
FiddlerScript memungkinkan kita menulis kode program kecil menggunakan sintaks JScript.NET (mirip dengan C# dan JavaScript) untuk secara dinamis mengubah permintaan sebelum dikirim ke server. Kita dapat mengotomatiskan injeksi atau penggantian header X-Authorization di setiap permintaan!
9.1. Mengakses Editor FiddlerScript
- Buka Fiddler Classic.
- Pada tab kanan, cari tab yang bernama FiddlerScript. (Jika tidak ada, Anda bisa pergi ke menu bar:
Rules > Customize Rules... atau tekan Ctrl+R yang akan membuka file CustomRules.js di editor teks seperti Notepad atau Fiddler ScriptEditor).
- Di dalam file kode tersebut, gulir ke bawah hingga Anda menemukan fungsi yang bernama
OnBeforeRequest(oSession: Session). Fungsi kritis ini dieksekusi tepat sebelum Fiddler meneruskan permintaan dari klien ke server.
9.2. Skrip Otomatisasi: Menimpa Header X-Authorization
Katakanlah Anda memiliki token valid yang masa aktifnya sangat lama (misalnya token lingkungan Staging) dan Anda ingin agar setiap kali browser Anda mengirim permintaan ke api.testing.com, Fiddler secara otomatis memaksa (force inject) header X-Authorization yang telah Anda tentukan. Berikut adalah kodenya:
static function OnBeforeRequest(oSession: Session) {
// [Kode bawaan lainnya ada di sini...] // Tambahkan logika kita sendiri:
// Cek apakah host tujuan adalah API kita
if (oSession.HostnameIs("api.testing.com")) {
// Token JWT atau Opaque valid yang Anda miliki
var validToken = "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIi...[SISA_TOKEN]";
// Jika header X-Authorization sudah ada, timpa nilainya.
// Jika belum ada, tambahkan header baru.
oSession.oRequest["X-Authorization"] = validToken;
// Opsional: Beri warna pada sesi di Fiddler agar kita tahu skrip telah bekerja
oSession["ui-color"] = "orange";
oSession["ui-bold"] = "true";
}
}
Penjelasan Kode:
oSession.HostnameIs(): Memastikan modifikasi hanya berlaku pada domain target kita dan tidak mengacaukan lalu lintas ke Google, Facebook, atau layanan lainnya di latar belakang.
oSession.oRequest["Nama-Header"]: Mengakses koleksi dictionary header. Mengisinya dengan nilai akan secara otomatis memodifikasi (atau menambah jika belum ada) header tersebut sebelum di-relay ke server.
ui-color: Sebuah trik estetika. Mengubah warna tulisan di daftar sesi (kiri) menjadi oranye, sehingga Anda dapat dengan mudah melihat secara visual mana saja permintaan yang headernya telah berhasil disuntikkan secara otomatis oleh skrip.
9.3. Menyimpan dan Menguji Skrip
Setelah Anda memasukkan kode di atas, cukup simpan file (jika menggunakan Notepad, Ctrl+S). Fiddler akan segera memuat ulang (reload) CustomRules tersebut. Fiddler akan mengeluarkan suara "beep" kecil tanda skrip berhasil dikompilasi ulang. Mulai saat itu, meskipun Anda melakukan Replay sederhana (menggunakan tombol R) pada permintaan tanpa header autentikasi, FiddlerScript akan menangkapnya secara real-time, memasukkan X-Authorization, dan mengirimkannya ke server.
10. Studi Kasus dan Penerapan Dunia Nyata
Untuk memahami sepenuhnya seberapa kuat perpaduan Fiddler Replay dan manipulasi X-Authorization, mari kita lihat beberapa studi kasus riil yang sering dihadapi oleh profesional IT.
10.1. Kasus 1: Menguji Celah IDOR (Insecure Direct Object Reference)
Konteks: Sebuah aplikasi manajemen faktur (Invoice) memiliki endpoint untuk mengunduh PDF: GET /api/v1/invoice/download/9901. Klien mengirim permintaan ini disertai header X-Authorization milik User A. Faktur 9901 memang milik User A.
Tindakan di Fiddler:
- Security Analyst menangkap permintaan tersebut di Fiddler.
- Memindahkan (Drag) permintaan tersebut ke Composer.
- Pada URL, Analyst mengubah parameter ID faktur menjadi
9902 (yang diasumsikan milik User B).
- Analyst membiarkan header
X-Authorization tetap berisi token milik User A.
- Klik Execute (Replay).
Hasil Observasi: Jika server membalas dengan status 200 OK dan mengirimkan file PDF faktur milik User B, maka selamat, Analyst tersebut baru saja menemukan kerentanan kritis tingkat tinggi (BOLA/IDOR). Server hanya memvalidasi apakah token valid, tetapi gagal mengotorisasi apakah pemilik token berhak mengakses sumber daya 9902. Jika server merespons 403 Forbidden, maka API dirancang dengan aman.
10.2. Kasus 2: Pengembangan Aplikasi Mobile (Android/iOS) Tanpa Akses Source Code Backend
Konteks: Anda adalah seorang Front-End Mobile Developer. Tim Backend sedang libur, dan aplikasi mobile Anda tiba-tiba macet saat mencoba memuat layar beranda. Anda curiga ada struktur data JSON yang berubah pada backend, tetapi tidak yakin endpoint mana yang bermasalah.
Tindakan di Fiddler:
- Anda mengarahkan koneksi Wi-Fi dari Smartphone (iPhone/Android) Anda ke IP Address komputer Anda (dengan port 8888) tempat Fiddler berjalan (Proses Proxy Device).
- Anda membuka aplikasi di Smartphone. Fiddler menangkap semua API Call.
- Anda menemukan bahwa ada endpoint
/mobile/home-feed yang mengembalikan error 400 Bad Request.
- Anda melakukan Replay berulang-ulang di Composer sambil memodifikasi sedikit demi sedikit nilai pada parameter URL atau Body, dan tidak lupa memastikan header
X-Authorization selalu diganti dengan yang terbaru agar tidak kena blokir karena kedaluwarsa.
- Setelah melakukan trial & error melalui replay, Anda menemukan bahwa parameter
version=1.0 di header menyebabkan error, dan mengubahnya menjadi version=2.0 menyelesaikan masalah. Anda berhasil mendebug API tanpa harus menunggu tim backend.
11. Troubleshooting dan Pemecahan Masalah Umum
Meskipun Fiddler sangat kuat, lalu lintas jaringan web sangatlah kompleks. Ada banyak mekanisme pengamanan modern yang bisa menghalangi atau mempersulit Fiddler saat mencoba melakukan intersepsi dan manipulasi. Berikut beberapa kendala dan solusinya:
11.1. HTTPS Certificate Pinning pada Aplikasi Mobile
Jika Anda melakukan Replay Request pada API yang berasal dari browser web komputer, biasanya berjalan mulus. Namun, jika permintaan tersebut berasal dari aplikasi mobile canggih, terkadang Fiddler sama sekali tidak bisa membaca isinya (hanya muncul baris merah Tunnel to...). Ini karena aplikasi mengimplementasikan Certificate Pinning (SSL Pinning). Aplikasi menyimpan "sidik jari" (fingerprint) asli sertifikat server di dalam kode sumbernya. Ketika Fiddler memasukkan sertifikat MITM palsunya, aplikasi mobile mendeteksinya dan langsung memutus koneksi secara paksa. Anda tidak akan bisa menangkap X-Authorization untuk di-replay.
Solusi: Pada perangkat Android yang telah di-root, Anda harus menggunakan framework seperti Frida atau aplikasi modul Magisk seperti JustTrustMe atau TrustMeAlready untuk mem-bypass (melucuti) mekanisme SSL Pinning tersebut. Setelah SSL Pinning dinonaktifkan, lalu lintas akan muncul di Fiddler dengan sempurna.
11.2. Cors (Cross-Origin Resource Sharing) Issues dan Preflight Requests
Terkadang, ketika Anda mencoba melakukan Replay permintaan berbasis Javascript yang memiliki header kustom (seperti X-Authorization), Anda akan menyadari ada dua permintaan yang terbentuk di Fiddler. Permintaan pertama menggunakan metode HTTP OPTIONS, dan barulah diikuti permintaan GET/POST yang asli.
Permintaan OPTIONS ini disebut Preflight Request. Browser secara otomatis mengirimkannya untuk bertanya ke server: "Hei server, saya punya header aneh bernama X-Authorization dari domain lain. Boleh tidak saya kirim data utamanya?".
Solusi: Saat melakukan Replay di Fiddler Composer, Anda sebenarnya beroperasi di luar ranah browser. Anda adalah "Tuhan" atas permintaan tersebut (mengabaikan CORS). Anda tidak perlu mereplay OPTIONS. Langsung saja Drag & Drop permintaan GET/POST utamanya, modifikasi header X-Authorization, dan jalankan (Execute).
11.3. Respons Berupa Karakter Aneh (Gibberish)
Terkadang setelah Anda mengeksekusi Replay Request, server merespons, namun tab TextView di Fiddler Inspector menunjukkan karakter yang tidak bisa dibaca (seperti: ‹ í½`I–%&/mÊ...). Anda bingung dan menganggap replay gagal.
Solusi: Ini bukan karena modifikasi X-Authorization Anda salah. Hal ini terjadi karena klien awal (browser) mengirimkan request header: Accept-Encoding: gzip, deflate, br. Karenanya, server mengkompresi respons. Fiddler menampilkan data mentah terkompresi. Untuk melihat teks JSON/HTML aslinya, cukup klik bilah peringatan berwarna kuning di tab Inspector yang bertuliskan: "Response is encoded any may need to be decoded before inspection. Click here to transform."
11.4. Masalah VPN (Virtual Private Network)
Jika Fiddler tiba-tiba tidak dapat menangkap lalu lintas (Blank Capturing) atau permintaan Replay selalu gagal dengan error DNS Lookup Failed atau Connection Refused, kemungkinan komputer Anda menjalankan perangkat lunak VPN perusahaan (Cisco AnyConnect, GlobalProtect, dll). VPN ini membelokkan ulang routing sistem dan membypass proxy localhost Fiddler.
Solusi: Cobalah untuk mematikan VPN saat melakukan inspeksi dengan Fiddler, atau konsultasikan pengaturan "Bypass Proxy" pada konfigurasi VPN perusahaan Anda. Pada beberapa kasus, menjalankan Fiddler terlebih dahulu sebelum mengkoneksikan VPN (atau sebaliknya) dapat memecahkan masalah routing override ini.
12. Praktik Terbaik (Best Practices) dalam API Testing
Menggunakan alat berkuasa tinggi seperti Fiddler menuntut tanggung jawab dan pemahaman akan metrik keamanan operasional. Berikut adalah rangkuman praktik terbaik ketika memanipulasi header seperti X-Authorization:
- Jangan Lakukan Pengujian di Lingkungan Produksi (Production): Selalu uji dan replay request di lingkungan Development (Dev), Staging, atau User Acceptance Testing (UAT). Memutar ulang (replay) permintaan POST pembayaran atau pembaruan profil di Production dapat menyebabkan anomali data (data corruption) yang memengaruhi pengguna riil.
- Rahasiakan Token Anda: Token di dalam
X-Authorization setara dengan kombinasi Username dan Password Anda. Jika Anda mengambil tangkapan layar (screenshot) Fiddler untuk dilaporkan sebagai bug ke tim pengembang, pastikan untuk memburamkan (blur) nilai X-Authorization. Atau lebih baik lagi, gunakan fitur Sanitize sebelum menyimpan file sesi (.saz).
- Gunakan AutoResponder untuk Simulasi Respons (Mocking): Alih-alih selalu harus melakukan Replay yang membebani server backend, manfaatkan fitur AutoResponder (Fiddler Classic) atau Rule Builder (Fiddler Everywhere). Anda dapat membuat aturan: "Jika Fiddler mendeteksi klien saya mengirim permintaan dengan header
X-Authorization: TokenKadaluarsa123, langsung hentikan permintaan sebelum sampai ke internet, dan kembalikan respons palsu HTTP 401 buatan saya sendiri". Ini luar biasa berguna untuk menguji penanganan error aplikasi UI (Frontend Error Handling).
- Pahami Batasan Waktu (TTL): Perhatikan waktu. Replay mungkin sukses di menit pertama, tetapi gagal total di menit ke-15 jika kebijakan keamanan sistem menetapkan TTL token yang agresif. Sering-seringlah merefresh sesi Anda.
13. Kesimpulan
Telerik Fiddler tidak diragukan lagi adalah salah satu pilar utama dalam persenjataan seorang insinyur perangkat lunak modern. Memahami cara melakukan Replay Request bukan hanya persoalan teknis pengulangan permintaan HTTP, melainkan memahami bagaimana interaksi state pada internet bekerja secara fundamental.
Melalui manipulasi terhadap header kritis seperti X-Authorization menggunakan tab Composer atau melalui otomatisasi tingkat lanjut dengan FiddlerScript, kita dapat dengan bebas menyelami celah dan relung terdalam dari infrastruktur Application Programming Interface (API). Proses ini mengungkap kerentanan tersembunyi seperti kontrol akses tingkat objek yang rusak (IDOR), manajemen sesi yang buruk (Broken Session Management), sekaligus mengakselerasi proses pencarian bug (debugging) oleh tim teknis secara revolusioner.
Baik Anda seorang Web Developer yang mencoba menyelesaikan masalah sinkronisasi frontend-backend, seorang analis QA yang mengotomatiskan serangkaian uji kasus regresi, maupun seorang konsultan keamanan (Pentester) yang mencoba meretas batas kebijakan otorisasi, penguasaan atas metodologi intersepsi, modifikasi otorisasi, dan pengiriman ulang (Replay) dengan alat seperti Telerik Fiddler (Classic maupun Everywhere) adalah keterampilan level elit yang akan senantiasa relevan dalam lanskap rekayasa perangkat lunak.
Semoga panduan teknis dan mendalam ini dapat menjadi referensi definitif yang membantu kelancaran operasional pengujian dan pemeliharaan aplikasi Anda. Terus eksplorasi, terus teliti, dan pastikan setiap permintaan yang Anda putar ulang membawa sistem Anda selangkah lebih dekat menuju kesempurnaan arsitektur API.
Обсуждение (0)