Sebenarnya ada dua pertanyaan dalam satu. Dan pertanyaan dari judul tidak ada hubungannya dengan kekhawatiran yang diungkapkan oleh OP dalam komentar sesudahnya.
Meskipun saya menyadari bahwa untuk OP itu adalah kasus khusus mereka yang penting, bagi pembaca yang berasal dari Google, penting untuk menjawab pertanyaan yang lebih umum, yang dapat diutarakan sebagai "apakah penggabungan seaman pernyataan yang disiapkan jika saya memastikan bahwa setiap literal yang saya gabungkan aman? ". Jadi, saya ingin berkonsentrasi pada yang terakhir ini. Dan jawabannya adalah
Pasti TIDAK.
Penjelasannya tidak langsung seperti yang diinginkan kebanyakan pembaca, tetapi saya akan berusaha sebaik mungkin.
Saya telah merenungkan masalah ini untuk sementara waktu, menghasilkan artikel (meskipun berdasarkan lingkungan PHP) di mana saya mencoba merangkum semuanya. Terpikir oleh saya bahwa pertanyaan tentang perlindungan dari injeksi SQL sering kali luput dari beberapa topik terkait tetapi lebih sempit, seperti string escape, type casting, dan semacamnya. Meskipun beberapa tindakan dapat dianggap aman jika dilakukan sendiri, tidak ada sistem, atau aturan sederhana untuk diikuti. Yang membuatnya sangat licin, memberikan terlalu banyak perhatian dan pengalaman pengembang.
Pertanyaan tentang injeksi SQL tidak dapat disederhanakan menjadi masalah sintaks tertentu. Ini lebih luas dari yang biasa dipikirkan pengembang rata-rata. Ini juga pertanyaan metodologis . Ini tidak hanya "Pemformatan khusus mana yang harus kita terapkan", tetapi juga " Bagaimana hal itu harus dilakukan".
(Dari sudut pandang ini, sebuah artikel dari Jon Skeet yang dikutip dalam jawaban lain melakukan agak buruk daripada baik, karena lagi-lagi membahas beberapa kasus tepi, berkonsentrasi pada masalah sintaks tertentu dan gagal mengatasi masalah secara keseluruhan.)
Saat Anda mencoba menjawab pertanyaan tentang perlindungan tidak secara keseluruhan tetapi sebagai serangkaian masalah sintaksis yang berbeda, Anda menghadapi banyak masalah.
- daftar kemungkinan pilihan pemformatan sangat besar. Berarti seseorang dapat dengan mudah mengabaikan beberapa. Atau membingungkan mereka (dengan menggunakan string escaping untuk pengenal misalnya).
- Penggabungan berarti bahwa semua tindakan perlindungan harus dilakukan oleh programmer, bukan oleh program. Masalah ini sendiri menyebabkan beberapa konsekuensi:
- format seperti itu manual. Manual berarti sangat rawan kesalahan. Seseorang bisa saja lupa untuk melamar.
- Selain itu, ada godaan untuk memindahkan prosedur pemformatan ke beberapa fungsi terpusat, bahkan lebih mengacaukan, dan merusak data yang tidak masuk ke database.
- ketika lebih dari satu pengembang terlibat, masalah dikalikan dengan faktor sepuluh.
- ketika penggabungan digunakan, seseorang tidak dapat mengetahui kueri yang berpotensi berbahaya secara sekilas: semuanya berpotensi berbahaya!
Tidak seperti kekacauan itu, pernyataan yang disiapkan memang The Holy Grail:
- itu dapat diekspresikan dalam bentuk satu aturan sederhana yang mudah diikuti.
- itu pada dasarnya adalah ukuran yang tidak dapat dihapus, berarti pengembang tidak dapat mengganggu, dan, dengan sengaja atau tidak, merusak proses.
- proteksi dari injeksi sebenarnya hanya merupakan efek samping dari statement yang dibuat, yang tujuan sebenarnya adalah menghasilkan statement yang benar secara sintaksis. Dan pernyataan yang benar secara sintaksis adalah bukti injeksi 100%. Namun kami membutuhkan sintaks kami untuk benar meskipun ada kemungkinan injeksi.
- jika digunakan secara menyeluruh, ini melindungi aplikasi terlepas dari pengalaman pengembangnya. Katakanlah, ada yang namanya injeksi orde dua . Dan khayalan yang sangat kuat yang berbunyi "untuk melindungi, Luput dari Semua Masukan yang Disediakan Pengguna ". Dikombinasikan bersama, mereka mengarah pada injeksi, jika pengembang mengambil kebebasan untuk memutuskan, apa yang perlu dilindungi dan apa yang tidak.
(Berpikir lebih jauh, saya menemukan bahwa set placeholder saat ini tidak cukup untuk kebutuhan kehidupan nyata dan harus diperluas, baik untuk struktur data yang kompleks, seperti array, dan bahkan kata kunci atau pengenal SQL, yang terkadang harus ditambahkan ke kueri secara dinamis juga, tetapi pengembang dibiarkan tidak bersenjata untuk kasus seperti itu, dan dipaksa untuk kembali ke penggabungan string tetapi itu masalah pertanyaan lain).
Menariknya, kontroversi pertanyaan ini dipicu oleh sifat Stack Overflow yang sangat kontroversial. Ide situs adalah memanfaatkan pertanyaan tertentu dari pengguna yang bertanya secara langsung untuk mencapai tujuan memiliki database jawaban tujuan umum yang sesuai untuk pengguna yang datang dari penelusuran . Idenya adalah tidak buruk per se , tetapi gagal dalam situasi seperti ini: ketika pengguna mengajukan pertanyaan yang sangat sempit , terutama untuk mendapatkan sebuah argumen dalam sengketa dengan rekan (atau untuk memutuskan apakah itu layak untuk refactor kode). Sementara sebagian besar peserta berpengalaman mencoba menulis jawaban, ingatlah misinya dari Stack Overflow secara keseluruhan, membuat jawaban mereka bagus untuk pembaca sebanyak mungkin, bukan hanya OP.
