Analisis Replay Attack pada HTTP Request Menggunakan Telerik Fiddler
Abstrak
Replay attack merupakan salah satu jenis serangan pada protokol komunikasi jaringan di mana attacker menangkap request yang valid, lalu mengirim ulang request tersebut ke server untuk memperoleh hasil yang sama lebih dari sekali. Serangan ini sering ditemukan pada API yang menangani transaksi sensitif seperti login, reward claim, redeem voucher, pembelian item, atau transfer data penting.
Artikel ini membahas konsep replay attack pada HTTP API, analisis header autentikasi seperti X-Authorization, penggunaan Telerik Fiddler sebagai HTTP debugging proxy, serta metode mitigasi yang dapat diterapkan developer untuk mencegah serangan tersebut.
1. Pendahuluan
Aplikasi modern seperti game online, mobile apps, dan layanan cloud umumnya menggunakan komunikasi berbasis HTTP atau HTTPS untuk pertukaran data dengan server.
Contoh komunikasi client-server:
Mobile App → HTTP Request → API Server
API Server → HTTP Response → Mobile App
Setiap request dapat berisi:
Header autentikasi
Token session
Payload JSON
Signature
Cookie
Jika server tidak memiliki mekanisme proteksi replay, request yang sama dapat dikirim ulang dan diproses berkali-kali.
2. Definisi Replay Attack
Replay attack adalah serangan di mana attacker:
Menangkap request yang valid
Menyimpan request tersebut
Mengirim ulang request yang sama
Server memproses ulang request seolah request baru
Ilustrasi:
User Claim Reward → Request valid
Attacker Capture Request
Attacker Re-send Request
Server memproses ulang
Reward didapat lagi
Dampak:
Double reward
Duplicate transaction
Currency abuse
Inventory manipulation
Session abuse
3. HTTP Request Structure
Contoh request HTTP:
POST /api/claim HTTP/1.1
Host: api.examplegame.com
Content-Type: application/json
X-Authorization: abc123xyz
User-Agent: GameClient/1.0
{
"rewardId": "daily_bonus"
}
Komponen utama:
Request Line
POST /api/claim HTTP/1.1
Menjelaskan:
Method: POST
Endpoint: /api/claim
Protocol: HTTP/1.1
Header
X-Authorization: abc123xyz
Header ini biasanya digunakan untuk:
Session token
JWT token
API token
Play session ticket
Body
{
"rewardId": "daily_bonus"
}
Body berisi data utama request.
4. Header X-Authorization
X-Authorization adalah custom HTTP header yang digunakan untuk autentikasi.
Contoh:
X-Authorization: 53ABAA1D29FA
Fungsi:
Mengidentifikasi user
Memvalidasi session
Mengontrol akses API
Jika token ini:
maka risiko replay meningkat.
5. Telerik Fiddler
Telerik Fiddler Classic adalah tool untuk debugging HTTP traffic.
Fungsi:
Capture HTTP request
Capture HTTP response
Melihat header
Melihat body JSON
Debug API
Arsitektur:
Mobile App
↓
Fiddler Proxy
↓
API Server
Fiddler bekerja sebagai proxy di antara client dan server.
6. Analisis Request Menggunakan Fiddler
Security engineer biasanya menganalisis request sensitif seperti:
Login
Payment
Reward claim
Coupon redeem
Hal yang diperiksa:
Apakah ada timestamp?
Contoh:
{
"timestamp": 1710001112
}
Jika tidak ada timestamp, request lama mungkin masih valid.
Apakah ada nonce?
Contoh:
{
"nonce": "A1B2C3"
}
Nonce adalah nilai unik per request.
Jika nonce sama digunakan dua kali, server harus menolak.
Apakah ada signature?
Contoh:
{
"signature": "sha256hash"
}
Signature mencegah modifikasi request.
7. Contoh Vulnerability
Misalkan server memiliki endpoint:
POST /claimReward
Kode backend:
def claim_reward(user):
user.coins += 100
Masalah:
Jika request dikirim ulang berkali-kali:
100 coin
200 coin
300 coin
dst
Ini adalah replay vulnerability.
8. Proteksi Replay Attack
8.1 Nonce Validation
Setiap request punya nonce unik.
Client:
{
"nonce": "9F33AB"
}
Server:
Pseudo-code:
if nonce in used_nonce:
reject()
8.2 Timestamp Validation
Request hanya valid dalam window tertentu.
Contoh:
if current_time - request_time > 30:
reject()
8.3 Signature / HMAC
Request ditandatangani.
Contoh:
signature = HMAC(secret, body + timestamp)
Keuntungan:
8.4 Idempotency Key
Digunakan pada transaksi.
Header:
Idempotency-Key: 123-ABC
Jika key sama:
8.5 Server-side Validation
Jangan percaya client.
Buruk:
if request.reward == "daily":
give_reward()
Bagus:
if user.last_claim != today:
give_reward()
9. Simulasi Lab Aman
Untuk pembelajaran legal, replay attack sebaiknya dilakukan pada:
localhost
mock server
staging environment
sandbox
Contoh:
Flask API + Fiddler + Dummy Mobile App
Bukan pada:
game publik
API production
layanan pihak ketiga
10. Kesimpulan
Replay attack terjadi ketika request valid dikirim ulang dan server gagal mendeteksi duplikasi. Kerentanan ini sering muncul pada API yang tidak memiliki:
nonce
timestamp
signature
idempotency validation
Penggunaan tool seperti Telerik Fiddler sangat membantu developer dan security engineer untuk menganalisis traffic HTTP dan mengidentifikasi kelemahan keamanan pada API. Pencegahan replay attack harus dilakukan di sisi server melalui validasi state, request uniqueness, dan mekanisme autentikasi yang kuat.
Discussion (0)