FlawOpen

flawopen.com/SQL Injection di JavaScript/TypeORM

Apakah TypeORM QueryBuilder aman dari SQL Injection?

Panduan referensi
Jawaban singkat

Parameter terikat seperti kolom bernama pada formulir: TypeORM mengirim nilainya secara terpisah sehingga tetap menjadi data, bukan instruksi SQL. QueryBuilder mengikat parameter bernama yang diberikan terpisah. Input yang diinterpolasi ke kondisi berubah menjadi teks SQL.

TIDAK AMAN — interpolasikan input ke SQL
userRepo.createQueryBuilder("u")
  .where(`u.id = ${userId}`)
  .getOne()
DIPERKUAT — ikat nilai secara terpisah
userRepo.createQueryBuilder("u")
  .where("u.id = :id", { id: userId })
  .getOne()

Ikat nilai; batasi struktur kueri

QueryBuilder.where() menerima kondisi dengan placeholder bernama seperti :id dan objek parameter terpisah. Gunakan nama berbeda untuk nilai berbeda; TypeORM memperingatkan bahwa nama yang dipakai ulang dapat menimpa nilai. Jangan interpolasikan input pengguna ke kondisi. Metode raw seperti dataSource.query() juga mendukung placeholder khusus driver dengan nilai terpisah. Parameter mengikat data, bukan nama tabel atau kolom, urutan, atau SQL bebas. Petakan struktur pilihan ke ekspresi tetap milik aplikasi.

Cara mengaudit konstruksi kueri TypeORM

rg -n '(\.where\(|\.query\(|\.sql)' --glob '*.ts' .

Pertanyaan umum

Apakah metode find Repository TypeORM selalu aman?

Opsi find biasa meneruskan nilai melalui konstruksi kueri TypeORM, tetapi tinjau operator khusus, ekspresi raw SQL, dan string yang dirakit aplikasi. Parameterisasi mencegah injeksi sintaks, tetapi tidak mengotorisasi akses record atau memvalidasi makna nilai.

Referensi

Lihat juga SQL Injection (CWE-89): cara kerja dan cara mencegahnya di setiap bahasa — flawopen.com Django ORM SQL Injection: pola aman Injeksi SQL Doctrine ORM: kueri aman EF Core FromSqlRaw: SQL berparameter yang aman Injeksi SQL FastAPI: Yang Dicegah dan Tidak Dicegah Pydantic GORM Raw SQL: Cegah Injeksi SQL di Go Apakah Escape Tanda Kutip Cukup untuk Mencegah SQL Injection?