Temuduga Bahagian Belakang: Bagaimanakah Anda Mencegah Suntikan SQL?

Masalah dan Skop

Platform pesanan berbilang penyewa mendedahkan titik akhir carian dalaman. Penyewa pengguna yang disahkan boleh didapati daripada sesi pelayan. Permintaan tersebut mungkin mengandungi e-mel pelanggan, senarai status pesanan, medan pengisihan, arah pengisihan dan had keputusan. Satu semakan menemui kod berbentuk seperti ini:

const sql = `
  SELECT id, customer_email, status, total_cents, created_at
  FROM orders
  WHERE tenant_id = '${tenantId}'
    AND customer_email = '${input.email}'
    AND status IN (${input.statuses.join(",")})
  ORDER BY ${input.sort} ${input.direction}
  LIMIT ${input.limit}
`

Terangkan cara anda mereka bentuk semula sempadan pertanyaan ini supaya teks yang dikawal penyerang tidak dapat mengubah tatabahasa SQL. Rangkumi nilai, penapis pilihan, parameter senarai, pengecam seperti lajur pengisihan, prosedur tersimpan, jalan keluar pertanyaan mentah ORM, keistimewaan pangkalan data, pengelogan, ujian, dan data yang disimpan sebelum ini yang kemudiannya digunakan semula dalam SQL dinamik.

Peraturan utamanya ialah kod SQL mesti ditentukan oleh kod aplikasi yang dipercayai, manakala data luaran sampai ke pangkalan data melalui antara muka pengikatan parameter sebelah pelayan. Pengesahan input dan keistimewaan paling rendah menambah halangan yang berguna, tetapi kedua-duanya tidak mengubah penyambungan rentetan menjadi pertanyaan yang selamat.

Ini ialah soalan bahagian belakang kerana kemahiran yang menentukan ialah pembinaan pertanyaan, tingkah laku pemacu pangkalan data, kebenaran pada sempadan perkhidmatan, kebenaran pangkalan data dan pengesahan pengeluaran. Bahasa pelaksanaan adalah sampingan.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada calon mengenal pasti setiap sempadan tatabahasa dan bukannya sekadar berkata "gunakan pernyataan yang disediakan (prepared statement)." Nilai seperti ID penyewa, alamat e-mel, status dan had hendaklah diikat sebagai data. Nama jadual, nama lajur, kata kunci SQL dan arah pengisihan biasanya tidak boleh dibekalkan melalui pemegang tempat nilai biasa, jadi ia memerlukan reka bentuk semula pertanyaan atau senarai dibenarkan milik pelayan yang memetakan enum awam yang kecil kepada token SQL tetap.

Isyarat kedua ialah membezakan pencegahan suntikan daripada kebenaran. tenant_id berparameter masih tidak selamat untuk pengasingan penyewa jika ia datang daripada badan permintaan dan pemanggil boleh memilih penyewa lain. Perkhidmatan tersebut harus memperoleh penyewa daripada prinsipal yang disahkan dan memasukkannya ke dalam setiap pertanyaan yang berkaitan. Pemparameteran menghalang nilai daripada mengubah struktur pertanyaan; ia tidak membuktikan bahawa pemanggil dibenarkan mengakses nilai tersebut.

Isyarat ketiga ialah mengenali sempadan pelaksanaan yang tersembunyi. ORM adalah selamat hanya semasa kod menggunakan API berparameternya dengan betul. Pembantu pertanyaan mentah, penapis yang dibina dengan rentetan, alat migrasi, tugas pelaporan dan prosedur tersimpan yang melaksanakan SQL dinamik boleh mencipta semula kelemahan yang sama. Data yang disimpan dengan selamat hari ini juga boleh menjadi sumber suntikan peringkat kedua jika tugas lain kemudiannya menyambungkannya ke dalam SQL.

Isyarat terakhir ialah pengesahan berlapis. Jawapan yang kukuh menggabungkan semakan kod, pengikatan sebelah pelayan, pengecam dalam senarai dibenarkan, peranan pangkalan data dengan keistimewaan paling rendah, pengendalian ralat yang selamat, ujian penyepaduan dengan rentetan berniat jahat, penegasan pengasingan penyewa, dan pemantauan untuk ralat pangkalan data. Ia tidak membentangkan tembok api aplikasi web atau pelepasan manual sebagai pembaikan utama.

Soalan Penjelasan Sebelum Menjawab

• Pangkalan data dan pemacu manakah yang digunakan? Sintaks pemegang tempat, pengikatan tatasusunan, utiliti memetik pengecam, dan tingkah laku pernyataan yang disediakan adalah berbeza-beza. Prinsip reka bentuknya boleh alih, tetapi API yang tepat mesti sepadan dengan pemacu yang digunakan.
• Adakah permintaan membekalkan tenantId? Jika ya, abaikan medan tersebut untuk kebenaran dan peroleh penyewa daripada konteks pelayan yang disahkan. Akses rentas penyewa pentadbiran memerlukan laluan berasingan yang dibenarkan secara eksplisit.
• Penapis manakah yang merupakan pilihan? Predikat pilihan harus ditambah daripada serpihan SQL tetap sementara nilainya kekal sebagai parameter. API generik "tambah sebarang medan dan pengendali" meluaskan permukaan tatabahasa dengan ketara.
• Medan pengisihan manakah yang benar-benar diperlukan? Jika produk hanya memerlukan masa penciptaan dan jumlah keseluruhan, dedahkan dua kunci awam tersebut. Jangan terima ungkapan lajur sewenang-wenangnya, fungsi, pengumpulan (collations) atau klausa susunan yang dipisahkan koma.
• Bolehkah titik akhir mencari banyak status atau ID? Gunakan kemudahan tatasusunan pemacu pangkalan data, parameter tatasusunan ditaip, atau set pemegang tempat yang dijana. Jangan sekali-kali menggabungkan nilai mentah ke dalam teks SQL.
• Adakah sebarang API pertanyaan mentah ORM muncul dalam laluan tersebut? Periksa kedua-dua kaedah yang tidak selamat secara eksplisit dan pembantu templat yang "selamat" untuk mengesahkan sama ada nilai diikat oleh pemacu atau diinterpolasikan ke dalam rentetan terlebih dahulu.
• Adakah prosedur tersimpan membina SQL dinamik? Prosedur tidak selamat secara automatik. Parameternya mesti kekal sebagai data apabila prosedur memanggil SQL; laluan dinamik gaya EXEC memerlukan semakan yang sama.
• Apakah keistimewaan yang dimiliki oleh peranan aplikasi? Titik akhir baca biasanya tidak sepatutnya bersambung dengan pemilikan skema, DDL atau kebenaran jadual yang tidak berkaitan. Asingkan kelayakan operasi dan migrasi daripada kelayakan masa jalan.
• Apakah bukti yang diperlukan sebelum pelepasan? Tentukan korpus input berniat jahat, semakan pengasingan penyewa, inventori pertanyaan mentah, pengesahan peranan pangkalan data dan isyarat ralat pengeluaran sebelum menukar kod.

Rangka Kerja Jawapan 30 Saat

"Saya akan menjadikan konteks pelayan yang disahkan sebagai sumber tenantId, kemudian mengikat setiap nilai data melalui pemacu pangkalan data: penyewa, e-mel, tatasusunan status dan had. Lajur dan arah pengisihan adalah tatabahasa, jadi saya akan memetakan dua nilai enum awam kepada token SQL tetap milik pelayan dan menolak semua yang lain. Saya akan menginventori panggilan pertanyaan mentah ORM dan prosedur tersimpan kerana ia boleh memperkenalkan semula SQL yang dibina dengan rentetan, dan saya akan memparameterkan data tersimpan sekali lagi setiap kali ia mencapai sempadan pelaksanaan kemudian. Kemudian saya akan mengurangkan peranan pangkalan data masa jalan, mengembalikan ralat klien generik, memantau kegagalan dalaman terperinci, dan menjalankan ujian penyepaduan yang membuktikan rentetan berniat jahat kekal sebagai literal dan tidak boleh mengembalikan baris penyewa lain."

Huraian Mendalam Langkah demi Langkah

Langkah 1: Tandakan Sumber Kod, Data dan Kebenaran

Kelaskan setiap bahagian pertanyaan asal:

Contoh yang tidak selamat membolehkan rentetan yang diperoleh daripada permintaan mengambil bahagian dalam penghuraian. Tanda petik, ulasan, pengendali atau ungkapan tambahan boleh mengubah pernyataan sebelum pangkalan data mengetahui aksara yang sepatutnya menjadi data. Menyemak beberapa subrentetan yang mencurigakan tidak memulihkan sempadan kerana SQL mempunyai sintaks khusus dialek, pengekodan, ulasan, fungsi dan tingkah laku penghurai.

Mulakan daripada setiap tempat yang melaksanakan SQL, bukan sahaja titik akhir ini. Cari API pertanyaan mentah, rentetan templat, penyambungan rentetan di sekitar kaedah pertanyaan, pelaksanaan prosedur dinamik, penapis pelaporan dan pembina pertanyaan yang menerima nama medan atau pengendali. Jejaki pembalut (wrappers) sehingga anda boleh menunjukkan perkara yang sampai ke pemacu sebagai teks SQL dan perkara yang sampai sebagai koleksi parameter.

Langkah 2: Ikat Setiap Nilai pada Pelayan

Pelaksanaan TypeScript gaya PostgreSQL boleh memastikan nilai kekal berasingan:

const SORT_COLUMNS = {
  createdAt: "o.created_at",
  total: "o.total_cents",
} as const

const SORT_DIRECTIONS = {
  asc: "ASC",
  desc: "DESC",
} as const

interface OrderSearchInput {
  email: string | null
  statuses: string[] | null
  sort: string
  direction: string
  limit: number
}

async function findOrders(authenticatedTenantId: string, input: OrderSearchInput) {
  if (
    !Object.hasOwn(SORT_COLUMNS, input.sort) ||
    !Object.hasOwn(SORT_DIRECTIONS, input.direction)
  ) {
    throw new Error("Unsupported sort option")
  }

  const sortColumn =
    SORT_COLUMNS[input.sort as keyof typeof SORT_COLUMNS]
  const sortDirection =
    SORT_DIRECTIONS[input.direction as keyof typeof SORT_DIRECTIONS]

  const sql = `
    SELECT o.id, o.customer_email, o.status, o.total_cents, o.created_at
    FROM orders AS o
    WHERE o.tenant_id = $1
      AND ($2::text IS NULL OR o.customer_email = $2)
      AND ($3::text[] IS NULL OR o.status = ANY($3))
    ORDER BY ${sortColumn} ${sortDirection}
    LIMIT $4
  `

  return db.query(sql, [
    authenticatedTenantId,
    input.email,
    input.statuses,
    input.limit,
  ])
}

Interpolasi yang tinggal hanya menggunakan nilai yang dipilih daripada pemetaan pemalar selepas semakan keahlian masa jalan. Tiada rentetan permintaan menjadi pengecam atau kata kunci. Penyewa, e-mel, tatasusunan status dan had kekal dalam koleksi parameter pemacu.

Sahkan limit sebagai integer dalam julat yang dibenarkan oleh produk sebelum pelaksanaan. Ini melindungi penggunaan sumber dan semantik API. Ia masih diikat sebagai parameter kerana pengesahan perniagaan dan pengasingan kod/data mempunyai tujuan yang berbeza.

Bagi pangkalan data tanpa parameter tatasusunan yang mudah, jana pemegang tempat daripada panjang tatasusunan dan ikat setiap elemen:

status IN ($3, $4, $5)
values = [tenantId, email, status1, status2, status3]

Teks pemegang tempat boleh dijana oleh kod yang dipercayai; nilai status tidak boleh digabungkan ke dalam teks SQL. Tentukan tingkah laku tatasusunan kosong secara eksplisit. Ia mungkin bermaksud "tiada penapis status" atau "padankan tiada apa-apa," dan pilihan tersebut tidak seharusnya berubah secara tidak sengaja mengikut tingkah laku pembina pertanyaan.

Langkah 3: Pastikan Tatabahasa Dinamik Kecil dan Milik Pelayan

Pemegang tempat biasa mewakili nilai, bukan pengecam atau kata kunci sewenang-wenangnya. Menyampaikan "created_at" sebagai $1 biasanya mengisih mengikut literal rentetan dan bukannya memilih lajur, dan mengendalikan pengecam yang tidak dipercayai dengan API nilai tidak menyelesaikan keperluan produk.

Dedahkan perbendaharaan kata awam yang kecil dan petakannya kepada token dalaman tetap:

createdAt -> o.created_at
total     -> o.total_cents
asc       -> ASC
desc      -> DESC

Tolak kunci yang tidak diketahui. Jangan teruskan pengecam yang dipetik, fungsi SQL, laluan JSON, pengumpulan, klausa susunan nol, atau ungkapan daripada permintaan. Jika keperluan produk kemudiannya menambah pengisihan terkira, laksanakan ungkapan tersebut dalam kod pelayan dan petakan satu kunci awam baharu kepadanya.

Pembantu pemetik pengecam boleh menjadi sesuai apabila kod pentadbiran yang dipercayai benar-benar memerlukan pengecam dinamik, tetapi memetik input pengguna sewenang-wenangnya sering kali mengekalkan keupayaan yang lebih luas daripada yang sepatutnya dimiliki oleh titik akhir. Bagi API biasa, pemetaan yang sempit adalah lebih mudah untuk disemak dan diuji.

Langkah 4: Kekalkan Pengasingan Penyewa Secara Bebas

Peroleh authenticatedTenantId daripada sesi, token atau identiti perkhidmatan yang disahkan. Jangan percaya nilai penyewa pendua dalam badan JSON, rentetan pertanyaan atau keadaan pelayar. Setiap bacaan dan penulisan yang menyentuh baris milik penyewa harus menyertakan skop yang dibenarkan atau menggunakan abstraksi repositori yang memerlukannya.

Matriks ujian mesti menyertakan ID pesanan, e-mel atau status sah milik penyewa lain. Pertanyaan tersebut sepatutnya tidak mengembalikan baris sedemikian walaupun semua nilai SQL tidak berbahaya secara sintaksis. Ini menangkap kegagalan kebenaran yang tidak dapat dikesan oleh ujian suntikan sahaja.

Keselamatan peringkat baris pangkalan data boleh menambah sempadan lain apabila ia dikonfigurasikan di sekitar identiti sesi yang boleh dipercayai dan diuji melalui penyatuan sambungan. Ia tidak memaafkan kebenaran perkhidmatan yang hilang, pengendalian pembolehubah sesi yang tidak selamat atau penyambungan SQL. Anggap ia sebagai lapisan penguatkuasaan tambahan dengan konfigurasi dan ujiannya sendiri.

Langkah 5: Audit ORM, Prosedur Tersimpan dan Laluan Peringkat Kedua

API penapis biasa ORM lazimnya mengikat nilai, tetapi kaedah pelaksanaan mentah mungkin menawarkan kedua-dua bentuk berparameter yang selamat dan bentuk rentetan yang tidak selamat secara eksplisit. Semak kaedah yang tepat, versi rangka kerja dan laluan pemacu. Nama kaedah seperti queryRaw bukanlah bukti yang mencukupi dengan sendirinya; buktikan sama ada SQL akhir dan nilai dihantar secara berasingan.

Prosedur tersimpan adalah selamat hanya apabila inputnya kekal sebagai parameter. Prosedur yang menyambungkan parameter ke dalam SQL dinamik dan melaksanakannya telah memindahkan sempadan terdedah ke dalam pangkalan data. Cari badan prosedur untuk pelaksanaan dinamik dan semak keistimewaan yang diberikan kepada peranan aplikasi.

Suntikan peringkat kedua berlaku apabila teks berniat jahat disimpan sebagai data biasa dan kemudiannya digunakan semula sebagai tatabahasa SQL. Contohnya, proses import mungkin memasukkan nama laporan dengan selamat, manakala tugas laporan setiap malam kemudiannya menyambungkan nama tersebut ke dalam pertanyaan. Penulisan pertama boleh diparameterkan dan masih menyebabkan pelaksanaan kemudian terdedah. Gunakan pemparameteran atau pemetaan tetap pada setiap sempadan pelaksanaan, tidak kira sama ada nilai itu datang terus daripada permintaan, perkhidmatan lain, fail atau baris pangkalan data yang sedia ada.

Langkah 6: Tambah Pertahanan Secara Mendalam Tanpa Menyembunyikan Kecacatan

Gunakan peranan pangkalan data masa jalan dengan hanya jadual dan operasi yang diperlukan. Perkhidmatan carian baca sahaja tidak sepatutnya memiliki skema atau mempunyai kebenaran untuk menggugurkan jadual, mencipta sambungan atau mengemas kini data yang tidak berkaitan. Migrasi dan pentadbiran harus menggunakan kelayakan yang berasingan. Keistimewaan paling rendah mengehadkan kerosakan jika suntikan atau kompromi aplikasi lain terlepas; ia tidak menjadikan pertanyaan yang tidak selamat boleh diterima.

Pengesahan input harus menguatkuasakan jenis perniagaan, panjang, keahlian enum dan julat. Ia boleh menolak permintaan cacat bentuk lebih awal dan mengurangkan penyalahgunaan. Ia kekal sebagai perkara sekunder kerana nilai yang lulus pengesahan masih boleh berbahaya dalam konteks SQL yang salah, dan medan bentuk bebas seperti nama secara sah mengandungi tanda baca.

Pelepasan manual adalah khusus untuk pangkalan data dan rapuh. Jangan cipta pembantu escapeSql umum dan sambungkan outputnya. Jika laluan legasi tidak boleh diganti dengan serta-merta, asingkannya, gunakan kemudahan terdokumen vendor pangkalan data, hadkan keistimewaan, tambah ujian dan jejak penyingkirannya. Tembok api aplikasi web mungkin menyediakan pengesanan sementara atau penampalan maya semasa insiden, tetapi ia tidak dapat membuktikan bahawa setiap laluan pelaksanaan pangkalan data adalah selamat.

Kembalikan kegagalan generik kepada klien dan log peristiwa dalaman berstruktur dengan laluan, operasi, penggunaan dan kelas ralat pangkalan data. Jangan gema teks SQL, surihan tindanan, butiran sambungan atau nilai parameter sensitif kepada pemanggil. Elakkan mencatat rahsia atau data peribadi penuh sambil mengekalkan pengecam yang mencukupi untuk disiasat.

Langkah 7: Sahkan Pembaikan pada Sempadan Pertanyaan

Bina ujian penyepaduan terhadap pemacu sebenar dan dialek pangkalan data. Sertakan rentetan yang mengandungi petikan, penanda ulasan, koma bertitik, Unicode, aksara kad bebas dan teks yang menyerupai SQL. Penegasannya bukan sekadar "permintaan itu tidak ranap." Nilai mesti dianggap secara literal, bentuk pertanyaan mesti kekal tetap, dan titik akhir mesti mengembalikan baris yang dibenarkan sahaja.

Rangkumi sekurang-kurangnya:

1. Teks e-mel dengan tanda petik atau aksara seperti ulasan kekal sebagai perbandingan literal.
2. Setiap kunci pengisihan yang dibenarkan menghasilkan klausa ORDER BY tetap yang dijangkakan.
3. Kunci pengisihan yang tidak diketahui, arah, status dan had di luar julat ditolak sebelum membuat pertanyaan.
4. Tatasusunan kosong, satu elemen dan banyak elemen mempunyai tingkah laku yang ditentukan dan menggunakan nilai terikat.
5. Pemanggil tidak boleh mendapatkan semula baris penyewa lain dengan menukar sebarang medan permintaan.
6. Laluan pertanyaan mentah ORM dan prosedur tersimpan menerima korpus berniat jahat yang sama.
7. Rentetan tersimpan yang kemudiannya digunakan oleh tugas pelaporan atau penyelenggaraan kekal sebagai data pada sempadan pelaksanaan kedua.
8. Peranan pangkalan data masa jalan tidak boleh melakukan perubahan skema atau mengakses jadual yang tidak berkaitan.

Analisis statik dan semakan kod boleh menghalang laluan interpolasi mentah baharu. Konfigurasikan peraturan atau pusat pemeriksaan semakan untuk kaedah pertanyaan mentah yang tidak selamat dan pembinaan rentetan bersebelahan SQL, tetapi kekalkan ujian penyepaduan kerana pembalut, kod yang dijana, prosedur dan tingkah laku pemacu mungkin tidak dapat dilihat melalui carian teks mudah.

Langkah 8: Lepaskan, Perhatikan dan Balas

Lancarkan dengan pemantauan kadar ralat pangkalan data, kependaman titik akhir, kiraan input yang ditolak dan bentuk pertanyaan. Peningkatan mendadak dalam ralat sintaks, kegagalan kebenaran atau kunci pengisihan yang ditolak boleh mendedahkan klien yang terlepas pandang atau penyiasatan aktif. Jangan log muatan berniat jahat penuh semata-mata untuk mengiranya.

Jika suntikan sebenar disyaki, lumpuhkan atau sempitkan titik akhir yang terdedah, simpan bukti audit penggunaan dan pangkalan data yang berkaitan, putar kelayakan pangkalan data yang terdedah, dan tentukan perkara yang boleh dibaca atau diubah oleh peranan masa jalan. Semak log pangkalan data dan rekod perniagaan untuk akses tanpa kebenaran, baiki setiap laluan pelaksanaan yang setara, dan tambah kelas yang ditemui ke dalam korpus regresi sebelum memulihkan akses normal.

Penyelesaian bermaksud laluan tatabahasa yang tidak selamat telah tiada, kebenaran penyewa kekal dikuatkuasakan, peranan masa jalan dihadkan, semua pelaksana pertanyaan telah diinventori, dan ujian membuktikan bahawa input berniat jahat kekal sebagai data merentasi kedua-dua pelaksanaan serta-merta dan kemudian.

Contoh Jawapan Berkualiti Tinggi

"Mula-mula saya akan menginventori setiap laluan pelaksanaan SQL yang digunakan oleh titik akhir, termasuk kaedah mentah ORM dan prosedur tersimpan. Pertanyaan asal mencampurkan lima kebimbangan yang berbeza. Penyewa, e-mel, nilai status dan had ialah data; lajur dan arah pengisihan ialah tatabahasa SQL; dan skop penyewa juga merupakan keputusan kebenaran.

Saya akan memperoleh penyewa daripada konteks pelayan yang disahkan dan mengikatnya melalui pemacu dengan e-mel, tatasusunan status ditaip dan had integer terikat. Saya hanya akan mendedahkan createdAt dan total sebagai kunci pengisihan serta asc dan desc sebagai arah, kemudian memetakkannya kepada token SQL malar selepas semakan keahlian masa jalan. Nilai yang tidak diketahui akan ditolak. Jika pemacu tidak mempunyai pengikatan tatasusunan, saya hanya akan menjana senarai pemegang tempat dan mengikat setiap elemen secara berasingan.

Saya akan mengesahkan API pertanyaan mentah tepat ORM dan bukannya menganggap semua panggilan ORM adalah selamat. Saya juga akan memeriksa prosedur tersimpan untuk pelaksanaan dinamik. Nilai yang disimpan sebelum ini kekal tidak dipercayai apabila laporan atau tugas kelompok kemudiannya membina SQL, jadi ia mesti diparameterkan sekali lagi pada sempadan pelaksanaan tersebut.

Untuk pertahanan secara mendalam, perkhidmatan carian akan menggunakan peranan pangkalan data yang hanya boleh membaca lajur atau pandangan yang diperlukan dan tidak boleh mengubah skema. Pengesahan perniagaan akan menguatkuasakan enum, panjang dan had yang dibenarkan, manakala pemparameteran kekal sebagai pertahanan suntikan. Respons klien adalah generik; log dalaman akan merakam operasi dan kelas ralat tanpa teks SQL atau parameter sensitif.

Akhir sekali, saya akan menjalankan ujian penyepaduan menggunakan pemacu sebenar. Tanda petik, ulasan, teks yang kelihatan seperti SQL, Unicode dan elemen tatasusunan mesti kekal sebagai nilai literal. Ujian akan merangkumi setiap pilihan pengisihan yang dibenarkan dan ditolak, senarai kosong dan besar, laluan ORM dan prosedur, penggunaan semula data tersimpan, dan pengecam rentas penyewa. Pembetulan selesai hanya apabila struktur pertanyaan kekal tetap dan tiada permintaan boleh mengembalikan baris penyewa lain."

Kesilapan Biasa

• Memparameterkan e-mel sahaja → penyewa, elemen senarai, had atau penapis lain masih boleh mengubah SQL → ikat setiap nilai dan inventori keseluruhan laluan pelaksanaan.
• Mengikat nama lajur yang diminta sebagai nilai biasa → pemegang tempat nilai tidak mewakili pengecam → petakan enum awam yang kecil kepada token SQL tetap milik pelayan.
• Memetik sebarang pengecam yang diminta → titik akhir masih memberikan pemanggil kawalan ke atas permukaan tatabahasa yang luas → dedahkan hanya kunci pengisihan yang diperlukan produk dan tolak yang lain.
• Menggabungkan senarai status yang disahkan ke dalam IN (...) → pengesahan boleh tersasar dan setiap elemen memasuki semula teks SQL → gunakan parameter tatasusunan ditaip atau jana pemegang tempat dan ikat setiap elemen.
• Mengambil tenantId daripada permintaan kerana ia diparameterkan → pengasingan kod/data tidak membenarkan penyewa yang dipilih → peroleh skop penyewa daripada konteks pelayan yang disahkan.
• Menganggap ORM menghalang semua suntikan → kaedah mentah atau tidak selamat boleh memintas pengikatan biasa → sahkan API yang tepat dan panggilan pemacu akhir.
• Memindahkan pembinaan rentetan ke dalam prosedur tersimpan → SQL dinamik di dalam prosedur kekal boleh disuntik → pastikan input prosedur diparameterkan melalui pelaksanaan akhir.
• Membersihkan hanya pada penulisan asal → teks berniat jahat yang disimpan kemudiannya boleh menjadi tatabahasa SQL dalam tugas laporan → lindungi setiap sempadan pelaksanaan daripada suntikan peringkat kedua.
• Melepaskan tanda petik dengan pembantu tersuai → perbezaan dialek, pengekodan dan konteks menjadikan pelepasan manual rapuh → gunakan antara muka pengikatan parameter sebelah pelayan pemacu.
• Memberikan keistimewaan pemilik aplikasi kerana pertanyaan telah dibetulkan → kecacatan lain atau kebocoran kelayakan mempunyai radius letupan yang tidak perlu → gunakan peranan masa jalan dengan keistimewaan paling rendah dan kelayakan migrasi berasingan.
• Mengembalikan ralat pangkalan data dan SQL untuk penyahpepijatan → pemanggil mempelajari butiran skema dan pertanyaan, manakala log mungkin mendedahkan data peribadi → kembalikan ralat generik dan rekod bukti dalaman yang berstruktur dan disunting.
• Menguji satu muatan terkenal dan berhenti → kebenaran, tatasusunan, prosedur tersimpan, laluan mentah alternatif dan pelaksanaan peringkat kedua kekal tidak diuji → sahkan bentuk pertanyaan dan keputusan penyewa merentasi pelbagai korpus.

Soalan Susulan

Soalan Susulan 1: Bolehkah Pernyataan yang Disediakan Melindungi Nama Jadual atau Lajur Dinamik?

Parameter ikatan biasa mewakili nilai. Ia secara amnya tidak menggantikan nama jadual, nama lajur, pengendali atau kata kunci SQL. Reka bentuk semula API supaya pemanggil memilih daripada enum kecil, kemudian petakan setiap kunci yang dibenarkan kepada serpihan SQL tetap milik aplikasi. Jika perkakasan pentadbiran yang dipercayai benar-benar memerlukan pengecam dinamik, gunakan kemudahan pengecam vendor pangkalan data dan sempadan kebenaran yang lebih sempit; jangan dedahkan keupayaan tersebut melalui titik akhir carian biasa yang menghadap pengguna.

Soalan Susulan 2: Adakah ORM Cukup untuk Mencegah Suntikan SQL?

Hanya jika API yang dipilih mengekalkan pengikatan parameter melalui panggilan pemacu akhir. Kaedah kesaksamaan dan penapis biasa selalunya melakukannya. Kaedah rentetan mentah, varian tidak selamat, nama medan dinamik, pengendali tersuai dan sambungan mungkin tidak. Semak versi rangka kerja yang digunakan, periksa SQL dan nilai yang dijana dalam persekitaran ujian yang selamat, dan jalankan ujian penyepaduan input berniat jahat. ORM mengurangkan peluang untuk melakukan kesilapan; ia tidak menghapuskan keperluan untuk memahami jalan keluarnya.

Soalan Susulan 3: Apakah Itu Suntikan SQL Peringkat Kedua?

Nilai yang dikawal penyerang disimpan terlebih dahulu sebagai data tanpa mengubah pernyataan asal. Proses kemudian membaca nilai tersebut dan menyambungkannya ke dalam SQL dinamik, di mana ia mengubah tatabahasa pernyataan baharu. Pembaikan adalah wajar pada sempadan pelaksanaan kemudian: ikat nilai yang disimpan sebagai data, atau petakannya kepada token tetap jika ia sepatutnya memilih tatabahasa. Layan baris pangkalan data, fail, barisan gilir dan perkhidmatan dalaman sebagai sumber yang tidak dipercayai apabila ia mempengaruhi SQL yang boleh dilaksanakan.

Soalan Susulan 4: Patutkah Aplikasi Menolak Setiap Tanda Petik, Koma Bertitik atau Kata Kunci SQL?

Tidak. Nama, teks carian dan data sah lain mungkin mengandungi tanda baca atau perkataan yang menyerupai SQL. Pengesahan perniagaan harus menguatkuasakan jenis domain sebenar, panjang, format, enum dan julat. Pemparameteran membekalkan sifat keselamatan dengan menjadikan nilai lengkap sebagai data literal. Senarai tolak adalah tidak lengkap dan juga boleh memecahkan input yang sah.

Soalan Susulan 5: Bagaimanakah Anda Mengendalikan Senarai IN Dinamik yang Besar?

Gunakan tatasusunan ditaip pangkalan data atau parameter bernilai jadual apabila tersedia, atau jana satu pemegang tempat bagi setiap elemen dan ikat setiap nilai. Tentukan saiz senarai maksimum untuk kawalan sumber. Senarai yang sangat besar mungkin mewajarkan jadual sementara, mekanisme muatan pukal atau API yang berbeza, tetapi nilai yang dimasukkan masih menggunakan data protokol terikat atau pukal dan bukannya penyambungan rentetan SQL.

Soalan Susulan 6: Apakah yang Akan Anda Lakukan Semasa Insiden Suntikan Pengeluaran yang Disahkan?

Hadkan laluan yang terdedah, simpan bukti audit penggunaan, pangkalan data dan aplikasi, serta putar kelayakan yang mungkin telah terdedah. Gunakan kebenaran peranan masa jalan untuk membatasi penyiasatan, semak bacaan dan penulisan tanpa kebenaran, serta baiki semua pembina pertanyaan dan prosedur yang setara. Tambah laluan yang diperhatikan pada ujian regresi, kurangkan keistimewaan jika boleh, dan pulihkan trafik hanya selepas pertanyaan yang dibetulkan dan sempadan penyewa disahkan.