Session Hijacking Basics
What really is Session?
Bayangkan ketika anda nonton bioskop,
lalu tiba-tiba di tengah pertunjukan anda ingin ke toilet yang letaknya
di luar studio. Setelah anda selesai dari toilet, menurut anda apakah
anda dibolehkan masuk atau diminta membeli tiket lagi? Bila anda diminta
membeli tiket lagi, berarti dia “lupa” bahwa anda adalah penonton yang
sah. Bagaimana cara penjaga pintu studio mengingat bahwa anda adalah
pentonton yang sah? Saking banyaknya pentonton tidak mungkin penjaga
hafal wajah tiap penonton. Maka cara yang dipakai adalah dengan bukti
berupa tiket masuk.
Itulah ilustrasi dari session. Mulai
bioskop memutar film sampai selesai adalah satu sesi. Setiap penonton
bebas keluar masuk studio selama sesi masih berlangsung, namun setelah
sesi selesai, penonton tidak boleh lagi masuk studio. Karena penjaga
pintu studio tidak mungkin mengingat setiap penonton, maka diperlukan
bukti berupa tiket.
HTTP adalah protokol yang sifatnya
stateless, artinya setiap transaksi request dan response adalah bebas,
tidak ada hubungannya dengan transaksi sebelum atau sesudahnya. Server
tidak mungkin mengingat dan mengetahui bahwa transaksi X dan transaksi Y
dilakukan oleh orang yang sama.
Session Identifier is Your Ticket
Seperti pada ilustrasi bioskop, untuk membantu
penjaga pintu studio mengetahui setiap penonton yang masuk adalah
penonton yang sah diperlukan bukti berupa tiket. Dalam HTTP, tiket
bioskop itu berupa session identifier yang tidak lain adalah untaian
karakter dan angka yang panjang dan acak.
Ketika pengunjung pertama kali datang,
server akan memberikan tiket berupa session id. Ketika server menerima
request dari pengunjung yang membawa session id, server akan memeriksa
apakah session id itu valid. Jika session id valid, maka server yakin
bahwa request ini datang dari “returning visitor” bukan orang asing.
Ingat ilustrasi bioskop di awal, ini seperti penjaga pintu studio yakin
bahwa anda adalah penonton yang kembali masuk setelah sebelumnya keluar
ke toilet.
Ada 2 media untuk membawa sessionid,
yaitu cookie dan URL. Cookie biasanya berupa file text yang disimpan
oleh browser dan dikirimkan kembali ke server bersama setiap request.
Sedangkan sessionid yang dibawa melalui URL umumnya berbentuk parameter
seperti ?sessionid=123123 .
Server umumnya memberikan sessionid melalui cookie karena cara ini lebih aman dari cara URL.
Web Application Session
Dalam web aplikasi umumnya pengunjung
diharuskan memasukkan username dan password, setelah itu baru pengunjung
bisa menikmati beragam fasilitas yang diberikan sampai pengunjung
melakukan logout. Mari kita lihat apa yang terjadi ketika pengunjung
melakukan login.
Ketika pengunjung memasukkan username
(katakanlah “Budi”) dan password yang benar, web server akan memberikan
tiket berupa sessionid katakanlah “1234″. Kemudian dalam database akan
dicatat bahwa sessionid “1234″ adalah milik seorang pengunjung yang
bernama “Budi”. Setiap kali ada request yang membawa tiket sessionid
“1234″, server yakin bahwa request itu adalah dari pengunjung yang
namanya adalah “Budi”. Tiket ini akan terus valid sampai suatu saat
“Budi” melakukan logout. Setelah logout, ketika ada request dengan
sessionid “1234″, maka server akan tahu bahwa sessionid itu sudah tidak
valid, dan memaksa anda login.
Stealing Session
Bayangkan bila ketika anda keluar
bioskop untuk ke toilet, tiket anda jatuh dan saya temukan. Lalu saya
masuk ke studio dengan tiket itu, apakah saya diijinkan masuk? Tentu
saja boleh! Karena saya memegang bukti tak terbantahkan berupa tiket.
Sedangkan anda yang kehilangan tiket tidak akan boleh masuk studio
karena penjaga studio tidak hafal wajah anda.
Itulah yang akan terjadi bila seseorang
mencuri sessionid. Jika anda sedang baca email dan sessionid anda dicuri
orang lain, maka orang lain itu akan bisa juga membaca email anda dan
server akan yakin bahwa orang lain itu adalah anda.
Di internet, siapapun yang membawa sessionid anda akan menjadi anda!
Bagaimana cara mendapatkan sessionid
korban? Secara garis besar ada 3 kategori teknik untuk mendapatkan
sessionid, yaitu predict, capture dan fixate.
- Predict
- Capture
- (Passive) Sniffing.
Menyadap komunikasi http antara browser korban dan server web. Teknik ini sangat mungkin dilakukan untuk situs yang tidak dilindungi https karena paket http tidak ter-enkripsi.
- Man-in-them-middle (MITM).
Situs dengan https tidak bisa disniff secara passive. Man-in-the-middle attack diperlukan untuk sniffing komunikasi antara browser korban dan server yang dilindungi https. Namun tanpa sertifikat yang di-sign CA yang dipercaya browser, serangan ini mudah dicegah karena browser akan memberi warning bahwa sertifikat attacker tidak bisa dipercaya.
- Cross Site Request Forgery (CSRF).
CSRF attack bertujuan untuk membuat korban melakukan request yang mengandung sessionid. Bila sessionid disimpan dalam cookie, maka request akan mengandung sessionid dalam header cookie. (baca contoh PoC-nya di membajak session https permatanet). Bila sessionid disimpan dalam URL (url rewriting), maka request akan mengandung sessionid dalam header referer.
- Cross Site Scripting (XSS).
XSS dilakukan dengan cara meng-injeksi code javascript (client side script) yang akan dieksekusi oleh browser korban. Code javascript ini bertujuan mengirimkan cookie ke server yang sudah disiapkan attacker. Baca contoh PoC-nya di menjaring password klikBCA dengan XSS.
- (Passive) Sniffing.
- Fixate.
Kalau menebak dan menyadap sessionid sulit dilakukan, maka cara lain adalah dengan memaksa korban menggunakan sessionid yang sudah dipilih sebelumnya oleh attacker. Serangan ini disebut dengan session fixation attack.
Teknik ini mirip dengan judi togel, yaitu dengan cara
menebak-nebak angka. Kemungkinan berhasilnya tergantung dari tingkat
ke-acak-an sessionid. Bila sessionid tidak cukup random, bahkan
cenderung mengikuti suatu pola, maka kemungkinan sessionid bisa ditebak.
Namun umumnya sessionid sekarang sudah menggunakan fungsi random dan
ukurannya panjang, sehingga kecil kemungkinan berhasil dengan cara ini
(jauh lebih mudah menebak togel yang cuma 4 angka, daripada menebak
sessionid).
Session Telkom.net
Anda
ingin tahu bagaimana rasanya mencuri session? Benarkah bila anda
mendapatkan sessionid orang lain, maka anda bisa menjadi orang lain?
Untuk membuktikannya, anda harus mencoba sendiri. Contoh kasus yang
mudah adalah dalam session webmail telkom.net.
Saya pakai contoh telkom.net karena
telkom.net menyimpan sessionid dalam URL, bukan dalam cookie sehingga
lebih mudah untuk contoh. Jika anda login ke webmail telkom.net, maka
URL anda akan tampak seperti ini:
Dalam URL di atas sessionid adalah 1348362-ri33mMyYqlqEBizKv9lW-kmbcuww. Coba saja klik URL di atas. Anda akan melihat halaman login telkom.net dengan pesan error: Anda telah disconnect dari server. Silakan login kembali. Hal itu terjadi karena anda mengakses webmail dengan sessionid yang sudah tidak valid karena sudah pernah logout.
Untuk merasakan mencuri session, coba
saja buat account sendiri di mail.telkom.net, kemudian login. Setelah
anda berhasil login, copy URL anda lalu berikan URL itu pada teman anda
melalui Yahoo Messenger atau Email. Jika teman anda mengklik URL itu,
maka teman anda otomatis menjadi anda dan bisa melakukan semua hal yang
bisa anda lakukan. Atau anda bisa membuka URL anda di browser yang
berbeda, hasilnya akan sama saja, di browser yang lain juga akan terbuka
email anda.
Sekarang coba anda logout. Setelah
logout, anda buka kembali URL yang sudah anda copy sebelumnya. Kini anda
tidak bisa lagi membuka email anda karena sessionid sudah tidak valid.
Kesimpulan
Anda telah mengerti tentang session dan
melakukan pencurian session dengan cara manual “Copy-Paste”. Karena
artikel ini hanyalah introduction maka saya tidak menjelaskan tentang
teknik pencurian session yang lebih canggih. Dalam artikel lainnya saya
akan jelaskan teknik pencurian session yang lebih canggih.
Post a Comment