SQL Enjeksiyonu Nedir ve C#'de Nasıl Önlenir?

Demo uygulaması ve neden önemlidir

Tim, yerel bir InjectableDB'ye (People ve Secrets tabloları) bağlı küçük bir WPF demo uygulamasıyla başlar. Uygulamanın web formu benzeri arama kutusu, kullanıcıdan bir girdi (soyadı) alır ve kimlik numarası, isim ve soyadı döndüren bir SQL sorgusu oluşturur. "Çalışıyor" — Corey yazın ve Tim Corey alın — ama Tim, ana noktayı vurgular: "Sadece bir uygulama çalışıyor diye güvenli olduğu anlamına gelmez." Çalışan bir web uygulaması hala kullanıcı tarafından sağlanan girdi SQL ifadelerine dizge bağlama veya dinamik SQL yoluyla doğrudan eklendiğinde SQL enjeksiyonu açıkları içerebilir.

Güvenli olmayan kod — string birleştirme ve dinamik SQL

Tim, birçok geliştiricinin kullandığı tehlikeli deseni tam olarak gösteriyor:

var sql = $"SELECT * FROM People WHERE LastName = '{searchText}'";
var results = connection.Query<Person>(sql);

var sql = $"SELECT * FROM People WHERE LastName = '{searchText}'";
var results = connection.Query<Person>(sql);

Bu orijinal sorgu, bir SQL ifadesi oluşturmak için string birleştirme kullanır. Tim uyarıyor: kullanıcı girdilerini doğrudan SQL sorgularına enjekte eden bir kod görürseniz, durun — bu bir SQL enjeksiyon güvenliğidir. Saldırganlar, SQL komutlarınızın yapısını değiştiren veya hatta ek zararlı SQL ifadeleri çalıştıran kötücül girdiler oluşturabilir.

Bir saldırgan bunu nasıl istismar eder — UNION ve DROP

SQL enjeksiyon saldırısının nasıl çalıştığını göstermek için Tim, SQL Server'da sorguları yeniden üretir ve ardından karakterlerin sonunu gizlemek için UNION ALL ve SQL yorumları (--) kullanarak enjeksiyonlar hazırlar. Örnek kötü amaçlı yükler Tim'in gösterdiği:

Diğer tabloları okumak için birleştirme tabanlı SQL enjeksiyonu:

UNION ALL SELECT ID, KullanıcıAdı AS FirstName, Şifre AS LastName FROM Secrets;

Bu, kullanıcı adı ve parolalar gibi hassas verileri açığa çıkararak Secrets sonuçlarını orijinal SELECT sonuç kümesine karıştırır.

• Tabloları silmek için yıkıcı enjeksiyon:

  DROP TABLE DemoTable;

Bu, birinci ifadeyi noktalı virgül ile sonlandırarak ve ardından yıkıcı komutu ekleyerek ikinci bir SQL ifadesi (DROP TABLE) çalıştırır. Tim, tablonun kaybolduğunu gösteriyor — veritabanı kötü amaçlı SQL tarafından değiştirilmiş.

Tim'in noktası: saldırganların tablo veya sütun adlarını önceden bilmelerine gerek yok — tablo veya sütun adlarını veritabanı sunucularından listeleyebilir ya da davranışı keşfetmek için kör veya zamana dayalı teknikler deneyebilirler.

Çözüm 1 — Parametreli sorgular

Tim'in ilk ve en önemli savunması, kullanıcı verileriyle SQL dizeleri oluşturmayı bırakmaktır. Dinamik SQL'i parametreli sorgular ile değiştirin:

string sql = "SELECT * FROM People WHERE LastName = @LastName";
var results = connection.Query<Person>(sql, new { LastName = searchText });

string sql = "SELECT * FROM People WHERE LastName = @LastName";
var results = connection.Query<Person>(sql, new { LastName = searchText });

Tim, parametrizasyonun (özel ifadenin hazırlanmış bir biçimde kullanımı) veritabanının kullanıcı tarafından sağlanan girdiyle veri olarak sıkı bir şekilde ilgilendiği ve kötü amaçlı SQL'in sadece bir dizge değeri haline geldiği ve SQL yapısını değiştiremeyeceği anlamına geldiğini açıklar. Bu, birleşim tabanlı yükler ve eklenen ; dahil olmak üzere birçok yaygın SQL enjeksiyon saldırısını önler. DROP TABLE komutları.

Ayrıca, parametreleştirmeyi minimum giriş doğrulamasıyla eşleştirmeyi önerir: Bir soyadında olması olası olmayan karakterleri temizleyin veya engelleyin (örneğin, noktalı virgüller veya -- yorum işaretleyicileri) ancak O'Reilly'deki kesme işareti gibi yasal karakterlere izin verin. Parametreli sorgular + girdi temizleme, SQL enjeksiyon saldırılarına karşı önemli koruma sağlar.

Düzeltme 2 — Saklı prosedürler

Tim, bir proc içinde SQL'i birleştiren ve ardından bunu çalıştıran güvensiz bir saklı prosedürü ve parametreleri doğrudan kullanan güvenli bir saklı prosedürü gösteriyor.

• Tehlikeli depolanmış prosedür, parametreden bir @sql dizesi oluşturur ve EXEC kullanarak çalıştırır — hâlâ enjeksiyona karşı savunmasızdır.

• Güvenli saklı yordam SELECT işlemini gerçekleştirir ... WHERE LastName = @LastName ve parametre ile çalıştırılır — güvenli.

Tim şunu açıklar: saklı yordamlar, içlerinde dinamik SQL oluşturmaya devam ediyorsanız otomatik bir çözüm değildir. Ancak doğru kullanıldığında (dinamik SQL olmadan), saklı yordamlar SQL ifadelerini merkezileştirmeye yardımcı olur ve sorguların parametrelenmesini ve denetlenmesini kolaylaştırır. Depolanan prosedürler, SQL enjeksiyon önlemesini uygulamanızda basitleştirmeye de yardımcı olabilir.

Verilere — hatta veritabanı verilerine bile — güvenmeyin

Tim'in önemli ve genellikle gözden kaçan bir noktaya dikkat çektiği konu: Kendi SQL veritabanınızdan alınan verilere körü körüne güvenmemelisiniz. Saldırganlar bazen, daha sonra başka bir işlem tarafından dinamik SQL'de birleştirilecek kötü niyetli yükleri sütunlara (bir "zaman ayarlı bomba") yerleştirir. Tim ısrar ediyor: her adımda parametreler kullanın ve veri temizliği yapın — ister bir web formundan, ister bir dosya yüklemesinden, ister kendi veritabanınızdan gelsin — böylece kötü niyetli girişler daha sonra enjeksiyon için bir yol haline gelemez.

Ekstra ipucu — en az ayrıcalık ve veritabanı ayrıcalıklarını sınırlama

Kod düzeltmelerinin ötesinde, Tim savunma amaçlı yapılandırmayı öneriyor: uygulama hesaplarınız için veritabanı ayrıcalıklarını sınırlayın. Demo sırasında bağlantı, entegre güvenlik yoluyla bir yönetici hesabı kullanıyor — tehlikeli. Bunun yerine, asgari ayrıcalık ilkesini kullanın:

Uygulama için sadece ihtiyaç duyduğu haklara sahip bir veritabanı hesabı oluşturun.

• Eğer saklı yordamlar kullanırsanız, o hesaba sadece belirli saklı yordamlar için EXECUTE izni verin ve başka bir izni vermeyin.

• Uygulama hesaplarına ... geniş yönetici ayrıcalıkları vermeyin.

• Saklı yordamlar kullanıyorsanız, o hesaba yalnızca belirli saklı yordamlar üzerinde YÜRÜTME izni verin ve başka hiçbir izin vermeyin.

• Uygulama hesaplarına, DROP TABLE, tüm tabloları listeleme veya diğer veritabanlarını okuma gibi geniş yönetici ayrıcalıkları vermeyin.

Bu, başarılı bir SQL enjeksiyon saldırısının etkisini azaltır — enjeksiyon mümkün olsa bile, saldırgan, hesaba izin verilenden fazlasını yapamaz.

Tim ayrıca Entity Framework'ün bunu karmaşıklaştırdığını belirtiyor: EF genellikle yükseltilmiş izinler gerektirir (migrasyonlar, şema değişiklikleri). Üretimde EF kullanıyorsanız, izinlerini ve dağıtımını dikkatli bir şekilde planlayın.

Özet — durdur, parametrize et, temizle, sınırla

Tim, C# uygulamalarında SQL enjeksiyonunu önlemek için net bir kontrol listesi ile videosunu sonlandırıyor:

1. Kullanıcı girişi içeren dize birleştirme veya dinamik SQL ile SQL ifadeleri oluşturmayı bırakın.

2. Kullanıcı verilerinin her zaman veri olarak ele alınmasını sağlamak için parametreli sorguları / hazırlıklı ifade kalıplarını kullanın.

3. Uygun olan yerlerde girdi verilerini temizleyin (noktalı virgülleri, SQL yorumlarını, beklenmedik karakterleri engelleyin).

4. Sorgu mantığını merkezileştirmek için güvenli saklı yordamları tercih edin (içlerinde dinamik SQL bulunmamalıdır).

5. Veritabanı hesaplarına en az ayrıcalığı uygulayın — uygulamanın veritabanı kullanıcısının yapabileceklerini sınırlayın.

6. Kodu gözden geçirin (özellikle SQL'i dinamik olarak oluşturan yerleri) ve SQL enjeksiyon açıklarını test edin.

Tim'in son uyarısı: kullanıcı girdilerinin özensiz şekilde işlenmesi, dinamik SQL kullanımı ve aşırı veritabanı ayrıcalıkları ciddi ihlallere yol açabilir — hassas verilerin sızdırılması, tabloların yok edilmesi veya uzun süre fark edilmeden devam eden veri kaçırmaları. SQL enjeksiyon önlemesini isteğe bağlı bir düzenleme değil, temel bir güvenlik gereksinimi olarak ele alın.