Bagaimana Hacker Mengambil alih Situs Web dengan SQL Injection dan DDoS

Daftar Isi:

Bagaimana Hacker Mengambil alih Situs Web dengan SQL Injection dan DDoS
Bagaimana Hacker Mengambil alih Situs Web dengan SQL Injection dan DDoS

Video: Bagaimana Hacker Mengambil alih Situs Web dengan SQL Injection dan DDoS

Video: Bagaimana Hacker Mengambil alih Situs Web dengan SQL Injection dan DDoS
Video: CSD 04 | Sudah Instal Linux Terus Ngapain? | Rekomendasi untuk User Linux Pemula - YouTube 2024, April
Anonim
Bahkan jika Anda hanya mengikuti secara longgar acara grup peretas Anonymous dan LulzSec, Anda mungkin pernah mendengar tentang situs web dan layanan diretas, seperti hacks Sony yang terkenal. Pernahkah Anda bertanya-tanya bagaimana mereka melakukannya?
Bahkan jika Anda hanya mengikuti secara longgar acara grup peretas Anonymous dan LulzSec, Anda mungkin pernah mendengar tentang situs web dan layanan 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, penting 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

Denial of Service Attack

Image
Image

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 (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 dapat 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 petunjuk ini, misalnya, adalah mengirim permintaan berulang 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 keefektifannya, tetapi juga dalam keanonimannya karena penyerang tidak benar-benar harus menggunakan komputer mereka sama sekali untuk melakukan serangan.

Serangan Injeksi SQL

Image
Image

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:

SELECT UserID FROM Users WHERE UserName='myuser' AND Password='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 autentikasi template yang dapat kita gantikan dengan nilai yang dimasukkan pengguna di formulir web:

SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[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 dalam bidang nama pengguna dan "salah" dimasukkan dalam kata sandi. Dengan menggunakan substitusi sederhana dalam permintaan template kami, kami akan mendapatkan ini:

SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'

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:

SELECT UserID FROM Users 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 berada dalam sistem, kami tidak tahu bahwa sebenarnya kami bukan pengguna itu, sehingga kami 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:

SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'

Catatan: titik koma dalam kueri SQL digunakan untuk menandai akhir dari pernyataan tertentu dan awal dari pernyataan baru.

Yang dieksekusi oleh database sebagai:

SELECT UserID FROM Users 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 adalah menangani setiap kutipan kutipan tunggal (‘) karakter secara tepat sehingga mereka tidak dapat digunakan untuk mengakhiri secara prematur string di dalam pernyataan SQL.

Misalnya, jika Anda ingin mencari "O’neil" dalam basis data, Anda tidak dapat menggunakan substitusi sederhana karena kutipan tunggal setelah O akan menyebabkan string berakhir secara prematur. Sebagai gantinya Anda membersihkannya dengan menggunakan karakter escape database yang bersangkutan. Mari kita asumsikan karakter pelolosan untuk kutipan tunggal inline adalah prefacing setiap kutipan dengan simbol. Jadi "O'neal" akan disterilkan sebagai "O 'neil".

Tindakan sanitasi sederhana ini cukup banyak mencegah serangan SQLI. Untuk mengilustrasikannya, mari kaji kembali contoh sebelumnya dan lihat kueri yang dihasilkan saat masukan pengguna disanitasi.

myuser'--

/ salah jalan:

SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'

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:

SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'

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.

Singkatnya

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.

Direkomendasikan: