Bahkan jika Anda hanya mengikuti secara longgar peristiwa kelompok peretas Anonymous dan LulzSec, Anda mungkin pernah mendengar tentang situs web dan layanan yang diretas, seperti hacks Sony yang terkenal. Pernahkah Anda bertanya-tanya bagaimana mereka melakukannya?
Ada sejumlah alat dan teknik yang digunakan kelompok-kelompok ini, dan sementara kami tidak mencoba memberi Anda panduan untuk melakukan ini sendiri, berguna untuk memahami apa yang sedang terjadi. Dua dari serangan yang Anda dengar secara konsisten tentang mereka menggunakan adalah "(Distributed) Denial of Service" (DDoS) dan "SQL Suntikan" (SQLI). Begini cara kerjanya.
Gambar oleh xkcd
Apa itu?
Sebuah "penolakan layanan" (kadang-kadang disebut serangan "distributed denial of service" atau DDoS) terjadi ketika sebuah sistem, dalam hal ini server web, menerima begitu banyak permintaan pada satu waktu ketika sumber daya server kelebihan beban sistem hanya terkunci dan mati. Tujuan dan hasil dari serangan DDoS yang sukses adalah situs web di server target tidak tersedia untuk permintaan lalu lintas yang sah.
Bagaimana cara kerjanya?
Logistik serangan DDoS mungkin paling baik dijelaskan dengan sebuah contoh.
Bayangkan satu juta orang (para penyerang) bersama-sama dengan tujuan menghambat bisnis Perusahaan X dengan menurunkan pusat panggilan mereka. Para penyerang berkoordinasi sehingga pada hari Selasa jam 9 pagi mereka semua akan menghubungi nomor telepon Perusahaan X. Kemungkinan besar, sistem telepon Perusahaan X tidak akan mampu menangani jutaan panggilan sekaligus sehingga semua jalur yang masuk akan diikat oleh para penyerang. Hasilnya adalah bahwa panggilan pelanggan yang sah (yaitu mereka yang bukan penyerang) tidak dapat melewati karena sistem telepon terikat menangani panggilan dari penyerang. Jadi pada intinya Perusahaan X berpotensi kehilangan bisnis karena permintaan yang sah tidak dapat dilalui.
Serangan DDoS pada server web bekerja dengan cara yang persis sama. Karena hampir tidak ada cara untuk mengetahui lalu lintas apa yang bersumber dari permintaan yang sah vs penyerang sampai server web memproses permintaan, jenis serangan ini biasanya sangat efektif.
Melaksanakan serangan itu
Karena sifat "brute force" dari serangan DDoS, Anda perlu memiliki banyak komputer yang semuanya terkoordinasi untuk menyerang pada saat yang bersamaan. Meninjau kembali contoh call centre kami, ini akan mengharuskan semua penyerang untuk tahu menelepon pukul 9 pagi dan benar-benar menelepon pada waktu itu. Sementara prinsip ini pasti akan bekerja ketika datang untuk menyerang server web, itu menjadi lebih mudah ketika komputer zombie, bukan komputer berawak yang sebenarnya, dimanfaatkan.
Seperti yang Anda ketahui, ada banyak varian malware dan trojan yang, sekali di sistem Anda, tertidur dan kadang-kadang "telepon rumah" untuk instruksi. Salah satu dari instruksi ini dapat, misalnya, mengirim permintaan ulang ke server web Perusahaan X pada pukul 9 pagi. Jadi dengan satu pembaruan ke lokasi rumah dari masing-masing malware, penyerang tunggal dapat langsung mengoordinasikan ratusan ribu komputer yang disusupi untuk melakukan serangan DDoS besar-besaran.
Keindahan memanfaatkan komputer zombie tidak hanya dalam efektivitasnya, tetapi juga dalam anonimitasnya sebagai penyerang tidak benar-benar harus menggunakan komputer mereka sama sekali untuk melakukan serangan.
Apa itu?
Serangan "SQL injection" (SQLI) adalah eksploit yang memanfaatkan teknik pengembangan web yang buruk dan, biasanya dikombinasikan dengan, keamanan basis data yang salah. Hasil dari serangan yang sukses dapat berkisar dari menyamar sebagai akun pengguna hingga kompromi lengkap dari masing-masing basis data atau server. Tidak seperti serangan DDoS, serangan SQLI benar-benar dan mudah dicegah jika aplikasi web diprogram dengan tepat.
Melaksanakan serangan itu
Setiap kali Anda login ke situs web dan memasukkan nama pengguna dan kata sandi Anda, untuk menguji kredensial Anda, aplikasi web dapat menjalankan pertanyaan seperti berikut:
PILIH UserID DARI Pengguna WHERE UserName = "myuser" DAN Sandi = "mypass";
Catatan: nilai string dalam kueri SQL harus diapit oleh tanda kutip tunggal yang menyebabkannya muncul di sekitar nilai yang dimasukkan pengguna.
Jadi kombinasi nama pengguna yang dimasukkan (myuser) dan kata sandi (mypass) harus cocok dengan entri di tabel Pengguna agar UserID dikembalikan. Jika tidak ada kecocokan, tidak ada UserID yang dikembalikan sehingga kredensial masuk tidak valid. Sementara implementasi tertentu mungkin berbeda, mekanika cukup standar.
Jadi sekarang mari kita lihat kueri otentikasi template yang dapat kita gantikan nilai-nilai yang dimasukkan pengguna pada formulir web:
PILIH UserID DARI Pengguna WHERE UserName = "[user]" DAN Sandi = "[pass]"
Pada pandangan pertama ini mungkin tampak seperti langkah sederhana dan logis untuk memvalidasi pengguna dengan mudah, namun jika substitusi sederhana dari nilai yang dimasukkan pengguna dilakukan pada template ini, ia rentan terhadap serangan SQLI.
Misalnya, anggap "myuser'-" dimasukkan di bidang nama pengguna dan "salah" dimasukkan dalam kata sandi. Dengan menggunakan substitusi sederhana dalam permintaan template kami, kami akan mendapatkan ini:
PILIH UserID DARI Pengguna WHERE UserName = "myuser" - 'AND Password = "salah paham"
Kunci untuk pernyataan ini adalah dimasukkannya dua tanda hubung (--)
. Ini adalah token komentar awal untuk pernyataan SQL, sehingga apa pun yang muncul setelah dua tanda hubung (inklusif) akan diabaikan. Pada dasarnya, permintaan di atas dijalankan oleh database sebagai:
PILIH UserID DARI Pengguna WHERE UserName = "myuser"
Kelalaian yang mencolok di sini adalah kurangnya pemeriksaan kata sandi.Dengan memasukkan dua tanda pisah sebagai bagian dari bidang pengguna, kami benar-benar melewati kondisi pemeriksaan kata sandi dan dapat masuk sebagai "myuser" tanpa mengetahui kata sandinya. Tindakan memanipulasi kueri ini untuk menghasilkan hasil yang tidak diinginkan adalah serangan injeksi SQL.
Kerusakan apa yang bisa dilakukan?
Serangan injeksi SQL disebabkan oleh pengkodean aplikasi yang lalai dan tidak bertanggung jawab dan benar-benar dapat dicegah (yang akan kita bahas suatu saat), namun tingkat kerusakan yang dapat dilakukan tergantung pada pengaturan database. Agar aplikasi web untuk berkomunikasi dengan database backend, aplikasi harus menyediakan login ke database (catatan, ini berbeda dari login pengguna ke situs web itu sendiri). Tergantung pada izin apa yang diperlukan oleh aplikasi web, akun database ini dapat meminta apa pun dari izin baca / tulis di tabel yang ada hanya untuk akses basis data penuh. Jika ini tidak jelas sekarang, beberapa contoh harus membantu memberikan beberapa kejelasan.
Berdasarkan contoh di atas, Anda dapat melihat bahwa dengan memasukkan, misalnya, "youruser '-", "admin' -"
atau nama pengguna lainnya, kami dapat langsung masuk ke situs sebagai pengguna tanpa mengetahui kata sandinya. Setelah kita berada di sistem tidak tahu kita bukan benar-benar pengguna itu sehingga kita memiliki akses penuh ke akun masing-masing. Perizinan database tidak akan menyediakan jaring pengaman untuk ini karena, biasanya, situs web harus memiliki setidaknya akses baca / tulis ke database masing-masing.
Sekarang mari kita asumsikan situs web memiliki kontrol penuh dari database masing-masing yang memberikan kemampuan untuk menghapus catatan, menambah / menghapus tabel, menambah akun keamanan baru, dll. Penting untuk dicatat bahwa beberapa aplikasi web bisa memerlukan jenis izin ini sehingga tidak otomatis merupakan hal buruk yang diberikan kontrol penuh.
Jadi untuk menggambarkan kerusakan yang dapat dilakukan dalam situasi ini, kami akan menggunakan contoh yang disediakan di komik di atas dengan memasukkan berikut ini ke dalam bidang nama pengguna: "Robert '; DROP TABLE Users; -".
Setelah substitusi sederhana, kueri autentikasi menjadi:
PILIH UserID DARI Pengguna WHERE UserName = "Robert"; DROP TABLE Users; - 'AND Password = "keliru"
Catatan: titik koma dalam kueri SQL digunakan untuk menandai akhir dari pernyataan tertentu dan awal dari pernyataan baru.
Yang dieksekusi oleh database sebagai:
PILIH UserID DARI Pengguna WHERE UserName = "Robert"
DROP TABLE Users
Jadi seperti itu, kami telah menggunakan serangan SQLI untuk menghapus seluruh tabel Pengguna.
Tentu saja, jauh lebih buruk dapat dilakukan karena, tergantung izin SQL yang diizinkan, penyerang dapat mengubah nilai, membuang tabel (atau seluruh database itu sendiri) ke file teks, membuat akun masuk baru atau bahkan membajak seluruh pemasangan basis data.
Mencegah serangan injeksi SQL
Seperti yang telah disebutkan beberapa kali sebelumnya, serangan injeksi SQL mudah dicegah. Salah satu aturan utama pengembangan web adalah Anda tidak pernah secara membuta mempercayai input pengguna seperti yang kita lakukan ketika kita melakukan substitusi sederhana dalam permintaan template kami di atas.
Serangan SQLI mudah digagalkan oleh apa yang disebut sanitasi (atau melarikan diri) masukan Anda. Proses sanitasi sebenarnya cukup sepele karena semua itu pada dasarnya dilakukan adalah menangani setiap kutipan kutipan tunggal (') karakter dengan tepat sehingga mereka tidak dapat digunakan untuk mengakhiri secara prematur string di dalam pernyataan SQL.
Sebagai contoh, jika Anda ingin mencari "O'neil" dalam database, Anda tidak dapat menggunakan substitusi sederhana karena kutipan tunggal setelah O akan menyebabkan string untuk mengakhiri secara prematur. Sebaliknya Anda membersihkannya dengan menggunakan karakter escape database masing-masing. Mari kita asumsikan karakter escape untuk kutipan tunggal inline adalah prefacing setiap kutipan dengan simbol \. Jadi "O'neal" akan disanitasi sebagai "O \ 'neil".
Tindakan sanitasi sederhana ini cukup banyak mencegah serangan SQLI. Untuk mengilustrasikan, mari meninjau kembali contoh kami sebelumnya dan melihat kueri yang dihasilkan ketika input pengguna disanitasi.
myuser '-
/ salah jalan:
PILIH UserID DARI Pengguna DI MANA UserName = "myuser \" - 'AND Password = "keliru"
Karena kutipan tunggal setelah myuser di-escape (berarti itu dianggap sebagai bagian dari nilai target), database akan mencari nama User dari "myuser '-".
Selain itu, karena dash termasuk dalam nilai string dan bukan pernyataan SQL itu sendiri, mereka akan dianggap sebagai bagian dari nilai target, bukan ditafsirkan sebagai komentar SQL.
Robert '; DROP TABLE Users; -
/ salah jalan:
PILIH UserID DARI Pengguna WHERE UserName = "Robert \"; DROP TABLE Users; - 'AND Password = "keliru"
Hanya dengan melarikan diri kutipan tunggal setelah Robert, baik titik koma dan tanda pisah yang terkandung dalam string pencarian UserName sehingga database akan benar-benar mencari "Robert '; DROP TABLE Users; -"
alih-alih mengeksekusi penghapusan tabel.
Sementara serangan web berevolusi dan menjadi lebih canggih atau fokus pada titik masuk yang berbeda, penting untuk diingat untuk melindungi terhadap serangan yang dicoba dan benar yang telah menjadi inspirasi dari beberapa "alat peretas" yang tersedia bebas yang dirancang untuk mengeksploitasinya.
Beberapa jenis serangan, seperti DDoS, tidak dapat dengan mudah dihindari sementara yang lain, seperti SQLI, dapat. Namun, kerusakan yang dapat dilakukan oleh jenis serangan ini dapat berkisar dari ketidaknyamanan hingga bencana tergantung pada tindakan pencegahan yang diambil.