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.

1. Predict

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).

2. 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.

3. 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.

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:

http://mail.telkom.net/Session/1348362-ri33mMyYqlqEBizKv9lW-kmbcuww/Mailbox.wssp?Mailbox=INBOX

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.