Pertimbangan Keamanan (Entity Framework)

  • Artikel

Topik ini menjelaskan pertimbangan keamanan yang khusus pada mengembangkan, menyebarkan, dan menjalankan aplikasi Entity Framework. Anda juga harus mengikuti rekomendasi untuk membuat aplikasi .NET Framework yang aman. Untuk informasi selengkapnya, lihat Ringkasan Keamanan.

Pertimbangan Keamanan Umum

Pertimbangan keamanan berikut ini berlaku untuk semua aplikasi yang menggunakan Kerangka Kerja Entitas.

Hanya gunakan penyedia sumber data tepercaya.

Untuk berkomunikasi dengan sumber data, penyedia harus melakukan hal berikut ini:

  • Menerima string koneksi dari Entity Framework.

  • Menerjemahkan pohon perintah ke bahasa kueri asli sumber data.

  • Merakit dan mengembalikan set hasil.

Selama operasi masuk, informasi yang didasarkan pada kata sandi pengguna diteruskan ke server melewati pustaka jaringan sumber data yang mendasarinya. Penyedia berbahaya bisa mencuri kredensial pengguna, menghasilkan kueri berbahaya, atau mengutak-atik hasil yang ditetapkan.

Enkripsi koneksi Anda untuk melindungi data sensitif.

Entity Framework tidak secara langsung menangani enkripsi data. Jika pengguna mengakses data dengan jaringan publik, aplikasi Anda harus membuat koneksi terenkripsi ke sumber data untuk meningkatkan keamanan. Untuk informasi selengkapnya, lihat dokumentasi terkait keamanan untuk sumber data Anda. Untuk sumber data SQL Server, baca Mengenkripsi Koneksi ke SQL Server.

Amankan string koneksi.

Melindungi akses ke sumber data Anda adalah salah satu tujuan terpenting ketika mengamankan aplikasi. Sebuah string koneksi menyajikan kerentanan potensial jika tidak diamankan atau jika tidak dibangun dengan benar. Saat Anda menyimpan informasi koneksi dalam teks biasa atau bertahan dalam memori, Anda terancam mengorbankan seluruh sistem Anda. Berikut ini adalah metode-metode yang disarankan untuk mengamankan string koneksi:

  • Gunakan Autentikasi Windows dengan menggunakan sumber data SQL Server.

    Ketika Anda menggunakan Autentikasi Windows untuk terhubung ke sumber data SQL Server, string koneksi tidak berisi informasi masuk dan kata sandi.

  • Enkripsi bagian file konfigurasi dengan konfigurasi yang dilindungi.

    ASP.NET menyediakan fitur yang disebut konfigurasi terlindung yang memungkinkan Anda mengenkripsi informasi sensitif dalam file konfigurasi. Meskipun utamanya dirancang untuk ASP.NET, Anda juga dapat menggunakan konfigurasi yang dilindungi untuk mengenkripsi bagian file konfigurasi dalam aplikasi Windows. Untuk deskripsi terperinci mengenai kemampuan konfigurasi baru yang dilindungi, lihat Mengenkripsi Informasi Konfigurasi Menggunakan Konfigurasi Terlindung.

  • Simpan string koneksi dalam file konfigurasi yang aman.

    Anda tidak boleh menyematkan string koneksi di dalam kode sumber Anda. Anda bisa menyimpan string koneksi dalam file konfigurasi, yang menghilangkan kebutuhan untuk menyematkannya dalam kode aplikasi Anda. Secara default, Wizard Model Data Entitas menyimpan string koneksi dalam file konfigurasi aplikasi. Anda harus mengamankan file ini guna mencegah akses yang tidak sah.

  • Gunakan pembangun string koneksi saat membuat koneksi secara dinamis.

    Jika Anda harus membuat string koneksi saat durasi, gunakan kelas EntityConnectionStringBuilder. Kelas pembuat string ini membantu mencegah serangan injeksi string koneksi dengan memvalidasi dan melarikan diri dari informasi input yang tidak valid. Untuk informasi selengkapnya, lihat Cara: Membangun String Koneksi EntityConnection. Gunakan juga kelas pembuat string yang sesuai untuk membangun string koneksi sumber data yang merupakan bagian dari string koneksi Entity Framework. Untuk informasi mengenai penyusun string koneksi untuk penyedia ADO.NET, lihat Penyusun String Koneksi.

Untuk informasi lebih lengkap, lihat Melindungi Informasi Koneksi.

Jangan mengekspos EntityConnection kepada pengguna yang tidak tepercaya.

Objek EntityConnection mengekspos string koneksi dari koneksi yang mendasarinya. Pengguna dengan akses ke objek EntityConnection juga dapat mengubah ConnectionState dari koneksi yang mendasarinya. Kelas EntityConnection ini tidak aman untuk utas.

Jangan melewati koneksi di luar konteks keamanan.

Setelah koneksi dibuat, Anda tidak boleh meneruskannya di luar konteks keamanan. Misalnya, satu utas dengan izin untuk membuka koneksi tidak boleh menyimpan koneksi pada lokasi global. Jika koneksi tersedia di lokasi global, maka utas berbahaya lainnya bisa menggunakan koneksi terbuka tanpa izin itu secara eksplisit diberikan kepadanya.

Ketahuilah bahwa informasi masuk dan kata sandi dapat terlihat di tempat pembuangan memori.

Ketika informasi sumber data masuk dan kata sandi disediakan di string koneksi, informasi ini disimpan dalam memori sampai pengumpulan sampah merebut kembali sumber daya. Hal ini membuat tidak mungkin untuk menentukan kapan string kata sandi tidak lagi terdapat dalam memori. Jika aplikasi crash, file cadangan memori dapat berisi informasi keamanan sensitif, dan pengguna yang menjalankan aplikasi dan pengguna mana pun dengan akses administratif ke komputer dapat melihat file cadangan memori. Gunakan Autentikasi Windows untuk koneksi ke Microsoft SQL Server.

Berikan pengguna hanya izin yang dibutuhkan di sumber data.

Administrator sumber data hanya bisa memberikan izin yang diperlukan kepada pengguna. Meskipun Entity SQL tidak mendukung pernyataan DML yang memodifikasi data, seperti INSERT, UPDATE, atau DELETE, pengguna masih bisa mengakses koneksi ke sumber data. Pengguna jahat bisa menggunakan koneksi ini untuk mengeksekusi pernyataan DML dalam bahasa asli sumber data.

Jalankan aplikasi dengan izin minimum.

Saat Anda mengizinkan aplikasi terkelola berjalan dengan izin kepercayaan penuh, .NET Framework tidak membatasi akses aplikasi ke komputer Anda. Ini dapat memungkinkan kerentanan keamanan dalam aplikasi Anda yang bisa membahayakan seluruh sistem. Untuk menggunakan keamanan akses kode dan mekanisme keamanan lainnya pada .NET Framework, Anda harus menjalankan aplikasi dengan menggunakan izin kepercayaan parsial dan dengan sekumpulan izin minimum yang diperlukan untuk memungkinkan aplikasi berfungsi. Izin akses kode berikut ini adalah izin minimum yang dibutuhkan aplikasi Entity Framework Anda:

Untuk informasi selengkapnya, baca Dasar-Dasar Keamanan Akses Kode.

Jangan memasang aplikasi yang tidak tepercaya.

Entity Framework tidak memberlakukan izin keamanan apa pun dan akan memanggil kode objek data yang disediakan pengguna dalam proses terlepas dari apakah itu tepercaya atau tidak. Pastikan bahwa autentikasi dan otorisasi klien dilakukan oleh penyimpanan data dan oleh aplikasi Anda.

Batasi akses ke seluruh file konfigurasi.

Administrator harus membatasi akses tulis ke seluruh file yang menentukan konfigurasi untuk aplikasi, termasuk untuk enterprisesec.config, security.config, machine.conf, dan file < konfigurasi aplikasi application>.exe.config.

Nama invarian penyedia dapat dimodifikasi di app.config. Aplikasi klien harus bertanggung jawab untuk mengakses penyedia yang mendasarinya dengan model pabrik penyedia standar dengan menggunakan nama yang kuat.

Batasi izin kepada file model dan pemetaan.

Administrator harus membatasi akses tulis ke model dan file pemetaan (.edmx, .csdl, .ssdl, dan .msl) khusus untuk pengguna yang memodifikasi model atau pemetaan. Entity Framework hanya memerlukan akses baca ke file-file ini pada waktu yang dijalankan. Administrator juga harus membatasi akses menuju lapisan objek dan file kode sumber tampilan yang telah dikompilasi sebelumnya yang dihasilkan oleh alat Model Data Entitas.

Pertimbangan Keamanan untuk Kueri

Pertimbangan keamanan berikut ini berlaku saat mengkueri model konseptual. Pertimbangan ini berlaku untuk kueri Entity SQL menggunakan EntityClient dan untuk mengajukan kueri menggunakan LINQ, Entity SQL, dan metode pembuat kueri.

Mencegah serangan injeksi SQL.

Aplikasi sering mengambil input eksternal (dari pengguna atau agen eksternal lainnya) serta melakukan tindakan berdasarkan input tersebut. Setiap input yang secara langsung atau tidak langsung berasal dari pengguna atau agen eksternal dapat memiliki konten yang menggunakan sintaks bahasa target untuk melakukan tindakan yang tidak sah. Saat bahasa target adalah Structured Query Language (SQL), seperti Transact-SQL, manipulasi ini dikenal sebagai serangan injeksi SQL. Pengguna jahat bisa menyuntikkan perintah langsung ke kueri dan menjatuhkan tabel database, menyebabkan penolakan layanan, atau mengubah sifat operasi yang dilakukan.

  • Serangan injeksi Entity SQL:

    SQL serangan injeksi dapat dilakukan di Entity SQL dengan menyediakan input berbahaya ke nilai yang digunakan pada predikat kueri dan dalam nama parameter. Untuk menghindari risiko injeksi SQL, Anda tidak diperbolehkan menggabungkan input pengguna dengan teks perintah Entity SQL.

    Kueri Entity SQL menerima parameter di mana pun literal diterima. Anda harus memakai kueri parameter alih-alih menyuntikkan literal dari agen eksternal langsung ke kueri. Anda juga harus mempertimbangkan untuk menggunakan metode penyusun kueri untuk membangun Entity SQL dengan aman.

  • Serangan injeksi LINQ ke Entitas:

    Meskipun komposisi kueri dimungkinkan dalam LINQ ke Entitas, hal itu dilakukan melalui API model objek. Tidak seperti kueri SQL Entitas, kueri LINQ ke Entitas tidak disusun menggunakan manipulasi string atau penggabungan, dan mereka tidak rentan terhadap serangan injeksi SQL tradisional.

Mencegah set hasil yang sangat besar.

Tataan hasil yang sangat besar bisa menyebabkan sistem klien dimatikan jika klien melakukan operasi yang mengonsumsi sumber daya sebanding dengan ukuran tataan hasil. Kumpulan hasil besar yang tidak terduga dapat terjadi pada kondisi berikut:

  • Pada kueri terhadap database besar yang tidak menyertakan kondisi filter yang sesuai.

  • Pada kueri yang membuat Cartesian bergabung di server.

  • Pada kueri Entity SQL berlapis.

Ketika menerima input pengguna, Anda harus memastikan bahwa input tidak dapat menyebabkan set hasil menjadi lebih besar dari apa yang dapat ditangani sistem. Anda juga bisa menggunakan metode Take di LINQ ke Entitas atau operator LIMIT di Entity SQL untuk membatasi ukuran kumpulan hasil.

Hindari Mengembalikan Hasil Yang Tidak Dapat Dikueri Saat Mengekspos Metode ke Penelepon yang Berpotensi Tidak Dipercaya.

Hindari mengembalikan jenis IQueryable<T> dari metode yang diekspos ke penelepon yang berpotensi tidak tepercaya karena alasan berikut:

  • Konsumen kueri yang mengekspos jenis IQueryable<T> bisa memanggil metode pada hasil yang mengekspos data aman atau meningkatkan ukuran kumpulan hasil. Sebagai contoh, perhatikan tanda tangan metode berikut ini:

    public IQueryable<Customer> GetCustomer(int customerId)

    Konsumen kueri ini dapat memanggil .Include("Orders") pada IQueryable<Customer> yang dikembalikan untuk mengambil data yang tidak ingin diekspos kueri. Ini dapat dihindari dengan mengubah jenis pengembalian metode ke IEnumerable<T> lalu memanggil metode (seperti .ToList()) yang mewujudkan hasilnya.

  • Karena kueri IQueryable<T> dijalankan saat hasil diulang, konsumen kueri yang mengekspos jenis IQueryable<T> bisa menangkap pengecualian yang dilemparkan. Pengecualian bisa berisi informasi yang tidak ditujukan untuk konsumen.

Pertimbangan Keamanan untuk Entitas

Pertimbangan keamanan berikut ini berlaku saat membuat dan bekerja dengan jenis entitas.

Jangan membagikan ObjectContext di seluruh domain aplikasi.

Berbagi ObjectContext dengan lebih dari satu domain aplikasi dapat mengekspos informasi dalam string koneksi. Sebagai gantinya, Anda harus mentransfer objek serial atau grafik objek ke domain aplikasi lain lalu melampirkan objek tersebut ke ObjectContext pada domain aplikasi tersebut. Untuk informasi selengkapnya, baca Membuat Serialisasi Objek.

Mencegah pelanggaran keamanan jenis.

Jika keamanan jenis dilanggar, Kerangka Kerja Entitas tidak dapat menjamin integritas data dalam objek. Pelanggaran keamanan jenis dapat terjadi jika Anda mengizinkan aplikasi yang tidak tepercaya berjalan dengan keamanan akses kode kepercayaan penuh.

Menangani pengecualian.

Metode akses dan properti ObjectContext dari dalam blok try-catch. Mengetahui pengecualian mencegah pengecualian yang tidak tertangani dari mengekspos entri dalam ObjectStateManager atau informasi model (seperti nama tabel) kepada pengguna aplikasi Anda.

Pertimbangan Keamanan untuk Aplikasi ASP.NET

Anda harus mempertimbangkan hal berikut ini ketika Anda bekerja dengan jalur dalam aplikasi ASP.NET.

Verifikasi apakah host Anda melakukan pemeriksaan jalur.

Saat string substitusi |DataDirectory| (diapit dalam simbol pipa) digunakan, ADO.NET memverifikasi bahwa jalur yang diselesaikan didukung. Contohnya, ".." tidak diizinkan di belakang DataDirectory. Pemeriksaan yang sama untuk menyelesaikan operator root aplikasi Web (~) dilakukan oleh proses hosting ASP.NET. IIS melakukan pemeriksaan ini; tetapi, host selain IIS mungkin tidak memverifikasi bahwa jalur yang diselesaikan didukung. Anda harus mengetahui perilaku host tempat Anda menerapkan aplikasi Entity Framework.

Jangan membuat asumsi mengenai nama jalur yang diselesaikan.

Meskipun nilai yang diselesaikan operator root (~) dan string substitusi DataDirectory harus tetap konstan selama runtime aplikasi, Entity Framework tidak membatasi host untuk memodifikasi nilai-nilai ini.

Verifikasi panjang jalur sebelum penyebaran.

Sebelum menyebarkan aplikasi Entity Framework, Anda harus memastikan bahwa nilai operator root (~) dan string substitusi DataDirectory tidak melebihi batas panjang jalur dalam sistem operasi. Penyedia data ADO.NET tidak memastikan bahwa panjang jalur berada dalam batas yang valid.

Pertimbangan Keamanan untuk Metadata ADO.NET

Pertimbangan keamanan berikut ini berlaku saat membuat dan bekerja dengan file model dan pemetaan.

Jangan mengekspos informasi sensitif dengan melalui pengelogan.

Komponen layanan metadata ADO.NET tidak mencatat informasi pribadi apa pun. Jika ada hasil yang tidak bisa dikembalikan karena pembatasan akses, sistem manajemen database dan sistem file harus mengembalikan hasil nol alih-alih menaikkan pengecualian yang dapat berisi informasi sensitif.

Jangan menerima objek MetadataWorkspace dari sumber yang tidak tepercaya.

Aplikasi tidak boleh menerima instans MetadataWorkspace kelas dari sumber yang tidak tepercaya. Sebagai gantinya, Anda harus secara eksplisit membangun dan mengisi ruang kerja dari sumber tersebut.

Lihat juga