Neden sadece parametrelenmemiş sorgular bir hata döndürmüyor?

SQL enjeksiyonu çok ciddi bir güvenlik sorunudur, çünkü büyük ölçüde yanlış anlamak çok kolaydır: Kullanıcı girişi içeren bir sorgu oluşturmanın bariz ve sezgisel yolu sizi savunmasız bırakır ve bunu azaltmanın Doğru Yolu parametreleştirilmiş olarak bilmenizi gerektirir önce sorgular ve SQL enjeksiyonu.

Bana göre bunu düzeltmenin açık yolu bariz (ama yanlış) seçeneğini kapatmak olacaktır: veritabanı motorunu düzeltin, böylece parametrelerin yerine WHERE yan tümcesinde kodlanmış değerleri kullanan herhangi bir sorgu alınca güzel, açıklayıcı bir sonuç döndürür parametreleri yerine kullanmanızı bildiren hata mesajı. Bunun açık bir şekilde bir seçenek dışı bırakılması gerekir; böylece yönetimsel araçlardan gelen geçici sorgular gibi şeyler hala kolayca çalışır, ancak varsayılan olarak etkinleştirilmesi gerekir.

Bunu yapmak, SQL enjeksiyonunu neredeyse bir gece boyunca soğuyacaktı ama bildiğim kadarıyla hiçbir RDBMS bunu yapmıyor. Olmamasının iyi bir nedeni var mı?

Bir edebi kullanmanın doğru yaklaşım olduğu çok fazla durum vardır.

Performans açısından, sorgularınızda değişmezleri istediğiniz zamanlar vardır. Düşünsene, performanstan endişe duymaya yetecek kadar büyüdüğünde, sistemdeki hataların% 70'inin "kapalı",% 20'sinin "açık",% 5'inin "aktif" ve 5 olacağını % başka bir durumda olacak. Makul olarak tüm etkin hataları döndüren sorguyu almak isteyebilirim

SELECT *
  FROM bug
 WHERE status = 'active'

statusbağlama değişkeni olarak geçmek yerine . İçin iletilen değere bağlı olarak farklı bir sorgu planı statusistiyorum - kapalı hataları döndürmek için bir tablo taraması yapmak vestatusaktif kredileri iade etmek için sütun. Şimdi, farklı veritabanları ve farklı sürümler, farklı değişkenlere sahip (az çok başarılı) aynı sorgunun, bind değişkeninin değerine bağlı olarak farklı bir sorgu planı kullanmasına izin veriyor. Ancak bu, bir sorgunun yeniden ayrıştırılmasının zahmete uğramaması veya mevcut bir planın yeni bir bağlama değişkeni değeri için tekrar kullanılıp kullanılmayacağı kararını dengelemek için yönetilmesi gereken makul bir karmaşıklık ortaya koyma eğilimindedir. Bir geliştirici için bu karmaşıklıkla başa çıkmak mantıklı gelebilir. Veya verilerimin optimize ediciden daha çok neye benzeyeceği hakkında daha fazla bilgiye sahip olduğumda farklı bir yolu zorlamak mantıklı olabilir.

Bir kod karmaşıklığı açısından bakıldığında, SQL deyimlerinde değişmezleri olması mükemmel bir anlam ifade eder. Örneğin, zip_code5 karakterlik bir posta koduna ve bazen ek 4 basamağa sahip bir sütununuz varsa , bunun gibi bir şey yapmak mükemmel olur.

SELECT substr( zip_code, 1, 5 ) zip,
       substr( zip_code, 7, 4 ) plus_four

Sayısal değerler için 4 ayrı parametreden geçmek yerine. Bunlar değişecek şeyler değildir, bu yüzden değişkenleri bağlamalarını sağlamak, sadece kodun okunmasını zorlaştırmak ve birisinin parametreleri yanlış sırayla bağlama ve bir hata ile sonuçlanma potansiyelini yaratma işlevini görür.

SQL enjeksiyonu, bir sorgu güvenilir olmayan ve doğrulanmamış bir kaynaktan gelen metni bir sorgunun diğer bölümleriyle birleştirerek bir sorgu oluşturduğunda meydana gelir. Böyle bir şey en çok dize değişmezleri ile gerçekleşse de, gerçekleşmesi için tek yol bu olmazdı. Sayısal değerler için bir sorgu, kullanıcının girdiği bir dizeyi ( yalnızca rakam içermesi gerekiyordu ) alabilir ve normalde string değişmezleriyle ilişkilendirilmiş alıntı işaretleri olmadan bir sorgu oluşturmak için diğer malzemelerle birleştirilebilir; İstemci tarafı doğrulamasına aşırı derecede güvenen kod, alan adlarına benzer bir HTML sorgu dizesinden gelebilir. Bir SQL sorgusu dizisine bakmanın nasıl bir araya getirildiğini görmesinin bir yolu yoktur.

Önemli olan, bir SQL ifadesinin string değişmezleri içerip içermediği değil, bir dizgenin güvenilir olmayan kaynaklardan gelen karakter dizilerini içerip içermediği ve bunun için doğrulamanın sorguları oluşturan kütüphanede en iyi şekilde ele alınmasıdır. Genel olarak C # 'da bir dizgenin değişmezine izin verecek, ancak başka bir dize ifadesine izin vermeyecek kod yazmasına imkan yoktur, ancak bir sorguların sorgulama sınıfı yerine sorgu oluşturma sınıfı kullanılarak oluşturulmasını gerektiren bir kodlama-uygulama kuralına sahip olabilir. dize bitiştirme işleminin ve hazırlayıcı olmayan bir dizgiyi sorgu oluşturucuya ileten herkes böyle bir eylemi haklı göstermelidir.

SELECT count(ID)
FROM posts
WHERE deleted = false

Bunların sonuçlarını forumunuzun altbilgisine koymak istiyorsanız, sadece her seferinde yanlış demek için kukla bir parametre eklemeniz gerekir. Ya da saf web programcısı bu uyarının nasıl devre dışı bırakılacağına bakar ve devam eder.

Şimdi, enums'lar için bir istisna ekleyeceğinizi söyleyebilirsiniz ancak bu sadece deliği tekrar açar (daha küçük) İnsanlardan bahsetmemek, öncelikle varcharsonlar için kullanılmaması için eğitimli olmalıdır .

Enjeksiyonun asıl sorunu programatik olarak sorgu dizesini oluşturmaktır. Bunun çözümü, saklı bir prosedür mekanizmasıdır ve kullanımını veya izin verilen sorguların beyaz listesini zorlamaktır.

TL; DR : Sadece cümlelerde olmayanları değil, tüm harfleri kısıtlamanız gerekir WHERE. Yapmamaları nedeniyle, veritabanının diğer sistemlerden ayrı kalmasını sağlar.

İlk olarak, öncülünüz hatalı. Yalnızca WHEREcümleleri kısıtlamak istiyorsunuz , ancak kullanıcı girişinin gidebileceği tek yer bu değil. Örneğin,

SELECT
    COUNT(CASE WHEN item_type = 'blender' THEN 1 END) as type1_count,
    COUNT(CASE WHEN item_type = 'television' THEN 1 END) AS type2_count)
FROM item

Bu, SQL enjeksiyonuna eşit derecede savunmasızdır:

SELECT
    COUNT(CASE WHEN item_type = 'blender' THEN 1 END) FROM item; DROP TABLE user_info; SELECT CASE(WHEN item_type = 'blender' THEN 1 END) as type1_count,
    COUNT(CASE WHEN item_type = 'television' THEN 1 END) AS type2_count)
FROM item

Öyleyse, WHEREmaddedeki harfleri kısıtlayamazsın . Tüm değişmezleri kısıtlamanız gerekir .

Şimdi "Neden değişmezlere hiç izin verilsin?" Sorusundan ayrıldık. Şunu aklından çıkarma: ilişkisel veri tabanları başka bir dile bir zaman büyük bir yüzdesi yazılmış bir uygulamanın altına kullanılır iken, hiçbir orada gereklilik veritabanını kullanmak için uygulama kodunu kullanmak gerektiğini söyledi. Ve burada bir cevabımız var: kod yazmak için değişmezlere ihtiyacınız var. Diğer tek alternatif tüm kodun veritabanından bağımsız olarak bir dilde yazılmasını gerektirmektir. Böylece, onlara sahip olmak size doğrudan veritabanına "kod" (SQL) yazma yeteneği verir. Bu değerli bir ayrıştırma ve hazır bilgi olmadan imkansız olurdu. (En sevdiğiniz dilde, bazen hazır olmadan da yazmaya çalışın. Bunun ne kadar zor olacağını hayal edebileceğinizden eminim.)

Yaygın bir örnek olarak, değişmezler genellikle değer listesi / arama tabloları popülasyonunda kullanılır:

CREATE TABLE user_roles (role_id INTEGER, role_name VARCHAR(50));
INSERT INTO user_roles (1, 'normal');
INSERT INTO user_roles (2, 'admin');
INSERT INTO user_roles (3, 'banned');

Onlar olmadan, sadece bu tabloyu doldurmak için başka bir programlama dilinde kod yazmanız gerekir . Bunu doğrudan SQL'de yapabilme yeteneği değerlidir .

Daha sonra bir sorumuz kaldı: neden programlama dili istemcisi kütüphaneleri bunu yapmıyor? Ve burada çok basit bir cevabımız var: veritabanının desteklenen her bir sürümü için tüm veritabanı ayrıştırıcısını yeniden uygularlardı . Niye ya? Çünkü her kelimeyi bulduğunu garanti etmenin başka yolu yok. Normal ifadeler yeterli değil. Örneğin: Bu PostgreSQL'de 4 ayrı hazır bilgi içerir:

SELECT $lit1$I'm a literal$lit1$||$lit2$I'm another literal $$ with nested string delimiters$$ $lit2$||'I''m ANOTHER literal'||$$I'm the last literal$$;

Bunu yapmaya çalışmak bir bakım kabusu olur, özellikle de geçerli sözdizimi çoğu kez veritabanlarının büyük sürümleri arasında değiştiğinden.