Deskripsi kerentanan adalah satu hal, tetapi berusaha menemukan kerentanan dan bekerja dengannya adalah masalah yang sama sekali berbeda. Untuk tujuan inilah aplikasi khusus dibuat dan dikembangkan di mana kerentanan sengaja ditinggalkan. Jika Anda mengetik di mesin pencari kueri "Aplikasi yang sangat rentan", Anda tidak akan menemukan selusin tautan.
Dalam seri ini, kita akan mulai menganalisis kerentanan dari OWASP Top 10, dan saya akan menggunakan aplikasi yang secara sengaja rentan sebagai tempat pengujian. Dalam kasus saya ini adalah OWASP Mutillidae II. Ini bukan pilihan terbaik, tetapi kerentanan di dalamnya disusun persis seperti yang dibutuhkan untuk tujuan pendidikan.
Berikan tanganmuJadi, kerentanan pertama adalah suntikan. OWASP Mutillidae II menyajikan beberapa opsi, dan kami akan mulai dengan "ekstrak data SQLi" yang paling sederhana> "Info Pengguna (SQL)".
Di depan kami adalah jendela autentikasi biasa - yang berinteraksi dengan Anda setiap hari:
Kami tidak memiliki nama pengguna atau kata sandi - tidak ada. Kalau begitu, mari mendaftar di situs ini. Saya akan membuat pengguna dengan nama belowzero273 dan kata sandi 123:
Hebat! Kami membuat akun, tulisan “1 baris disisipkan” mengisyaratkan bahwa baris telah ditambahkan, tampaknya ke tabel, karena sejumlah besar akun termudah untuk disimpan dalam DBMS.
Sekarang login dengan akun baru kami di sistem. Berhasil, bagus.
Ketika kita bekerja dengan halaman web, kita harus selalu ingat bahwa interaksi kita tidak terbatas pada konten halaman. Ada juga bilah alamat, misalnya. Di mana kita bisa melihat banyak hal menarik:
http://127.0.0.1/mutillidae/index.php?page=user-info.php&username=belowzero273&password=123&user-info-php-submit-button=View+Account+Details
Sebagai contoh, kita melihat bahwa kata sandi ditransmisikan dalam teks yang jelas. Ini buruk, karena lalu lintas dapat dicegat. Tapi mungkin bukan bencana seperti itu - lalu lintas akan dibungkus dengan TLS.
Mari kita coba ganti kata sandi tepat di baris, misalnya, bagian ini:
username=belowzero273&password=123
pada
username=belowzero273&password=12345
Kata sandi, tentu saja, sekarang salah, dan kami menerima kesalahan yang sesuai: dan ini buruk. Itu buruk, karena dengan bantuan THC-Hydra, yang saya bicarakan di
sini , kita dapat mengambil kata sandi ini dengan menggantikannya ke dalam baris ini tanpa bentuk apa pun. Tetapi ini tidak selalu dapat menghasilkan hasil yang positif dalam periode waktu yang dapat diterima.
Kami tidak punya banyak waktu, jadi mari kita coba yang lain. Tambahkan tanda kutip ke kata sandi salah kami:
username=belowzero273&password=123
pada
username=belowzero273&password=12345'
Sekarang kami mendapat kesalahan penuh:
Tidak ada yang salah dengan kesalahan. Bagaimana lagi cara mendiagnosis kerusakan jika kita tidak melihat umpan balik dari aplikasi? Tetapi kesalahan seperti itu seharusnya tidak terlihat oleh pengguna dan penyerang.
Sekarang kita melihat bahwa sebenarnya, ketika kita mengklik tombol "Kirim" di latar belakang, permintaan berikut dijalankan:
SELECT * FROM accounts WHERE username='belowzero273' AND password='12345'
Apostrof menonjol variabel string. Aplikasi web kami tidak memfilter data yang dimasukkan pengguna, dan dengan apostrof tambahan kami, kami melanggar permintaan. Sekarang kita tahu seperti apa query ini di latar belakang, kita perlu mencari cara mengubahnya untuk mendapatkan informasi yang kita butuhkan dari database.
Harap dicatat bahwa permintaan berisi fungsi dan, yaitu, kedua variabel harus benar, karena ini adalah kombinasi dari login dan kata sandi. Masuk akal.
Mari kita lihat sekilas pertanyaan ini:
SELECT * FROM accounts WHERE (username='belowzero273' AND password='12345') OR 1='1
Kami telah menambahkan kondisi yang selalu dipenuhi: 1 = 1. Dan permintaan akan dieksekusi dalam dua kasus: apakah kami menebak kombinasi nama pengguna dan kata sandi, atau 1 = 1. Artinya, itu akan selalu dieksekusi.
Ternyata yang berikut ini dapat ditentukan sebagai kata sandi:
' or 1='1
Apostrof di akhir baris tidak lagi diperlukan, logika aplikasi web akan menyediakannya untuk kita. Boom! Dan kami mendapat pilihan dari database dengan semua akun:
Keren, sekarang kami memiliki info masuk dan kata sandi dari semua orang yang terdaftar dalam aplikasi ini. Dan lebih buruk lagi, kata sandi di sini jelas.
Apa yang salah dengan itu? Dan fakta bahwa kebanyakan orang menggunakan nama pengguna dan kata sandi yang sama untuk semua situs. Dan setelah mendaftar dengan cara ini di satu situs yang rentan, mereka mungkin kehilangan akses ke semua situs mereka.
Anda juga dapat bereksperimen dengan kerentanan ini, misalnya, mencari kata sandi administrator. Untuk melakukan ini, gantikan login:
admin' or 1='1
Yaitu, kami sedang mencari entri di database di mana nama pengguna adalah admin, dan kata sandinya ada.
!
Kata sandi tidak selalu disimpan dalam teks yang jelas, tetapi itu tidak berarti bahwa otentikasi dilakukan dengan aman. Mari kita lihat contoh kedua dalam OWASP Mutillidae II "SQLi Bypass Authentication"> "Login".
Otentikasi dapat dilewati dengan membuat permintaan yang sesuai. Baru-baru ini, kami membuat akun belowzero273, dan sekarang mari kita tentukan sebagai login:
' or ('a' = 'a' and username='belowzero273')
Di sini kita memeriksa kondisi yang jelas benar - a = a, dan login - belowzero273, dan juga memotong bagian permintaan dengan bantuan "-".
Tekan Enter dan berhasil masuk ke sistem meskipun kami belum menentukan kata sandi Anda di mana pun.
Sangat mudahTerkadang pelanggan bertanya, apakah benar-benar mudah untuk melewati otentikasi di situs kami? Biasanya saya menjawab pertanyaan dengan pertanyaan: "Apakah Anda yakin ini belum terjadi?" Suntikan tidak sengaja di bagian atas peringkat OWASP, karena kerentanan ini, sebagai suatu peraturan, memiliki konsekuensi bencana jika diimplementasikan.
Dalam praktiknya, tentu saja, semuanya agak lebih rumit daripada dalam contoh-contoh ini. Tetapi pada contoh-contoh dasar seperti itulah pemahaman tentang masalah yang lebih dalam mulai terbentuk. Kami akan melanjutkan waktu berikutnya.
Baca blog penulis
di tautan ini .