Dapatkah saya melindungi dari injeksi SQL dengan mengosongkan kutip tunggal dan memasukkan masukan pengguna dengan tanda kutip tunggal?


142

Saya menyadari bahwa kueri SQL berparameter adalah cara optimal untuk membersihkan masukan pengguna saat membuat kueri yang berisi masukan pengguna, tetapi saya bertanya-tanya apa yang salah dengan mengambil masukan pengguna dan melepaskan tanda kutip tunggal dan mengelilingi seluruh string dengan tanda kutip tunggal. Berikut kodenya:

sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"

Kutipan tunggal apa pun yang dimasukkan pengguna diganti dengan tanda kutip tunggal ganda, yang menghilangkan kemampuan pengguna untuk mengakhiri string, jadi apa pun yang mereka ketik, seperti titik koma, tanda persen, dll., Semuanya akan menjadi bagian dari string dan tidak benar-benar dijalankan sebagai bagian dari perintah.

Kami menggunakan Microsoft SQL Server 2000, yang menurut saya kutipan tunggal adalah satu-satunya pemisah string dan satu-satunya cara untuk keluar dari pemisah string, jadi tidak ada cara untuk mengeksekusi apa pun yang diketik pengguna.

Saya tidak melihat cara untuk meluncurkan serangan injeksi SQL terhadap ini, tetapi saya menyadari bahwa jika ini antipeluru seperti yang terlihat bagi saya, orang lain akan memikirkannya dan itu akan menjadi praktik umum.

Ada apa dengan kode ini? Apakah ada cara untuk mendapatkan serangan injeksi SQL melewati teknik sanitasi ini? Contoh masukan pengguna yang memanfaatkan teknik ini akan sangat membantu.


MEMPERBARUI:

Saya masih tidak tahu cara apa pun untuk meluncurkan serangan injeksi SQL secara efektif terhadap kode ini. Beberapa orang menyarankan bahwa garis miring terbalik akan keluar dari satu kutipan tunggal dan membiarkan yang lain mengakhiri string sehingga sisa string akan dieksekusi sebagai bagian dari perintah SQL, dan saya menyadari bahwa metode ini akan berfungsi untuk menyuntikkan SQL ke dalam database MySQL, tetapi di SQL Server 2000 satu-satunya cara (yang dapat saya temukan) untuk keluar dari kutipan tunggal adalah dengan kutipan tunggal lainnya; garis miring terbalik tidak akan berhasil.

Dan kecuali jika ada cara untuk menghentikan pelolosan kutipan tunggal, tidak ada input pengguna lainnya yang akan dieksekusi karena semuanya akan diambil sebagai satu string yang berdekatan.

Saya memahami bahwa ada cara yang lebih baik untuk membersihkan masukan, tetapi saya benar-benar lebih tertarik untuk mempelajari mengapa metode yang saya berikan di atas tidak berfungsi. Jika ada yang tahu cara khusus untuk memasang serangan injeksi SQL terhadap metode sanitasi ini, saya akan senang melihatnya.


18
@BryanH Mengakui tidak memahami bagaimana kebijaksanaan yang diterima secara umum berlaku untuk kasus tertentu dan meminta contoh tentang kasus tertentu bukanlah keangkuhan, itu kerendahan hati. Menjadi kesal ketika seseorang menanyakan contoh mengapa kebijaksanaan yang diterima secara umum benar di sisi lain mungkin dianggap sombong. Penalaran dengan contoh spesifik sering kali merupakan cara yang bagus untuk menyelidiki dan belajar. Cara OP tentang keraguan ini sangat berguna untuk pemahaman saya tentang subjek, terutama ketika dia menjelaskan jawaban yang dia temukan.
SantiBailors

@patrik Baru saja menemukan ini saat saya mengerjakan bagian kode yang sama tetapi mencoba melepaskan string dan menyarangkan kueri. Apakah Anda pernah mengetahuinya?
3therk1ll

1
@ 3therk1ll sebaiknya jangan coba-coba, lebih baik Anda menggunakan SQL berparameter
Patrick

@Patrick, saya mendekatinya dari perspektif penyerang!
3therk1ll

Jawaban:


90

Pertama-tama, ini hanya praktik yang buruk. Validasi input selalu diperlukan, tetapi juga selalu rapuh.
Lebih buruk lagi, validasi daftar hitam selalu bermasalah, jauh lebih baik untuk secara eksplisit dan ketat menentukan nilai / format apa yang Anda terima. Memang, ini tidak selalu memungkinkan - tetapi sampai batas tertentu hal itu harus selalu dilakukan.
Beberapa makalah penelitian tentang subjek:

Intinya adalah, daftar hitam apa pun yang Anda lakukan (dan daftar putih yang terlalu permisif) dapat dilewati. Tautan terakhir ke makalah saya menunjukkan situasi di mana bahkan pelepasan kutipan dapat dilewati.

Meskipun situasi ini tidak berlaku untuk Anda, itu tetap merupakan ide yang buruk. Selain itu, kecuali aplikasi Anda kecil sekali, Anda harus berurusan dengan pemeliharaan, dan mungkin sejumlah tata kelola: bagaimana Anda memastikan bahwa aplikasi tersebut dilakukan dengan benar, di mana saja sepanjang waktu?

Cara yang tepat untuk melakukannya:

  • Validasi daftar putih: jenis, panjang, format, atau nilai yang diterima
  • Kalau mau blacklist, langsung saja. Meloloskan diri dari kutipan itu bagus, tetapi dalam konteks mitigasi lainnya.
  • Gunakan objek Command dan Parameter, untuk mempersiapkan dan memvalidasi
  • Panggil kueri berparameter saja.
  • Lebih baik lagi, gunakan Prosedur Tersimpan secara eksklusif.
  • Hindari menggunakan SQL dinamis, dan jangan gunakan penggabungan string untuk membuat kueri.
  • Jika menggunakan SP, Anda juga dapat membatasi izin dalam database untuk hanya menjalankan SP yang diperlukan, dan tidak mengakses tabel secara langsung.
  • Anda juga dapat dengan mudah memverifikasi bahwa seluruh basis kode hanya mengakses DB melalui SP ...

2
Ketika digunakan dengan benar, SQL dinamis dan penggabungan string dapat digunakan secara aman dengan kueri berparameter (yaitu dengan sp_executesqlalih - alih EXEC). Artinya, Anda dapat membuat pernyataan SQL secara dinamis selama tidak ada teks gabungan yang berasal dari pengguna. Ini juga memiliki manfaat kinerja; sp_executesqlmendukung caching.
Brian

2
@ Brian, baiklah :). Namun kenyataannya, seberapa sering Anda melihat programmer melakukan itu? Selain itu, skenario umum di mana SQL dinamis "diperlukan", memerlukan input pengguna sebagai bagian dari kueri (seharusnya). Jika Anda bisa melakukan sp_executesql, Anda (biasanya) tidak memerlukan sql dinamis di tempat pertama.
AviD

Saya akhirnya mengalami situasi yang membuat saya menyadari bahwa adalah mungkin untuk menggunakan unicode untuk menyelinap melewati penggantian string. Teks masukan diketik ke Word, yang mengubah apostrof dari versi lurus ke bawah menjadi apostrof "keriting" (yang lebih mirip koma), yang tidak terpengaruh oleh penggantian string tetapi diperlakukan sebagai pemisah string oleh SQL Server. Terima kasih atas jawabannya AviD (dan yang lainnya)!
Patrick

1
@ElRonnoco tentu, tapi saya tidak mengabaikannya , karena saya sudah melihatnya di alam liar lebih dari yang Anda kira ...
AviD

1
@AviD Saya memperbarui tautan ke PDF Penyelundupan SQL yang Anda tulis ke satu-satunya versi yang dapat saya temukan online ... beri tahu kami jika ada lokasi lain untuk makalah Anda.
Michael Fredrickson

41

Oke, tanggapan ini akan terkait dengan pembaruan pertanyaan:

"Jika ada yang tahu cara spesifik untuk melakukan serangan injeksi SQL terhadap metode sanitasi ini, saya akan senang melihatnya."

Sekarang, selain MySQL backslash escaping - dan dengan mempertimbangkan bahwa kita sebenarnya berbicara tentang MSSQL, sebenarnya ada 3 cara yang mungkin untuk tetap memasukkan SQL ke kode Anda.

sSanitizedInput = "'" & Ganti (sInput, "'", "''") & "'"

Perhatikan bahwa ini tidak semua valid setiap saat, dan sangat bergantung pada kode aktual Anda di sekitarnya:

  1. Injeksi SQL orde kedua - jika kueri SQL dibuat ulang berdasarkan data yang diambil dari database setelah lolos , data tersebut digabungkan tanpa lolos dan mungkin secara tidak langsung disuntikkan SQL. Lihat
  2. Pemotongan string - (sedikit lebih rumit) - Skenario Anda memiliki dua bidang, misalnya nama pengguna dan kata sandi, dan SQL menggabungkan keduanya. Dan kedua bidang (atau yang pertama) memiliki batas panjang yang ketat. Misalnya, nama pengguna dibatasi hingga 20 karakter. Katakanlah Anda memiliki kode ini:
username = left(Replace(sInput, "'", "''"), 20)

Maka yang Anda dapatkan - adalah nama pengguna, lolos, dan kemudian dipangkas menjadi 20 karakter. Masalahnya di sini - Saya akan menempelkan kutipan saya di karakter ke-20 (misalnya setelah 19 a), dan kutipan lolos Anda akan dipangkas (di karakter ke-21). Kemudian SQL

sSQL = "select * from USERS where username = '" + username + "'  and password = '" + password + "'"

dikombinasikan dengan nama pengguna yang salah format tersebut akan menghasilkan kata sandi yang sudah berada di luar tanda kutip, dan hanya akan berisi muatan secara langsung.
3. Penyelundupan Unicode - Dalam situasi tertentu, dimungkinkan untuk mengirimkan karakter unicode tingkat tinggi yang terlihat seperti kutipan, tetapi sebenarnya bukan - sampai ia masuk ke database, di mana tiba - tiba ia berada . Karena ini bukan kutipan saat Anda memvalidasinya, itu akan mudah ... Lihat tanggapan saya sebelumnya untuk lebih jelasnya, dan tautkan ke penelitian asli.


28

Singkatnya: Jangan pernah melakukan kueri yang keluar dari diri Anda sendiri. Anda pasti akan mendapatkan sesuatu yang salah. Sebagai gantinya, gunakan kueri berparameter, atau jika Anda tidak bisa melakukannya karena alasan tertentu, gunakan pustaka yang sudah ada yang melakukan ini untuk Anda. Tidak ada alasan untuk melakukannya sendiri.


2
Bagaimana jika Anda harus berurusan dengan sesuatu seperti "Tabel Google Fusion" di mana, afaik, tidak tersedia pustaka abstraksi yang mendukung dialeknya? Apa yang kamu sarankan?
systempuntoout

20

Saya menyadari ini sudah lama setelah pertanyaan diajukan, tapi ..

Salah satu cara untuk meluncurkan serangan pada prosedur 'kutipan argumen' adalah dengan pemotongan string. Menurut MSDN, di SQL Server 2000 SP4 (dan SQL Server 2005 SP1), string yang terlalu panjang akan dipotong secara diam-diam.

Saat Anda mengutip string, ukuran string bertambah. Setiap tanda kutip diulangi. Ini kemudian dapat digunakan untuk mendorong bagian-bagian SQL di luar buffer. Jadi Anda dapat secara efektif memangkas bagian klausa di mana.

Ini mungkin akan sangat berguna dalam skenario halaman 'admin pengguna' di mana Anda dapat menyalahgunakan pernyataan 'update' untuk tidak melakukan semua pemeriksaan yang seharusnya dilakukan.

Jadi jika Anda memutuskan untuk mengutip semua argumen, pastikan Anda tahu apa yang terjadi dengan ukuran string dan memastikan bahwa Anda tidak mengalami pemotongan.

Saya akan merekomendasikan menggunakan parameter. Selalu. Hanya berharap saya bisa menerapkannya di database. Dan sebagai efek sampingnya, Anda lebih cenderung mendapatkan klik cache yang lebih baik karena lebih banyak pernyataan yang terlihat sama. (Ini memang benar di Oracle 8)


1
Setelah memposting, saya memutuskan bahwa posting AviD mencakup ini, dan lebih detail. Semoga postingan saya masih bisa membantu seseorang.
Jørn Jen

10

Saya telah menggunakan teknik ini ketika berurusan dengan fungsionalitas 'pencarian lanjutan', di mana membuat kueri dari awal adalah satu-satunya jawaban yang layak. (Contoh: izinkan pengguna untuk mencari produk berdasarkan sekumpulan batasan tak terbatas pada atribut produk, menampilkan kolom dan nilai yang diizinkan sebagai kontrol GUI untuk mengurangi ambang pembelajaran bagi pengguna.)

Dengan sendirinya AFAIK aman. Seperti yang ditunjukkan oleh penjawab lain, Anda mungkin juga perlu berurusan dengan pelolosan backspace (meskipun tidak saat meneruskan kueri ke SQL Server menggunakan ADO atau ADO.NET, setidaknya - tidak dapat menjamin semua database atau teknologi).

Halangannya adalah Anda benar-benar harus memastikan string mana yang berisi input pengguna (selalu berpotensi berbahaya), dan string mana yang merupakan kueri SQL yang valid. Salah satu jebakannya adalah jika Anda menggunakan nilai dari database - apakah nilai tersebut awalnya disediakan oleh pengguna? Jika demikian, mereka juga harus melarikan diri. Jawaban saya adalah mencoba membersihkan selambat mungkin (tetapi tidak nanti!), Saat membuat kueri SQL.

Namun, dalam banyak kasus, pengikatan parameter adalah cara yang harus dilakukan - hanya saja lebih sederhana.


2
Anda masih dapat menggunakan substitusi parameter meskipun Anda membuat kueri Anda sendiri.
Nick Johnson

1
Anda harus membuat string pernyataan SQL dari awal, tetapi tetap menggunakan substitusi parameter.
JeeBee

Tidak, JANGAN PERNAH membangun pernyataan SQL Anda dari awal.
AviD

8

Sanitasi input bukanlah sesuatu yang ingin Anda setengah-setengah. Gunakan seluruh pantatmu. Gunakan ekspresi reguler pada bidang teks. TryCast numerik Anda ke jenis numerik yang tepat, dan laporkan kesalahan validasi jika tidak berhasil. Sangat mudah untuk mencari pola serangan di masukan Anda, seperti '-. Asumsikan semua masukan dari pengguna tidak bersahabat.


4
Dan bila Anda melewatkan SATU kasing pada SATU masukan, Anda pwnd.
BryanH

4
"Beberapa orang, ketika dihadapkan pada suatu masalah, berpikir" Saya tahu, saya akan menggunakan ekspresi reguler. "Sekarang mereka memiliki dua masalah."
MickeyfAgain_BeforeExitOfSO

1
@mickeyf Saya tahu ini adalah sentimen umum tetapi jujur ​​ekspresi reguler cukup mengagumkan setelah Anda memahami mereka.
tom.dietrich

@ tom.dietrich Itu selalu tergantung pada situasi kehidupan nyata. F.ex. sintaks regexpr tidak standar jadi secara umum saya akan menyarankan agar tidak menggunakan regexpr dalam konteks di mana sistem yang berbeda diintegrasikan untuk bekerja sama. Ini karena mesin regexpr yang berbeda mengevaluasi regexprs secara berbeda, dan yang lebih penting fakta sulit ini biasanya diremehkan atau diabaikan yang dapat menyebabkan pengembang tidak peduli dengan ketidakcocokan ini sampai mereka digigit. Ada banyak ketidakcocokan seperti itu; lihat f.ex. regular-expressions.info/shorthand.html (cari flavorsdi halaman itu).
SantiBailors

6

Bagaimanapun, itu ide yang buruk seperti yang Anda ketahui.

Bagaimana dengan sesuatu seperti keluar dari kutipan dalam string seperti ini: \ '

Penggantian Anda akan menghasilkan: \ ''

Jika garis miring terbalik keluar dari kutipan pertama, maka kutipan kedua telah mengakhiri string.


3
Terima kasih atas tanggapannya! Saya tahu bahwa serangan itu akan bekerja untuk database mySQL tetapi saya cukup yakin bahwa MS SQL Server tidak akan menerima garis miring terbalik sebagai karakter pelarian (saya mencobanya). Beberapa pencarian Google tidak mengungkapkan karakter pelarian lainnya, yang benar-benar membuat saya bertanya-tanya mengapa ini tidak berhasil.
Patrick

6

Jawaban sederhana: Ini kadang-kadang akan berhasil, tetapi tidak setiap saat. Anda ingin menggunakan validasi daftar putih pada semua yang Anda lakukan, tetapi saya menyadari itu tidak selalu memungkinkan, jadi Anda terpaksa menggunakan daftar hitam tebakan terbaik. Demikian juga, Anda ingin menggunakan procs tersimpan parametrized dalam segala hal , tetapi sekali lagi, itu tidak selalu memungkinkan, jadi Anda terpaksa menggunakan sp_execute dengan parameter.

Ada beberapa cara di sekitar daftar hitam yang dapat digunakan yang dapat Anda buat (dan beberapa daftar putih juga).

Tulisan yang layak ada di sini: http://www.owasp.org/index.php/Top_10_2007-A2

Jika Anda perlu melakukan ini sebagai perbaikan cepat untuk memberi Anda waktu untuk mendapatkan yang asli, lakukanlah. Tapi jangan berpikir Anda aman.


6

Ada dua cara untuk melakukannya, tanpa pengecualian, agar aman dari injeksi SQL; pernyataan yang disiapkan atau prosedur tersimpan prameterized.


4

Jika Anda memiliki kueri berparameter yang tersedia, Anda harus menggunakannya setiap saat. Yang diperlukan hanyalah satu kueri untuk lolos dari internet dan DB Anda berisiko.


4

Ya, itu akan berhasil sampai seseorang menjalankan SET QUOTED_IDENTIFIER OFF dan menggunakan tanda kutip ganda pada Anda.

Sunting: Ini tidak sesederhana tidak mengizinkan pengguna jahat untuk mematikan pengenal yang dikutip:

Pengandar SQL Server Native Client ODBC dan SQL Server Native Client OLE DB Provider untuk SQL Server secara otomatis menyetel QUOTED_IDENTIFIER ke ON saat menyambungkan. Ini bisa dikonfigurasi di sumber data ODBC, di atribut koneksi ODBC, atau properti koneksi OLE DB. Default untuk SET QUOTED_IDENTIFIER adalah OFF untuk koneksi dari aplikasi DB-Library.

Ketika prosedur tersimpan dibuat, pengaturan SET QUOTED_IDENTIFIER dan SET ANSI_NULLS diambil dan digunakan untuk pemanggilan berikutnya dari prosedur yang disimpan itu .

SET QUOTED_IDENTIFIER juga sesuai dengan pengaturan QUOTED_IDENTIFER dari ALTER DATABASE.

SET QUOTED_IDENTIFIER disetel pada waktu parse . Menyetel pada waktu parse berarti bahwa jika pernyataan SET ada dalam batch atau prosedur tersimpan, itu berlaku, terlepas dari apakah eksekusi kode benar-benar mencapai titik itu; dan pernyataan SET berlaku sebelum pernyataan apa pun dieksekusi.

Ada banyak cara QUOTED_IDENTIFIER bisa mati tanpa Anda sadari. Memang - ini bukan eksploitasi senjata api yang Anda cari, tetapi ini permukaan serangan yang cukup besar. Tentu saja, jika Anda juga lolos dari tanda kutip ganda - maka kita kembali ke awal. ;)


1
Itu bisa berhasil, tetapi sekali lagi, bagaimana mereka bisa membuat kode itu dieksekusi ketika semua input pengguna dikelilingi oleh tanda kutip tunggal? Baris kode tertentu yang dapat memasukkan SQL ke dalam kode di atas akan sangat membantu. Terima kasih!
Patrick

4

Pertahanan Anda akan gagal jika:

  • kueri mengharapkan angka, bukan string
  • ada cara lain untuk merepresentasikan tanda petik tunggal, termasuk:
    • urutan pelarian seperti \ 039
    • karakter unicode

(dalam kasus terakhir, itu harus menjadi sesuatu yang diperluas hanya setelah Anda selesai mengganti)


4

Patrick, apakah Anda menambahkan tanda kutip tunggal di sekitar SEMUA masukan, bahkan masukan numerik? Jika Anda memiliki input numerik, tetapi tidak menempatkan tanda kutip tunggal di sekitarnya, maka Anda memiliki eksposur.


1

Betapa jeleknya kode semua sanitasi input pengguna itu! Kemudian StringBuilder yang kikuk untuk pernyataan SQL. Metode pernyataan yang disiapkan menghasilkan kode yang jauh lebih bersih, dan manfaat SQL Injection adalah tambahan yang sangat bagus.

Juga mengapa menemukan kembali roda?


1

Daripada mengubah satu kutipan menjadi (seperti apa) dua kutipan tunggal, mengapa tidak mengubahnya menjadi apostrof, kutipan, atau menghapus seluruhnya?

Either way, itu sedikit kludge ... terutama ketika Anda secara sah memiliki hal-hal (seperti nama) yang mungkin menggunakan tanda kutip tunggal ...

CATATAN: Metode Anda juga mengasumsikan setiap orang yang mengerjakan aplikasi Anda selalu ingat untuk membersihkan input sebelum masuk ke database, yang mungkin tidak realistis hampir sepanjang waktu.


Tidak setuju karena jawaban tidak menjawab pertanyaan. Pertanyaannya adalah tentang keluarnya string dalam SQL. Ketika Anda keluar dari string arbitrer (seperti yang coba dilakukan penanya, untuk menangani data yang tidak dibersihkan), Anda tidak bisa begitu saja mengganti karakter bermasalah dengan karakter lain yang sewenang-wenang; yang merusak data. (Juga, satu kutipan ADALAH apostrof (setidaknya dalam ASCII).)
andrewf

-1

Meskipun Anda mungkin menemukan solusi yang berfungsi untuk string, untuk predikat numerik Anda juga perlu memastikan bahwa mereka hanya meneruskan angka (periksa sederhana apakah dapat diuraikan sebagai int / double / desimal?).

Ini banyak pekerjaan ekstra.


-2

Mungkin berhasil, tetapi bagi saya tampaknya sedikit tipu. Saya akan merekomendasikan untuk memverifikasi bahwa setiap string valid dengan mengujinya terhadap ekspresi reguler.


-3

Ya, Anda bisa, jika ...

Setelah mempelajari topik tersebut, menurut saya masukan yang disterilkan seperti yang Anda sarankan aman, tetapi hanya berdasarkan aturan berikut:

  1. Anda tidak pernah mengizinkan nilai string yang berasal dari pengguna menjadi apa pun selain literal string (yaitu, hindari memberikan opsi konfigurasi: "Masukkan nama / ekspresi kolom SQL tambahan di sini:"). Tipe nilai selain string (angka, tanggal, ...): konversikan ke tipe data aslinya dan sediakan rutin untuk literal SQL dari setiap tipe data.

    • Pernyataan SQL bermasalah untuk divalidasi
  2. Anda bisa menggunakan nvarchar/ ncharkolom (dan awalan string literal dengan N) ATAU membatasi nilai masuk ke varchar/ charkolom hanya untuk karakter ASCII (misalnya, membuang pengecualian saat membuat pernyataan SQL)

    • Dengan cara ini Anda akan menghindari konversi apostrof otomatis dari CHAR (700) ke CHAR (39) (dan mungkin peretasan Unicode serupa lainnya)
  3. Anda selalu memvalidasi panjang nilai agar sesuai dengan panjang kolom sebenarnya (buang pengecualian jika lebih panjang)

    • ada cacat yang diketahui di SQL Server yang memungkinkan untuk melewati kesalahan SQL yang terjadi saat pemotongan (menyebabkan pemotongan diam)
  4. Anda memastikan itu SET QUOTED_IDENTIFIERselaluON

    • berhati-hatilah, ini diterapkan dalam waktu parse, yaitu bahkan di bagian kode yang tidak dapat diakses

Mematuhi 4 poin ini, Anda harus aman. Jika Anda melanggar salah satunya, cara injeksi SQL terbuka.


1
Sepertinya Anda tidak membaca semua jawaban lain untuk pertanyaan berusia 8 tahun ini , karena sejumlah jawaban ini menunjukkan bahwa metodenya gagal menghentikan injeksi jika penyerang hanya menggunakan karakter unicode.
Hogan

@ Hogan - Ya, tapi saya pikir ada nilai ekstra dalam pertanyaan saya. Saya memiliki banyak pengalaman dan pengujian di balik apa yang saya tulis. Saya tahu menggunakan parameter kueri lebih baik, tetapi saya juga sepenuhnya memahami situasi ketika seseorang harus menghindarinya karena berbagai alasan (misalnya tuntutan majikan untuk tetap menggunakan cara lama). Dalam hal ini, menurut saya jawaban saya sangat komprehensif dan memiliki nilai lebih tinggi daripada jawaban yang mengatakan "jangan lakukan itu", karena ini menunjukkan jalan masuknya. Tunjukkan jawaban lain di sini yang menunjukkan cara yang sama dan saya akan mempertimbangkan untuk menghapus jawaban saya.
miroxlav

Oke, ketika (bukan jika) sistem Anda disusupi, harap kembali dan hapus jawaban ini .... atau Anda dapat menggunakan kueri parametrized.
Hogan

@ Hogan - Saya tidak punya masalah untuk melakukannya :) Tapi saat ini saya mengklaim tidak ada cara yang diketahui untuk menyiasatinya jika Anda menjaga 4 aturan yang saya posting. Jika Anda benar-benar berpikir ada jalan lain, tunjukkan saja di mana.
miroxlav

Nasihat buruk hombre. interpolasi apa pun bisa dikalahkan.
Shayne
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.