Kategori: dasar-security

Ada yang bertanya ke saya: bagaimana sih caranya mencari bug di aplikasi? Karena jawabannya tidak bisa ditulis singkat di chat, di tulisan kali ini saya akan berusaha menjawab pertanyaan itu.

Apa itu bug?

Kalau Anda disuruh mencari sebuah benda tapi tidak tahu benda itu seperti apa bentuknya maka Anda tidak akan bisa menemukannya (Contoh: tolong ambil logic analyzer di laci saya). Sama halnya dengan bug: pertama pahami dulu berbagai jenis bug yang ada, baru Anda bisa menemukannya.

Contoh-contoh bug web misalnya: SQL Injection, IDOR, XSS, dan command injection. Contoh bug aplikasi misalnya: buffer overflow. Selain tahu apa itu sebuah bug, kita juga perlu tahu bagaimana cara mengeksploitasinya.

Black box testing

Ini testing yang paling umum. Kita coba-coba berbagai input dengan harapan keluar suatu pesan error yang bisa menunjukkan kesalahan di sebuah program. Contoh kecil: jika ada input petik tunggal (‘) dan programnya menampilkan SQL error, maka kemungkinan ada bug SQL injection.

Lanjutkan membaca “Mencari bug”

Bug Insecure Direct Object References (IDOR) ini merupakan bug yang sangat sederhana, sangat umum dan biasanya sangat berbahaya. Intinya pengguna aplikasi bisa mengubah input sedemikian hingga bisa mengakses objek/data yang bukan miliknya.

Bug paling sederhana adalah jika ada URL seperti ini:

http://example.com/edit.php?produk=1

Jika kita ganti produk menjadi 2 (atau nilai lain) dan keluar detail produk yang seharusnya bukan milik kita, itu namanya IDOR. Sering kali bug IDOR tidak bisa dieksploitasi dengan sederhana seperti itu. Biasanya untuk mengeksploitasi bug semacam ini kita akan memanfaatkan intercepting proxy seperti burp suit atau zaproxy (pernah saya bahas di sini).

Kadang kala ketika berusaha mengedit suatu data, kita tidak bisa memakai IDOR, tapi ketika kita menekan tombol “UPDATE” dan datanya di POST ke server, ternyata kita bisa mengedit id produknya. Jadi dalam kasus ini kita bisa menimpa/update produk lain walaupun tidak bisa melihat hasilnya.

Dalam aplikasi mobile, IDOR ini juga banyak ditemui, tapi secara umum lebih sulit dieksploitasi. Pertama kita perlu mensetup proxy, lalu jika aplikasinya melakukan SSL pinning maka perlu dibypass, dan kadang kala di atas itu masih ada enkripsi custom.

IDOR yang tipenya sangat berbahaya adalah dalam aplikasi yang melibatkan uang. Sering kali saya temu kasus di mana kita bisa mengganti id pengirim transaksi sehingga bisa memindahkan uang dari satu account ke yang lain. Kebanyakan kasus ini terjadi pada aplikasi mobile yang mengakses API dari web dan dienkripsi dengan sangat ribet. Proteksi di sisi client sering kali lebih dipentingkan daripada sisi server.

Ini hal dasar dalam protokol HTTP yang sangat berguna untuk security. Cookie adalah data kecil yang dikirim oleh server ke browser, dan akan dikirimkan kembali oleh browser ketika mengunjungi website yang sama. Analoginya jika kita pergi ke dokter, kita diberi kartu, dan ketika kembali lagi ke dokter tersebut, kita memberikan lagi kartunya supaya bisa dikenali.

Dalam kasus sebuah kartu berobat, ada beberapa opsi dalam penyimpanan data. Mungkin kita hanya diberi kartu dengan nomor pasien, lalu seluruh datanya disimpan di dalam komputer klinik atau rumah sakit (atau sekedar di sebuah folder khusus).

Lanjutkan membaca “HTTP Cookie dan Session”

Kadang saya merasa lucu membaca komentar dari posting saya. Kalau postingnya terlalu kompleks (seperti berbagai hal yang yang saya tuliskan di blog saya yang berbahasa inggris: tinyhack.com), sedikit sekali yang paham jadi kurang ada komentar yang membangun. Sedangkan jika terlalu sederhana, seperti posting sebelumnya, banyak yang “protes”, atau malah nggak percaya.

Beberapa komentar yang muncul misalnya:

• Masak bank securitynya seperti itu?
• Itu kan POST, kok diakses pake GET?

Untuk hal pertama: jangan pikir security bank itu sangat ketat. Untuk hal kedua: sepertinya banyak pemula kurang paham mengenai POST dan GET, dan perlu penjelasan lebih lanjut.

Lanjutkan membaca “Security untuk pemula: POST dan GET”

Ini cuma sekedar cerita ketika secara random saya menemukan bug di situs sebuah bank dengan skrip yang saya ceritakan di posting sebelumnya. Para bug hunter sangat menyukai berbagai writeup dari bug hunter lain, karena mereka jadi belajar: “apa sih bug yang bisa dieksploit” (kadang ternyata bug sederhana sekali) dan “kok bisa sih ketemu bugnya?” (kadang bagian ini lebih menarik).

Kadang saya menulis writeup yang super rumit (biasanya di https://tinyhack.com/), tapi kali ini saya akan memberikan bug super sederhana: SQL Injection. Cerita ini di kategori: “kok bisa ketemu bugnya?”. Writeup ini ditujukan untuk pemula.

Lanjutkan membaca “Bug di sebuah bank”

Ini merupakan cerita teknis dengan inti bahwa: jika website Anda lemah, pasti akan ada yang menemukan bugnya. Bug ini bisa ditemukan dengan berbagai cara, dan di artikel ini akan saya tulis berbagai caranya.

Google Dorking

Dengan menggunakan Google saja kita bisa menemukan banyak situs lemah. Google dorking adalah memakai parameter advanced di Google. Saya tidak akan memberikan contohnya querynya di sini walau mudah di cari di internet.

Jadi cara kerjanya secara sederhana seperti ini:

• Ada webapp atau plugin atau komponen yang memiliki bug
• Komponen ini memiliki ciri-ciri misalnya urlnya /abc/def/, atau memiliki teks “Powered By”

Dengan query yang tepat, kita bisa mendapatkan daftar semua situs yang memiliki bug seperti itu. Tentunya ini hanya bisa ditemukan jika website diindeks oleh Google.

Banyak perusahaan yang memiliki banyak subdomain yang tidak diindeks oleh Google, namun bukan berarti ini tidak bisa ditemukan.

Lanjutkan membaca “Web dengan security lemah pasti ditemukan hacker”