mysql_real_escape_string()Fonksiyonu kullanırken bile bir SQL enjeksiyon olasılığı var mı ?

Bu örnek durumu ele alalım. SQL PHP'de şu şekilde oluşturulmuştur:

$login = mysql_real_escape_string(GetFromPost('login'));
$password = mysql_real_escape_string(GetFromPost('password'));

$sql = "SELECT * FROM table WHERE login='$login' AND password='$password'";

Çok sayıda insanın bana böyle bir kodun hala tehlikeli ve mysql_real_escape_string()kullanılan işlevle bile kesmek mümkün olduğunu söylediğini duydum . Ama olası bir istismar düşünemiyorum?

Bunun gibi klasik enjeksiyonlar:

aaa' OR 1=1 --

çalışma.

Yukarıdaki PHP kodundan geçebilecek olası bir enjeksiyon biliyor musunuz?

Aşağıdaki sorguyu düşünün:

$iId = mysql_real_escape_string("1 OR 1=1");    
$sSql = "SELECT * FROM table WHERE id = $iId";

mysql_real_escape_string()sizi buna karşı korumaz. Sorgunuzdaki değişkenlerinizin etrafında tek tırnak ( ' ') kullanmanız sizi buna karşı koruyan şeydir. Aşağıdakiler de bir seçenektir:

$iId = (int)"1 OR 1=1";
$sSql = "SELECT * FROM table WHERE id = $iId";

Kısa cevap evet, evet etrafta dolaşmanın bir yolu varmysql_real_escape_string() .

Çok OBSCURE KENAR DURUMLARı için !!!

Uzun cevap o kadar kolay değil. Burada gösterilen bir saldırıya dayanıyor .

Saldırı

Öyleyse, saldırıyı göstererek başlayalım ...

mysql_query('SET NAMES gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

Belirli durumlarda, bu 1'den fazla satır döndürür. Burada olanları inceleyelim:

1. Karakter Kümesi Seçme

   mysql_query('SET NAMES gbk');

   İşe bu saldırı için, sunucunun hem kodlamak için bağlantıda bekliyor o kodlamayı ihtiyaç 'ASCII ie olarak 0x27 ve kimin nihai bayt bir ASCII bazı karakter var \yani 0x5c. Sonradan anlaşıldı ki, varsayılan olarak MySQL 5.6 desteklenen 5 tür kodlamalar vardır: big5, cp932, gb2312, gbkve sjis. Seçeceğizgbk .

   Şimdi, SET NAMESburada kullanımını not etmek çok önemlidir . Bu, SUNUCU ÜZERİNDEKİ karakter setini ayarlar . C API işlevine yapılan çağrıyı kullansaydık mysql_set_charset()iyi olur (2006'dan beri MySQL sürümlerinde). Ama neden bir dakika içinde daha fazla ...

2. Yük

   Bu enjeksiyon için kullanacağımız yük, bayt dizisi ile başlar 0xbf27. Bu gbkgeçersiz bir çokbaytlı karakterdir; içinde latin1, bu dize ¿'. İçinde olduğunu unutmayın latin1 ve gbk , 0x27kendi hazır bilgi üzerine 'karakteri.

   Bu yükü seçtik, çünkü eğer çağırırsak, addslashes()ASCII'yi \yani karakterden 0x5cönce 'eklerdik. Bu yüzden iki karakter dizisi 0xbf5c27olan bir rüzgârla karşılaşırız gbk: 0xbf5carkasından 0x27. Ya da başka bir deyişle, geçerli bir karakter ve ardından çıkış karakteri yok '. Ama kullanmıyoruz addslashes(). Bir sonraki adıma geçelim ...

3. mysql_real_escape_string ()

   C API çağrısı , bağlantı karakter kümesini bildiğinden mysql_real_escape_string()farklıdır addslashes(). Böylece sunucunun beklediği karakter kümesi için kaçmayı düzgün bir şekilde gerçekleştirebilir. Ancak, bu noktaya kadar, müşteri hala latin1bağlantı için kullandığımızı düşünüyor , çünkü bunu asla aksini söylemedik. Biz söyledin sunucu Kullandığımız gbkancak istemci hala sanıyor latin1.

   Bu nedenle mysql_real_escape_string()ters eğik çizgi ekleme çağrısı ve '"kaçan" içeriğimizde serbest asılı bir karakterimiz var ! Biz bakmak için olsaydı Aslında, $variçinde gbkkarakter kümesi, biz görürdük:

   OR 'VEYA 1 = 1 / *

   Bu tam olarak saldırının gerektirdiği şeydir .

4. Sorgu

   Bu bölüm sadece bir formalite, ancak işlenmiş sorgu:

   SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1

Tebrikler, başarıyla bir programa başarıyla saldırdınız mysql_real_escape_string()...

Kötü

Daha da kötüleşiyor. PDOvarsayılan taklit MySQL ile hazırlanan ifadeleri. Bu, istemci tarafında, temel olarak bir mysql_real_escape_string()C sprintf (C kütüphanesinde) yaptığı anlamına gelir, bu da aşağıdakilerin başarılı bir enjeksiyonla sonuçlanacağı anlamına gelir:

$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

Şimdi, taklit hazırlanmış ifadeleri devre dışı bırakarak bunu önleyebileceğinizi belirtmek gerekir:

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Bu genellikle doğru hazırlanmış bir deyimle sonuçlanır (yani veriler sorgudan ayrı bir pakette gönderilir). Ancak, PDO sessizce olacağını unutmayın çare o edilmektedir edebilirsiniz olanlar bu: ifadeleri taklit etmek MySQL doğal olarak hazırlamak olamayacağını listelenen kılavuzda ama) uygun sunucu sürümünü seçmek için dikkatli olun.

Çirkin

Ben Kullandığımız olsaydı biz tüm bu engelleyebilecek çok başlayarak söyledi mysql_set_charset('gbk')yerine SET NAMES gbk. 2006'dan beri bir MySQL sürümü kullanmanız koşuluyla bu doğrudur.

Daha eski bir MySQL salınımını, ardından kullanıyorsanız hata içinde mysql_real_escape_string()böyle bizim yükü içinde olanlar gibi geçersiz baytlı karakterler amaçları kaçmak için tek bayt olarak tedavi edildi anlamına geliyordu istemci doğru bağlantı kodlama haberdar olmuştu bile bu yüzden bu saldırı olur ve hala başarılı. Hata MySQL giderilmiştir 4.1.20 , 5.0.22 ve 5.1.11 .

Ama en kötüsü olduğunu PDOC API maruz vermedi mysql_set_charset()böylece önceki sürümlerinde bu 5.3.6 kadar olamaz , mümkün olan her komut için bu saldırıyı önlemek! Artık bir DSN parametresi olarak gösterilmektedir .

Kurtarıcı Lütuf

Başlangıçta söylediğimiz gibi, bu saldırının çalışması için veritabanı bağlantısı savunmasız bir karakter seti kullanılarak kodlanmalıdır. utf8mb4olduğunu savunmasız değil destekleyebilir henüz ve her MySQL 5.5.3 beri yerine-ama sadece olmuştur kullanılabilir kullanmayı seçebilir böylece: Unicode karakter. Bir alternatif utf8de savunmasız olmayan ve Unicode Temel Çok Dilli Düzlem'in tamamını destekleyebiliyor .

Alternatif olarak, NO_BACKSLASH_ESCAPES(diğer şeylerin yanı sıra) çalışmasını değiştiren SQL modunu etkinleştirebilirsiniz mysql_real_escape_string(). Bu mod etkinleştirildiğinde, 0x27değiştirilecek 0x2727ziyade 0x5c27kaçan süreci dolayısıyla ve olamaz , daha önce var olmayan savunmasız kodlamalarla geçerli karakterleri oluşturmak (yani 0xbf27hala 0xbf27vb.) - Sunucu yüzden hala geçersiz olarak dize reddedecektir . Bununla birlikte, bu SQL modunu kullanmaktan kaynaklanabilecek farklı bir güvenlik açığı için @ eggyal'ın cevabına bakın .

Güvenli Örnekler

Aşağıdaki örnekler güvenlidir:

mysql_query('SET NAMES utf8');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

Sunucu bekliyor çünkü utf8...

mysql_set_charset('gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

Çünkü karakter setini istemci ve sunucu eşleşecek şekilde doğru şekilde ayarladık.

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

Çünkü taklit hazırlanmış ifadeleri kapattık.

$pdo = new PDO('mysql:host=localhost;dbname=testdb;charset=gbk', $user, $password);
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

Çünkü karakter setini doğru ayarladık.

$mysqli->query('SET NAMES gbk');
$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "\xbf\x27 OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();

Çünkü MySQLi her zaman doğru hazırlanmış ifadeler yapar.

Paketleme

Eğer sen:

• Modern MySQL Sürümlerini (geç 5.1, tümü 5.5, 5.6 vb.) VE mysql_set_charset() / $mysqli->set_charset()/ PDO'nun DSN karakter parametresini (PHP ≥ 5.3.6'da) kullanın

VEYA

• Bağlantı kodlaması için savunmasız bir karakter seti kullanmayın (yalnızca utf8/ latin1/ ascii/ etc kullanıyorsunuz)

% 100 güvendesin.

Aksi halde, kullanmanıza rağmenmysql_real_escape_string() savunmasızsınız ...

TL; DR

mysql_real_escape_string()aşağıdaki durumlarda hiçbir koruma sağlamayacaktır (ve ayrıca verilerinizi daha da engelleyebilir):

• MySQL en NO_BACKSLASH_ESCAPES SQL modu etkindir ( her bağlandığınızda açıkça başka bir SQL modu seçmediğiniz sürece olabilir ); ve

• SQL dizgi değişmezleriniz çift tırnak "karakterleri kullanılarak alıntılanır .

Bu, hata # 72458 olarak dosyalandı ve MySQL v5.7.6'da düzeltildi (aşağıdaki " The Saving Grace " başlığına bakın).

Bu başka, (belki daha az?) Belirsiz KENAR ÖRNEK !!!

Hürmeten @ ircmaxell mükemmel bir cevap (gerçekten, bu dalkavukluk değil intihal olması gerekiyordu!), Onun biçimini kabul edecek:

Saldırı

Bir gösteri ile başlıyor ...

mysql_query('SET SQL_MODE="NO_BACKSLASH_ESCAPES"'); // could already be set
$var = mysql_real_escape_string('" OR 1=1 -- ');
mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');

Bu, tüm kayıtları testtablodan döndürür . Bir diseksiyon:

1. SQL Modu Seçme

   mysql_query('SET SQL_MODE="NO_BACKSLASH_ESCAPES"');

   Dize Değişmezleri altında belgelendiği gibi :

   Bir dizeye tırnak işareti karakterleri eklemenin birkaç yolu vardır:

   • “ '” İle alıntılanan bir dizenin içindeki “ '”, “'' .

   • “ "” İle alıntılanan bir dizenin içindeki “ "”, “"" .

   • Alıntı karakterinden önce bir kaçış karakteri (“\ ”) .

   • “ '” İle belirtilen bir dize içindeki “ "” özel bir işleme ihtiyaç duymaz ve iki katına çıkarılmamalı veya kaçmamalıdır. Aynı şekilde, “ "” ile belirtilen bir ipin içindeki “ '” özel bir işleme ihtiyaç duymaz.

   Sunucunun SQL modu şunları içeriyorsa NO_BACKSLASH_ESCAPES , bu seçeneklerin üçüncüsü - ki benimsediği genel yaklaşım bu mysql_real_escape_string()değildir - bunun yerine ilk iki seçenekten biri kullanılmalıdır. Dördüncü merminin etkisinin, kişinin verilerini munging yapmaktan kaçınmak için edebi alıntı yapmak için kullanılacak karakteri mutlaka bilmesi gerektiğine dikkat edin.

2. Yük

   " OR 1=1 -- 

   Yük, bu enjeksiyonu kelimenin tam anlamıyla " karakterle . Belirli bir kodlama yok. Özel karakter yok. Tuhaf bayt yok.

3. mysql_real_escape_string ()

   $var = mysql_real_escape_string('" OR 1=1 -- ');

   Neyse ki, mysql_real_escape_string()SQL modunu kontrol eder ve davranışını buna göre ayarlar. Bakınız libmysql.c:

   ulong STDCALL
   mysql_real_escape_string(MYSQL *mysql, char *to,const char *from,
                ulong length)
   {
     if (mysql->server_status & SERVER_STATUS_NO_BACKSLASH_ESCAPES)
       return escape_quotes_for_mysql(mysql->charset, to, 0, from, length);
     return escape_string_for_mysql(mysql->charset, to, 0, from, length);
   }

   Böylece farklı bir altta yatan işlev, escape_quotes_for_mysql() , NO_BACKSLASH_ESCAPESSQL modu kullanılıyorsa çağrılır . Yukarıda belirtildiği gibi, böyle bir fonksiyonun, diğer tırnak karakterinin kelimenin tam anlamıyla tekrarlanmasına neden olmadan tekrar edebilmek için değişmezi alıntılamak için hangi karakterin kullanılacağını bilmesi gerekir.

   Ancak, bu işlev isteğe bağlı olarak dizenin tek tırnak karakteri kullanılarak tırnak içine alınacağını varsayar' . Bakınız charset.c:

   /*
     Escape apostrophes by doubling them up
   
   // [ deletia 839-845 ]
   
     DESCRIPTION
       This escapes the contents of a string by doubling up any apostrophes that
       it contains. This is used when the NO_BACKSLASH_ESCAPES SQL_MODE is in
       effect on the server.
   
   // [ deletia 852-858 ]
   */
   
   size_t escape_quotes_for_mysql(CHARSET_INFO *charset_info,
                                  char *to, size_t to_length,
                                  const char *from, size_t length)
   {
   // [ deletia 865-892 ]
   
       if (*from == '\'')
       {
         if (to + 2 > to_end)
         {
           overflow= TRUE;
           break;
         }
         *to++= '\'';
         *to++= '\'';
       }

   Böylece, değişmezi alıntılamak için kullanılan gerçek karakterden bağımsız olarak çift ​​tırnak "karakterlerine dokunulmaz (ve tüm tek tırnak 'karakterlerini ikiye katlar ) ! Bizim durumda sağlandığı argüman olarak tamamen aynı kalıntılar kaçış yok yerini almıştır sanki -Bu hiç .$varmysql_real_escape_string()

4. Sorgu

   mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');

   Resmiyetle ilgili bir şey, işlenen sorgu:

   SELECT * FROM test WHERE name = "" OR 1=1 -- " LIMIT 1

Öğrenilen arkadaşımın söylediği gibi: tebrikler, bir programı başarıyla kullanarak saldırdınız mysql_real_escape_string()...

Kötü

mysql_set_charset()bunun karakter kümeleriyle ilgisi olmadığı için yardım edemez; ne de olabilir mysqli::real_escape_string(), çünkü bu aynı işlevin etrafında sadece farklı bir sargıdır.

Sorun, daha açık değilse, daha sonraki bir zamanda karar vermek için geliştiriciye bırakıldığı için, değişmezin hangi karakterle alıntılanacağını mysql_real_escape_string() bilememe çağrısında bulunulmasıdır . Bu nedenle, NO_BACKSLASH_ESCAPESmodda, bu işlevin keyfi tırnaklarla kullanmak için her girdiden güvenle kaçabilmesinin hiçbir yolu yoktur (en azından, iki katına çıkmayı gerektirmeyen ve böylece verilerinizi munginglemeyen karakterleri iki katına çıkarmadan).

Çirkin

Daha da kötüleşiyor. NO_BACKSLASH_ESCAPESstandart SQL ile uyumluluk gerekliliği nedeniyle vahşi doğada nadiren görülmeyebilir (örneğin, SQL-92 spesifikasyonunun bölüm 5.3'e , yani <quote symbol> ::= <quote><quote>dilbilgisi üretimine ve ters eğik çizgiye verilen özel bir anlamın eksikliğine bakınız). Dahası, kullanımı açıkça ircmaxell'in gönderisinin açıkladığı (uzun süredir sabit olan) hataya geçici bir çözüm olarak önerildi. Kim bilir, bazı DBA'lar varsayılan olarak açık olacak şekilde yapılandırılabilir.addslashes() .

Ayrıca, yeni bir bağlantının SQL modu sunucu tarafından yapılandırmasına göre ayarlanır ( SUPERkullanıcının istediği zaman değiştirebilir); bu nedenle, sunucunun davranışından emin olmak için her zaman bağlandıktan sonra istediğiniz modu açıkça belirtmeniz .

Kurtarıcı Lütuf

SQL modunu her zaman açıkçaNO_BACKSLASH_ESCAPES tek tırnak karakteri kullanarak MySQL dizgi değişmezlerini içermeyecek veya teklif etmeyecek şekilde ayarladığınız sürece , bu hata çirkin başını arkadan ayıramaz:escape_quotes_for_mysql() kullanılmayacak veya hangi alıntı karakterlerinin tekrarlanmasını gerektireceği varsayımı doğru ol.

Bu nedenle, ben kullanarak o kimseye tavsiye NO_BACKSLASH_ESCAPESde sağlarANSI_QUOTES tek tırnaklı dize değişmezlerinin alışılmış kullanımını zorlayacağından modu modu . Bunun, çift tırnaklı değişmez değerlerin kullanılması durumunda SQL enjeksiyonunu engellemediğini unutmayın; yalnızca bunun gerçekleşme olasılığını azaltır (çünkü normal, kötü amaçlı olmayan sorgular başarısız olur).

PDO'da, hem eşdeğer işlevi PDO::quote()hem de hazırlanan ifade öykünücüsü mysql_handle_quoter(), tam olarak bunu yapan: kaçan hazır bilginin tek tırnak içinde verilmesini sağlar, böylece PDO'nun bu hatadan her zaman bağışık olduğundan emin olabilirsiniz.

MySQL v5.7.6'dan itibaren bu hata düzeltildi. Değişiklik günlüğüne bakın :

İşlevsellik Eklendi veya Değiştirildi

• Uyumsuz Değişiklik: SQL modu etkinleştirildiğinde, ikinci işlev karakterleri düzgün şekilde kodlayamadığından, yeni bir C API işlevimysql_real_escape_string_quote()yerinegeçmiştir. Bu durumda,tırnak işaretleri iki katına çıkarılmadan kaçamaz ve bunu düzgün yapmak için, alıntı bağlamı hakkında mevcut olandan daha fazla bilgi sahibi olmalıdır. alıntı içeriğini belirlemek için fazladan bir argüman alır. Kullanım ayrıntıları için bkz. Mysql_real_escape_string_quote () .mysql_real_escape_string()NO_BACKSLASH_ESCAPESmysql_real_escape_string()mysql_real_escape_string_quote()

   Not

  Uygulamalar kullanımına modifiye edilmelidir mysql_real_escape_string_quote()yerine, mysql_real_escape_string()şimdi başarısız olur ve bir üretir, hangi CR_INSECURE_API_ERReğer hata NO_BACKSLASH_ESCAPESetkindir.

  Kaynaklar: Ayrıca bakınız Hata # 19211994.

Güvenli Örnekler

İrcmaxell tarafından açıklanan hata ile birlikte alındığında, aşağıdaki örnekler tamamen güvenlidir (birinin 4.1.20, 5.0.22, 5.1.11'den sonraki MySQL kullandığını veya bir GBK / Big5 bağlantı kodlaması kullanmadığını varsayarsak) :

mysql_set_charset($charset);
mysql_query("SET SQL_MODE=''");
$var = mysql_real_escape_string('" OR 1=1 /*');
mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');

... çünkü açıkça içermeyen bir SQL modu seçtik NO_BACKSLASH_ESCAPES.

mysql_set_charset($charset);
$var = mysql_real_escape_string("' OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

... çünkü dizgi değişmezimizi tek tırnakla alıntılıyoruz.

$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(["' OR 1=1 /*"]);

... PDO tarafından hazırlanan ifadeler bu güvenlik açığından etkilenmediğinden (ve ircmaxell'in PHP5.5.6 kullanmanız ve karakter kümesinin DSN'de doğru bir şekilde ayarlanmış olması ya da hazırlanan ifade öykünmesinin devre dışı bırakılması şartıyla) .

$var  = $pdo->quote("' OR 1=1 /*");
$stmt = $pdo->query("SELECT * FROM test WHERE name = $var LIMIT 1");

... çünkü PDO'nun quote()işlevi sadece değişmez kelimeden kaçmakla kalmaz, aynı zamanda tırnak içine alır (tek tırnaklı 'karakterlerle); Bu durumda ircmaxell en hatayı önlemek için not, sen gerekir PHP≥5.3.6 kullanıyor ve doğru DSN karakter kümesi belirledik.

$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "' OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();

... çünkü MySQLi tarafından hazırlanan ifadeler güvenlidir.

Paketleme

Böylece, eğer:

• yerel hazırlanmış ifadeleri kullan

VEYA

• MySQL v5.7.6 veya üstünü kullan

VEYA

• içinde ilave en az biri ircmaxell özetinde çözümlerden bir, kullanım istihdam etmek:

  • PDO;
  • tek tırnaklı dize değişmezleri; veya
  • içermeyen açıkça ayarlanmış bir SQL modu NO_BACKSLASH_ESCAPES

... o zaman tamamen güvende olmalısınız (dize kaçan dize kapsamı dışındaki güvenlik açıkları).

Aslında, %joker karakter dışında bundan geçebilecek hiçbir şey yok . LIKESaldırganın bunu %filtrelemezseniz giriş olarak girebileceği ve kullanıcılarınızdan herhangi birinin parolasını bruteforce etmesi gerektiği için deyimi kullanıyorsanız tehlikeli olabilir . Veriler sorgunun kendisine bu şekilde müdahale edemeyeceğinden, insanlar genellikle% 100 güvenli hale getirmek için hazırlanan ifadeleri kullanmanızı önerir. Ancak bu kadar basit sorgular için, muhtemelen böyle bir şey yapmak daha verimli olacaktır.$login = preg_replace('/[^a-zA-Z0-9_]/', '', $login);