Dalam artikel sebelumnya, saya menyarankan agar pembaca tahu bagaimana bahasa query SQL terstruktur secara rinci, serta bagaimana protokol HTTP bekerja. Tapi ini biasanya tidak demikian. Dan saya langsung ingat kisah yang digambarkan dalam salah satu buku favorit saya, "Pikiran yang Tidak Dapat Dipercayai," oleh Rob Brotherton. Ini menggambarkan percobaan berikut. Psikolog Rebecca Lawson bertanya kepada sekelompok subjek apakah mereka pernah naik sepeda dalam hidup mereka. Sebagian besar menjawab ya. Dia lebih lanjut bertanya apakah mereka tahu cara kerja sepeda. Sudah ada jawaban afirmatif yang lebih sedikit, tetapi masih sebagian besar. Dan kemudian dia menyarankan gambar berikut dan meminta untuk melengkapi sehingga sepeda ini bisa naik.
Dan kemudian hal yang paling menarik terjadi - lebih dari setengah orang tidak bisa melakukan ini. Tugas sederhana yang tampak ini menunjukkan bahwa kebanyakan orang tidak dapat membayangkan bagaimana sebuah sepeda bekerja. Tetapi hal yang paling menarik adalah bahwa mereka tidak mengerti bahwa mereka tidak mengetahui hal ini, tetapi mulai memahami ini hanya pada saat mereka harus menunjukkan pengetahuan ini.
Dengan HTTP dan SQL, hal yang sama terjadi. 90% pakar TI menulis pertanyaan SQL, setidaknya di laboratorium laboratorium di lembaga pendidikan mereka, orang bekerja dengan HTTP setiap hari sebagai pengguna, dan pakar TI yang sama dari waktu ke waktu mengkonfigurasi server web yang benar-benar bekerja dengan HTTP. Tetapi ketika Anda harus menjawab pertanyaan tertentu, kebodohan terjadi secara teratur.
Seorang analis keamanan informasi harus mengetahui teknologinya secara rinci, mengetahui nuansa dan kehalusannya. Jika kita tidak tahu bagaimana teknologi ini atau itu seharusnya bekerja, lalu bagaimana kita bisa mencari tahu apa yang salah dengannya?
Juga "suntikan"
Saya menyebutkan bahwa verifikasi input harus dilakukan di server, tetapi tidak pada klien. Dari waktu ke waktu, seseorang dapat menemukan formulir input di mana masing-masing elemen tidak aktif. Dan diasumsikan bahwa mereka akan menjadi aktif setelah kondisi tertentu terpenuhi. Atau, misalnya, bidang input nama pengguna adalah 7 karakter, sehingga membatasi panjang maksimum nama pengguna. Semua ini adalah praktik yang sangat buruk, dan inilah alasannya: elemen-elemen pada halaman yang telah diterima dapat diedit secara sewenang-wenang sebelum dikirim, tanpa sarana teknis khusus. Dalam OWASP Mutillidae II, ini dapat dilihat pada contoh "Lainnya"> "Kontrol" keamanan "sisi klien".
Berikut adalah formulir di bidang yang harus Anda masukkan angka acak, kali ini 2056694312. "Kesulitan" di sini adalah bahwa bidang memiliki batasan. Ada bidang "Hanya-baca" di mana angka 42 tidak dapat diganti, ada bidang "Kotak teks" terlalu pendek di mana nomor kami tidak dapat ditampung, ada bidang "Kotak Teks Nonaktif" yang dinonaktifkan yang tidak aktif, dan sebagainya.
Bahkan, tugas itu diselesaikan dengan sangat sederhana. Di browser (dalam kasus saya ini adalah Mozilla Firefox), buka konsol pengembang (F12) dan mulailah memeriksa elemen formulir.
Misalnya, bidang baca-saja terlihat seperti ini:
<input HTMLandXSSInjectionPoint="1" type="text" name="readonly_textbox" id="id_readonly_textbox" size="15" maxlength="15" required="required" autofocus="autofocus" readonly="readonly" value="42" />
Hapus readonly = ”readonly” dan voila: form dapat ditulis, kita dapat memasukkan nomor kita.
Nilai kami tidak cocok dengan bidang berikutnya, mari kita lihat elemen ini:
<input HTMLandXSSInjectionPoint="1" type="text" name="short_textbox" id="id_short_textbox" size="3" maxlength="3" required="required" />
Di sini kita perhatikan maxlength = ”3 ″. Ganti 3 dengan 333, sekarang kita dapat memasukkan nomor kita tanpa takut itu tidak akan cocok.
Omong-omong, ini bukan hanya tentang bidang masukan. Demikian pula, Anda dapat mengubah elemen apa pun, seperti kotak centang. Kode halaman terlihat seperti ini:
<input type="checkbox" name="checkbox" id="id_checkbox" value="2056694312" required="required" disabled="disabled" />
Ini sangat sederhana di sini, kami akan mengganti nilainya dengan nomor kami, dan sekarang akan dikirim ketika pengguna mengklik tombol.
Secara total, jika Anda tahu bagaimana HTML disusun, maka tidak akan sulit bagi Anda untuk memperbaiki formulir ini sehingga Anda memasukkan semua data yang diperlukan di sana. Cukup baca kembali bagian tentang Sindrom Sepeda =)
Bukan hanya SQL
Injeksi tidak selalu tentang database. Pada umumnya, dari formulir apa pun yang tidak memfilter data yang masuk, Anda bisa mendapatkan beberapa informasi tambahan. Dalam contoh "Injeksi Log Aplikasi"> "Pencarian DNS" ada formulir yang sesuai untuk permintaan DNS:
Memang, jika Anda memasukkan alamat di sana, misalnya, google.com, kami mendapatkan semua informasi yang diperlukan:
Namun, kerentanannya adalah bahwa selain perintah pertama yang valid, kita dapat memasukkan sesuatu yang lain. Misalnya, tentukan:
google.com && dir
dan sekarang output dari perintah jauh lebih menarik:
Kami membuat permintaan ke server DNS, tetapi selain itu, kami mengeksekusi perintah dir dan melihat apa yang ada di folder dengan situs kami. Tidak sulit, menggabungkan perintah yang berbeda, untuk berkeliaran di hard drive server web dan mencari apa yang buruk.
Lain kali kami akan menganalisis lebih banyak contoh, dan juga melihat bagaimana Anda dapat mengotomatisasi pekerjaan Anda.
Baca blog penulis di
tautan ini .