Little boy questioned his mother, he asked what he can be in the future..with a sad smile, she tells him he can be anything he wants to be.... Boy said he’d become (an) astronaut and fly out into space crews around the universe he wanted to see the stars and also see other planets in outer space------------- "Why don’t we just keep dreaming, let’s keep our mind with dream and faith, as long as we wish we can make it come true, how old you are never forget your dream and keep dreaming "

Tuesday, 15 May 2018

SQL Injection (Injeksi SQL)

Serangan SQL menjadi sangat umum dikarenakan adanya database, yang sering mengandung informasi sensitif dan berharga, adalah target yang menarik. Salah satu serangan SQL yang paling umum adalah serangan injeksi SQL (SQL Injection).

Diskusi publik pertama tentang injeksi SQL mulai muncul sekitar tahun 1998. Pada tahun 2017, injeksi SQL dinilai sebagai serangan nomor satu di daftar 10 teratas OWASP.

Pada tahun 2012, sebuah grup hacker yang menyebut dirinya sebagai "D33DS Company" membocorkan alamat surel dan kata sandi untuk 450.000 akun Yahoo. D33DS mengatakan memperoleh data dengan mengeksekusi serangan injeksi SQL terhadap subdomain Yahoo yang tidak disebutkan namanya, yang telah diidentifikasi oleh pakar keamanan sebagai Yahoo Voices. (Sumber: Berita Yahoo)

Analis keamanan harus dapat mengenali kueri SQL yang mencurigakan untuk mendeteksi jika database relasional telah mengalami serangan injeksi SQL.

Serangan injeksi SQL terdiri dari memasukkan kueri SQL melalui data input dari klien ke aplikasi. Eksploitasi injeksi SQL yang berhasil dapat memungkinkan orang yang mengeksekusinya membaca data sensitif dari database, mengubah data basis data, menjalankan operasi administrasi pada database, dan, terkadang, mengeluarkan perintah ke sistem operasi.

Terkecuali aplikasi menggunakan validasi data terhadap masukan atau input secara ketat, akan menjadi rentan terhadap serangan injeksi SQL jika aplikasi menerima dan memproses data yang disediakan pengguna tanpa validasi data masukan apa pun, penyerang dapat mengirimkan string input perusak yang berbahaya untuk memicu serangan injeksi SQL.

Di bawah ini adalah contoh sederhana dari web server dengan halaman login dan backend SQL. Kueri SQL normal mungkin terlihat seperti ini:

SELECT UserID FROM user WHERE username = 'admin' AND password = 'i<3Cisco'

Filed admin dan i<3Cisco digunakan oleh pengguna saat proses login. Server SQL mencari tabel pengguna untuk menemukan entri pertama yang cocok dengan kredensial tersebut. Jika gagal, tidak ada yang akan dikembalikan dan pengguna tidak akan diizinkan untuk masuk. Jika berhasil, ID pengguna akan dikembalikan dan proses login akan dilanjutkan.

Berikut ini adalah kueri yang sama dengan injeksi SQL:

SELECT UserID FROM users WHERE username = 'anything' OR 1=1 -- AND password = 'hacktheplanet'

Sebagai seorang analis, jika Anda melihat string " OR 1 = 1 -- <space>" dalam bentuk respons HTTP, apa yang harus Anda curigai?
Bagian pertama dari kueri, SELECT UserID FROM users WHERE username =, adalah hardcoded, yang tidak dikontrol oleh penyerang.
Penyerang bermain di bagian lain, di mana nama pengguna di sini adalah anything. Tidak masalah apakah pengguna itu benar-benar ada atau tidak, karena OR 1 = 1 menimpa pemeriksaan nama pengguna. Karena menggunakan OR, bagian pertama bisa saja gagal (misalnya, nama pengguna tidak valid), tetapi kueri akan tetap berhasil (karena 1 selalu sama dengan 1).

Bagian terakhir dari query adalah kata sandi, tetapi karena penyerang menyediakan dua garis dan spasi (-- <spasi>), itu merupakan sebuah komentar. Meskipun penyerang mengetik hacktheplanet ke dalam field kata sandi, kata sandi tidak akan ditafsirkan oleh server SQL. Perhatikan bahwa harus ada spasi setelah tanda hubung ganda (--).

Hasilnya adalah bahwa permintaan akan berhasil, meskipun seharusnya gagal, mengingat nama pengguna dan kata sandi yang tidak valid. Masalahnya adalah penyerang akan masuk sebagai pengguna pertama yang cocok, yang bukan merupakan hal yang baik karena pengguna pertama dalam database umumnya adalah administrator. Serangan dapat dimodifikasi untuk menargetkan nama pengguna tertentu, tetapi penyerang harus tahu (atau menebak) nama pengguna itu.

Ada banyak variasi pada serangan ini, tergantung pada SQL server yang tepat. Komentar mungkin perlu tanda pound (#) bukan double-dash (-). Kutipan tunggal (') mungkin perlu berupa kutipan ganda ("). Singkatnya, ini tergantung pada SQL yang digunakan vendor, dan sintaks pernyataan SQL yang digunakan oleh web server. Analis harus hati-hati terhadap tanda kutip tunggal, tanda kutip ganda, dan titik koma, yang dapat digunakan untuk keluar dan menambahkan perintah SQL baru.

Sebagai seorang analis, jika Anda menemukan permintaan SQL seperti itu, Anda perlu menentukan ID pengguna mana yang digunakan oleh penyerang untuk masuk, kemudian mengidentifikasi informasi apa pun atau akses lebih lanjut yang dapat dimanfaatkan oleh penyerang setelah berhasil masuk.

Contoh berikut menunjukkan hasil kueri SQL setelah memasukkan ' or 1=1 -- <space> pada field nama (sekali lagi, ruang tambahan penting) :
Dalam hal ini, menggunakan query SQL tsb semua data akun untuk semua akun dalam database SQL berhasil diekstraksi.

Penanggulangan termasuk yang berikut:
  • Pengembang aplikasi harus mengikuti praktik terbaik untuk melakukan validasi masukan pengguna yang tepat, membatasi, dan membersihkan data input pengguna.
  • Referensi "the OWASP SQL Injection Prevention Cheat Sheet" : https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet.
  • Terapkan solusi IPS untuk mendeteksi dan mencegah injeksi SQL berbahaya.

No comments:

Post a Comment