SQL enjeksiyon önleme mekanizması neden parametreli hale getirilmiş sorguları kullanma yönünde gelişti?

Gördüğüm kadarıyla, SQL enjeksiyon saldırıları önlenebilir:

1. Dikkatlice tarama, filtreleme, kodlama girişi (SQL'e yerleştirmeden önce)
2. Kullanılması hazırlanmış tablolar / parametreli sorgular

Sanırım her biri için artılar ve eksiler var, ama neden 2. attı ve enjeksiyon saldırılarını engellemenin fiili bir yolu olduğu düşünüldü? Sadece daha mı güvenli ve hataya daha az yatkın mı yoksa başka faktörler var mıydı?

Anladığım kadarıyla # 1 doğru kullanılırsa ve tüm uyarılar dikkate alınırsa, # 2 kadar etkili olabilir.

Dezenfektan, Filtreleme ve Kodlama

Sanitasyon , filtreleme ve kodlamanın ne anlama geldiği arasında bazı karışıklıklar vardı . Amaçlarım için yukarıdakilerin hepsinin seçenek 1 için dikkate alınabileceğini söyleyeceğim. Bu durumda, temizlik ve filtrelemenin girdi verilerini değiştirme veya atma potansiyeline sahip olduğunu, kodlamanın olduğu gibi koruduğunu ancak kodlamadığını anladım. Enjeksiyon saldırılarını önlemek için Kaçan verilerin onu kodlamanın bir yolu olarak görülebileceğine inanıyorum.

Parametreli Sorgular ve Kodlama Kütüphanesi

Kavramları cevaplar vardır parameterized queriesve encoding librarieso birbirinin davranılır. Yanılıyorsam düzelt beni, ama farklı oldukları izlenimindeyim.

Anladığım kadarıyla, encoding librariesher zaman ne kadar iyi olursa olsun, her zaman SQL "Program" ı değiştirme potansiyeline sahipler , çünkü RDBMS'ye gönderilmeden önce SQL'de değişiklikler yapıyorlar.

Parameterized queries Öte yandan, SQL programını, sorguyu en iyi duruma getiren, sorgu yürütme planını tanımlayan, kullanılacak dizinleri vb. seçen RDBMS'ye gönderin ve ardından verileri RDBMS içindeki son adım olarak takın kendisi.

Kodlama Kütüphanesi

  data -> (encoding library)
                  |
                  v
SQL -> (SQL + encoded data) -> RDBMS (execution plan defined) -> execute statement

Parametreli Sorgu

                                               data
                                                 |
                                                 v
SQL -> RDBMS (query execution plan defined) -> data -> execute statement

Tarihsel Önemi

Bazı cevaplar, tarihsel olarak, parametreli hale getirilmiş sorguların (PQ) performans nedenleriyle ve kodlama sorunlarını hedef alan enjeksiyon saldırılarının popüler hale gelmesinden önce yaratıldığından bahseder. Bir noktada PQ'nun enjeksiyon saldırılarına karşı da oldukça etkili olduğu anlaşıldı. Sorumumun ruhuna uymak için, PQ neden tercih edilen yöntem olarak kaldı ve SQL enjeksiyon saldırılarını önleme konusunda neden diğer pek çok yöntemin üstünde gelişti?

Sorun şu ki # 1, üzerinde çalıştığınız SQL varyantının tamamını etkin bir şekilde ayrıştırmanızı ve yorumlamanızı gerektirir, bu yüzden yapmaması gereken bir şey yapıp yapmadığını bilirsiniz. Ve veritabanınızı güncellerken bu kodu güncel tutun. Sorgularınız için girişi kabul ettiğiniz her yer . Ve batırma.

Yani evet, bu tür bir şey SQL enjeksiyon saldırılarını durduracaktı, fakat uygulanması çok daha pahalı.

Çünkü seçenek 1 bir çözüm değildir. Tarama ve filtreleme, geçersiz girişi reddetmek veya kaldırmak anlamına gelir. Ancak herhangi bir giriş geçerli olabilir. Örneğin kesme işareti "O'Malley" adında geçerli bir karakterdir. Hazırlanan ifadelerin yaptığı SQL'de kullanılmadan önce doğru bir şekilde kodlanması gerekir.

Notu ekledikten sonra, temel olarak kendi fonksiyonel olarak benzer kodunuzu sıfırdan yazmak yerine neden standart bir kütüphane işlevi kullandığınızı soruyorsunuz. Her zaman kendi kodunuzu yazmak için standart kütüphane çözümlerini tercih etmelisiniz . Daha az iş ve daha fazla bakım yapılabilir. Bu, herhangi bir işlevsellik için geçerlidir, ancak özellikle güvenliğe duyarlı bir şey için tekerleği yeniden icat etmenin kesinlikle bir anlamı yoktur.

Dize işlemi yapmaya çalışıyorsanız, gerçekten bir SQL sorgusu oluşturmazsınız. Bir SQL sorgusu üretebilecek bir dize üretiyorsunuz. Hatalar ve hatalar için çok fazla alan açan bir dolaylı yönlendirme var . Çoğu durumda, programsal olarak bir şeyle etkileşime girmekten mutlu olduğumuz düşünülürse, bu gerçekten şaşırtıcı. Örneğin, bir liste yapımız varsa ve bir öğe eklemek istiyorsak, genellikle yapmayız:

List<Integer> list = /* a list of 1, 2, 3 */
String strList = list.toString();   /* to get "[1, 2, 3]" */
strList = /* manipulate strList to become "[1, 2, 5, 3]" */
list = parseList(strList);

Birisi bunu yapmayı öneriyorsa, bunun çok saçma olduğuna ve bunun sadece şunu yapması gerektiğine doğru cevap verirsin:

List<Integer> list = /* ... */;
list.add(5, position=2);

Bu, veri yapısı ile kavramsal düzeyde etkileşime girer. Bu yapının nasıl yazdırılacağı veya ayrıştırılacağına herhangi bir bağımlılık getirmez. Bunlar tamamen dikey kararlar.

İlk yaklaşımınız ilk örnek gibidir (sadece biraz daha kötü): İstediğiniz sorgu olarak doğru şekilde ayrıştırılacak dizeyi programlı olarak oluşturabileceğini varsayıyorsunuz. Bu, ayrıştırıcıya ve çok sayıda dize işleme mantığına bağlıdır.

Hazırlanan sorguları kullanmanın ikinci yaklaşımı, ikinci numuneye çok benzer. Hazırlanmış bir sorgu kullandığınızda, esasen yasal olan ancak içinde bazı yer tutucuları olan sözde bir sorguyu ayrıştırırsınız ve daha sonra içerisindeki bazı değerleri doğru şekilde koymak için bir API kullanırsınız. Artık ayrıştırma işlemine dahil değilsiniz ve herhangi bir dize işleminden endişelenmenize gerek yok.

Genel olarak, kavramsal düzeydeki şeylerle etkileşimde bulunmak çok daha kolay ve daha az hataya meyillidir. Bir sorgu bir dize değildir, bir sorgu bir dize ayrıştırırken elde ettiğiniz ya da programlı olarak bir tane oluşturduğunuzda (ya da başka bir yöntem bir tane oluşturmanıza izin verirse).

Burada basit metin değiştirme yapan C tarzı makrolar ve rastgele kod oluşturma yapan Lisp tarzı makrolar arasında iyi bir benzetme var. C tarzı makrolarla, kaynak koddaki metni değiştirebilir ve bu, sözdizimsel hatalar veya yanıltıcı davranışlar ortaya koyabileceğiniz anlamına gelir. Lisp makrolarıyla, derleyicinin işlediği biçimde kod oluşturuyorsunuz (yani, derleyicinin işleyeceği gerçek veri yapılarını döndürüyorsunuz, okuyucunun derleyiciden önce alabileceği metinleri değil) . Lisp makrosu ile, ayrıştırma hatası olabilecek bir şey üretemezsiniz. Örneğin, (a) ab (a) oluşturamazsınız .

Lisp makrolarında bile, yine de hatalı kod oluşturabilirsiniz, çünkü orada olması gereken yapının farkında olmanız gerekmez. Örneğin, Lisp'de (let ((ab)) a) "a değişkeninin b değişkeninin değerine yeni bir sözcüksel bağlanması kurun ve sonra" a "değişkeninin değerini döndürün " ve (let (ab) a) araçlarının "a ve b değişkenlerinin yeni sözcüksel bağlarını oluşturun ve ikisini de sıfır olarak sıfırlayın ve sonra a'nın değerini döndürün." Her ikisi de sözdizimsel olarak doğrudur, ancak farklı anlamlara gelir. Bu sorunu önlemek için, anlamsal olarak daha bilinçli işlevler kullanabilir ve aşağıdaki gibi bir şey yapabilirsiniz:

Variable a = new Variable("a");
Variable b = new Variable("b");
Let let = new Let();
let.getBindings().add(new LetBinding(a,b));
let.setBody(a);
return let;

Böyle bir şeyle, sözdizimsel olarak geçersiz olan bir şeyi geri döndürmek imkansızdır ve yanlışlıkla istediğinizi değil bir şeyi geri getirmek çok zordur .

Bu seçenek # 2 seçeneğinin genellikle en iyi yöntem olarak kabul edilmesine yardımcı olur, çünkü veritabanı sorgunun parametresiz sürümünü önbelleğe alabilir. Parametreli sorgular, SQL enjeksiyonu konusunu birkaç yıl öncesine kadar yutuyor (inanıyorum), bu yüzden iki kuşu bir taşla öldürebilirsin.

Basitçe dedi ki: Yapmadı. İfadeniz:

SQL Injection engelleme mekanizması neden Parametreli Sorguların kullanılması yönünde gelişmiştir?

temelde kusurlu. Parametreli sorgular, SQL Injection'ın en az bilinenlerinden daha uzun bir süredir var olmuştur. Genelde LOB (Line of Business) uygulamalarında kullanılan "arama için form" işlevselliği içerisinde dize toplanmasından kaçınmanın bir yolu olarak geliştirilmiştir. Çok - MANY - yıllar sonra, birisi dize manipülasyonuyla ilgili bir güvenlik sorunu buldu.

25 yıl önce SQL yaptığımı hatırlıyorum (internet yaygın olarak kullanılmadığında - sadece başlamıştı) ve IBM DB5 IIRC sürüm 5 ile SQL arasında yaptığımı hatırlıyorum - ve bu sorguları zaten parametreleştirmişti.

Diğer tüm iyi cevaplara ek olarak:

# 2'nin daha iyi olmasının nedeni, verilerinizi sizin kodunuzdan ayırmasıdır. # 1’de verileriniz kodunuzun bir parçasıdır ve tüm kötü şeylerin geldiği yer burasıdır. # 1 ile sorgunuzu alırsınız ve sorgunuzun verilerinizi veri olarak anladığından emin olmak için ek adımlar atmanız gerekir; oysa # 2'de kodunuzu alırsınız ve bu kod ve verileriniz veridir.

Parametreli sorguların, SQL enjeksiyon savunması sağlamanın yanı sıra, genellikle yalnızca bir kez derlenmenin ek bir faydası vardır, daha sonra farklı parametrelerle birden çok kez yürütülür.

SQL veri tabanı açısından select * from employees where last_name = 'Smith've select * from employees where last_name = 'Fisher'kesinlikle farklıdır ve bu nedenle ayrı ayrıştırma, derleme ve optimizasyon gerektirir. Ayrıca, derlenmiş ifadeleri saklamaya adanmış bellek alanında ayrı yuvalar tutacaktır. Ağır yüklü bir sistemde, farklı parametrelerin hesaplanması ve ek yükü olan çok sayıda benzer sorguya sahip önemli olabilir.

Daha sonra, parametreli hale getirilmiş sorguları kullanmak genellikle büyük performans avantajları sağlar.

Bekle ama neden?

Seçenek 1, her tür giriş için sterilize etme rutinleri yazmanız gerektiği anlamına gelirken, seçenek 2 daha az hataya eğilimlidir ve yazmanız / test etmeniz / sürdürmeniz için daha az koddur.

Neredeyse kesinlikle "tüm uyarılarla ilgilenmek" , düşündüğünüzden daha karmaşık olabilir ve diliniz (örneğin, Java Hazırlık Bildirimi), düşündüğünüzden daha fazla şey ifade eder.

Hazırlanan ifadeler veya parametreleştirilmiş sorgular, veritabanı sunucusunda önceden derlenir, böylece parametreler ayarlandığında, sorgu artık bir SQL dizesi olmadığından SQL birleştirme işlemi gerçekleştirilmez. Ek bir avantaj, RDBMS'nin sorguyu önbelleğe alması ve sonraki çağrılar, parametre değerleri değişse bile aynı SQL olarak kabul edilirken, birleştirilmiş SQL ile her sorgu farklı değerlerle çalıştırıldığında sorgunun farklı olması ve RDBMS'nin ayrıştırması gerekmesidir. , yürütme planını tekrar oluşturun, vb.

İdeal bir "sterilize et, filtrele ve kodla" yaklaşımının nasıl olacağını düşünelim.

Dezenfekte etmek ve filtrelemek, belirli bir uygulama bağlamında anlam ifade edebilir, ancak sonuçta ikisi de "bu verileri veritabanına koyamazsınız" demekten vazgeçer. Uygulamanız için bu iyi bir fikir olabilir, ancak genel bir çözüm olarak önerebileceğiniz bir şey değildir, çünkü veritabanında rasgele karakterler depolayabilmesi gereken uygulamalar olacaktır.

Böylece kodlama kalıyor. Kaçış karakterleri ekleyerek dizeleri kodlayan bir işleve sahip olarak başlayabilirsiniz, böylece bunları kendi başınıza değiştirebilirsiniz. Farklı veritabanları kaçan farklı karakterlere ihtiyaç duyduğundan (bazı veritabanlarında, her ikisi de \'ve ''her ikisi için de geçerli kaçış dizileri vardır ', ancak diğerleri için değil), bu işlevin veritabanı satıcısı tarafından sağlanması gerekir.

Ancak tüm değişkenler dizge değildir. Bazen bir tamsayı veya tarih yerine geçmeniz gerekir. Bunlar, dizelere farklı şekilde temsil edilir, bu nedenle farklı kodlama yöntemlerine ihtiyacınız vardır (yine, bunların veritabanı satıcısına özgü olması gerekir) ve bunları sorguya farklı şekillerde yerleştirmeniz gerekir.

Bu nedenle, belki de veritabanı sizin için ikame işlemeyi ele alırsa işler daha kolay olacaktır - sorgunun ne tür bir beklenti beklediğini ve verilerin güvenli bir şekilde nasıl kodlanacağını ve sorgunuzu güvenli bir şekilde nasıl sorgulayacağınızı zaten biliyor, bu yüzden endişelenmenize gerek yok kodunda.

Bu noktada, sadece parametreli hale getirilmiş sorguları yeniden icat ettik.

Sorgular parametrelendirildikten sonra, performans optimizasyonları ve basitleştirilmiş izleme gibi yeni fırsatlar açar.

Kodlamanın doğru yapılması zordur ve kodlama-tamam-sağ parametreleme işleminden ayırt edilemez.

Eğer gerçekten bina sorguları bir yolu olarak dize enterpolasyon gibi, geçmeli dize interpolasyon sahip dillerinde (Scala ve ES2015 akla gelen) bir çift vardır, öyleyse orada olan kütüphaneler , sen dize enterpolasyon gibi bakmak Parametrelenmiş sorguları yazalım ama SQL enjeksiyonundan güvenli - yani ES2015 sözdiziminde:

import {sql} from 'cool-sql-library'

let result = sql`select *
    from users
    where user_id = ${user_id}
      and password_hash = ${password_hash}`.execute()

console.log(result)

Seçenek 1'de, çok büyük bir çıktı boyutuyla eşlemeye çalıştığınız, size = infinity büyüklüğünde bir girdi kümesiyle çalışıyorsunuz. Seçenek 2'de, girişinizi seçtiğiniz her şeye sınırladınız. Başka bir deyişle:

1. [ Tüm güvenli SQL sorguları ] için [ sonsuzluk ] 'u dikkatlice inceleyin ve filtreleyin
2. [ Kapsamınızla sınırlı önceden düşünülmüş senaryolar ] kullanma

Diğer cevaplara göre, kapsamınızı sonsuzluktan uzaklaştırmanın ve yönetilebilir bir şeye doğru bazı performans avantajları olduğu da görülüyor.

Yararlı SQL modellerinden biri (özellikle modern lehçeler), her SQL deyiminin veya sorgunun bir program olduğudur. Yerel bir ikili çalıştırılabilir programda, en tehlikeli tür güvenlik açıkları bir saldırganın program kodunun üzerine farklı talimatlarla yazabileceği veya üzerinde değişiklik yapabileceği taşmalardır.

Bir SQL enjeksiyon güvenlik açığı, C gibi bir dilde bir arabellek taşması izomorfiktir. History, arabellek taşmalarının önlenmesinin çok zor olduğunu göstermiştir - açık incelemeye tabi son derece kritik kodlar bile bu güvenlik açıklarını içermektedir.

Taşma güvenlik açıklarını gidermeye yönelik modern yaklaşımın önemli bir yönü, belleğin belirli bölümlerini çalıştırılamaz olarak işaretlemek ve diğer belleğin salt okunur olarak işaretlenmesi için donanım ve işletim sistemi mekanizmalarının kullanılmasıdır. ( Örneğin Yürütülebilir alan koruması hakkındaki Wikipedia makalesine bakın .) Bu şekilde, bir saldırgan verileri değiştirebilse bile, saldırgan enjekte edilen verilerinin kod olarak değerlendirilmesine neden olamaz.

Öyleyse, bir SQL enjeksiyon güvenlik açığı bir arabellek taşmasına eşdeğerse, SQL NX bitine veya salt okunur bellek sayfalarına eşdeğerdir? Cevap şudur: parametreli hale getirilmiş sorgular ve sorgu olmayan istekler için benzer mekanizmalar içeren hazır ifadeler . Hazırlanan ifade, salt okunur olarak işaretlenmiş belirli bölümlerle derlenir, bu nedenle bir saldırgan programın bu bölümlerini ve çalıştırılabilir veri olarak işaretlenen diğer bölümleri (hazırlanan ifadenin parametreleri) değiştiremez; hiçbir zaman program kodu olarak değerlendirilmez, bu nedenle kötüye kullanım potansiyelinin çoğunu ortadan kaldırır.

Elbette, kullanıcı girişini dezenfekte etmek iyidir, ancak gerçekten güvenli olması için paranoyak olmanız gerekir (veya aynı zamanda bir saldırgan gibi düşünmek için). Program metni dışındaki bir kontrol yüzeyi bunu yapmanın yoludur ve hazırlanan ifadeler SQL için bu kontrol yüzeyini sağlar. Bu nedenle, hazırlanan ifadelerin ve dolayısıyla parametreleştirilmiş sorguların, güvenlik uzmanlarının büyük çoğunluğunun önerdiği yaklaşım olduğu şaşırtıcı değildir.

Bu konuda buraya yazmayı reddettim: https://stackoverflow.com/questions/6786034/can-parameterized-statement-stop-all-sql-injection/33033576#33033576

Ancak, sadece basit tutmak için:

Parametreli sorguların çalışma şekli, sqlQuery'nin bir sorgu olarak gönderilmesi ve veritabanı bu sorgunun ne yapacağını tam olarak bilmesi ve ancak bundan sonra kullanıcı adını ve parolaları yalnızca değerler olarak ekleyebilmesidir. Bu, sorguyu etkileyemedikleri anlamına gelir, çünkü veritabanı zaten sorgunun ne yapacağını bilir. Bu durumda, bu durumda "Nobody OR 1 = 1 '-" kullanıcı adını ve yanlış çıkması gereken boş bir şifre arayacaktır.

Yine de bu tam bir çözüm değildir ve giriş doğrulama işleminin yine de yapılması gerekecektir, çünkü bu, XSS saldırıları gibi diğer sorunları da yine de javascript'i veritabanına koyabileceğiniz gibi etkilemeyecektir. Sonra bu bir sayfaya okunursa, herhangi bir çıktı doğrulamasına bağlı olarak normal javascript olarak görüntüler. Bu yüzden gerçekten yapılacak en iyi şey hala giriş doğrulama kullanmak, ancak herhangi bir SQL saldırısını durdurmak için parametreli hale getirilmiş sorgular veya saklı yordamlar kullanmak.

Hiç SQL kullanmadım. Fakat belli ki insanların sahip olduğu sorunların ne olduğunu duyuyorsunuz ve SQL geliştiricileri bu "SQL Injection" ile ilgili problemler yaşadılar. Uzun zamandır çözemedim. Ardından, SQL ifadeleri yaratan insanların, gerçek metinsel SQL kaynak ifadeleri, bazılarını bir kullanıcı tarafından girilen dizeleri birleştirerek fark ettim. Ve bu gerçekleşmeyle ilgili ilk düşüncem şok oldu. Toplam şok. Düşündüm: Birisi nasıl bu kadar saçma aptal olabilir ve böyle bir programlama dilinde nasıl ifade verebilir? Bir C veya C ++ veya Java veya Swift geliştiricisi için bu tamamen delilik.

Bununla birlikte, bir C stringini argüman olarak alan bir C fonksiyonunu yazmak çok zor değildir ve aynı dizeyi temsil eden C kaynak kodundaki bir string değişmezine benzeyen farklı bir dize üretir. Örneğin, bu işlev abc'yi "abc" ve "abc" - "\" abc \ "" ve "\" abc \ "" - "\" \\ "abc \\" \ "" olarak çevirir. (Peki, bu size yanlış görünüyorsa, html. Bunu yazdığımda doğru, ancak görüntülendiğinde doğru değildi) Ve bir kez C işlevi yazıldığında, C kaynak kodunu oluşturmak hiç de zor değil. kullanıcı tarafından sağlanan bir giriş alanından gelen metin bir C string değişmezine dönüştürülür. Güvenli olması zor değil. Neden SQL geliştiricileri bu yaklaşımı SQL enjeksiyonlarından kaçınmanın bir yolu olarak kullanmayacaklardı.

"Sanitizing" tamamen kusurlu bir yaklaşımdır. Ölümcül kusur, belirli kullanıcı girişlerini yasa dışı kılmasıdır. Genel bir metin alanının benzeri metin içeremediği bir veritabanı ile bitiyorsunuz; Tablo ya da zarar vermek için bir SQL enjeksiyonunda ne kullanırsanız kullanın. Bunu kabul edilemez buluyorum. Bir veritabanı metin depolarsa, herhangi bir metni depolayabilmelidir . Ve pratik kusur şu ki, sterilizatör onu doğru anlayamıyor gibi görünüyor :-(

Elbette, parametreli hale getirilmiş sorgular, derlenmiş bir dili kullanan herhangi bir programcının beklediği şeydir. Hayatı çok daha kolay hale getirir: Bazı string girdileriniz vardır ve onu bir SQL string'e çevirmek için bile zahmete girmezsiniz, ancak sadece bir string olarak herhangi bir karaktere zarar verme olasılığı olmadan parametre olarak iletin.

Bu nedenle, derlenmiş dilleri kullanan bir geliştiricinin bakış açısından, temizlik, benim için asla gerçekleşmeyecek bir şeydir. Dezenfekte etme ihtiyacı delilik. Parametreli sorgular, sorunun net çözümüdır.

(Josip'in cevabını ilginç buldum. Temelde parametreleştirilmiş sorgularla SQL'e yönelik herhangi bir saldırıyı durdurabileceğinizi ancak veritabanında JavaScript enjeksiyonu oluşturmak için kullanılan bir metnin olabileceğini söylüyor :-( Yine aynı problemi yaşıyoruz) ve Javascript'in bunun için bir çözümü olup olmadığını bilmiyorum.

Asıl sorun, bilgisayar korsanlarının sağlık koşullarını çevrelemenin yollarını bulmasıdır; parametrelenmiş sorgular performans ve belleğin ekstra faydaları ile mükemmel şekilde çalışan mevcut bir prosedürdü.

Bazı insanlar sorunu "sadece tek bir alıntı ve çift alıntı" olarak basitleştirir, ancak bilgisayar korsanları farklı kodlamalar kullanmak veya veritabanı işlevlerini kullanmak gibi algılamayı engellemenin akıllı yollarını buldular.

Her neyse, yıkıcı bir veri ihlali oluşturmak için yalnızca tek bir dizgiyi unutmanız gerekiyordu. Bir veritabanı veya sorguyla veritabanının tamamını indirmek için komut dosyalarını otomatik hale getirebilen bilgisayar korsanları. Yazılım açık kaynak kodlu bir paket veya ünlü bir işletme paketi gibi iyi biliniyorsa, kullanıcılar ve şifreler tablosunu kolayca kullanabilirsiniz.

Öte yandan, yalnızca birleştirilmiş sorguları kullanmak sadece kullanmayı öğrenme ve ona alışma sorunuydu.