2013-07-03 34 views
17

Bunun daha önce istek kayıtlarımızda geldiğini gördüm. Neyi başarmaya çalışıyorlardı?SQL enjeksiyonu? CHAR (45,120,49,45,81,45)

tam isteği dizesi:

properties?page=2side1111111111111 UNION SELECT CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CHAR(45,120,53,45,81,45),CHAR(45,120,54,45,81,45),CHAR(45,120,55,45,81,45),CHAR(45,120,56,45,81,45),CHAR(45,120,57,45,81,45),CHAR(45,120,49,48,45,81,45),CHAR(45,120,49,49,45,81,45),CHAR(45,120,49,50,45,81,45),CHAR(45,120,49,51,45,81,45),CHAR(45,120,49,52,45,81,45),CHAR(45,120,49,53,45,81,45),CHAR(45,120,49,54,45,81,45) -- /* 

Düzenleme: bir google arama yararlı bir şey dönmedi gibi ben aynı şeyi karşılaşmak insanlar için soru sormak istiyorum.

+0

Şimdi, bu, google'da yaptığım orijinal arama için ikinci sonuç. – roo

cevap

7

Bu enjeksiyon için sadece bir testtir. Saldırgan çıktıda xQs görebiliyorsa, enjeksiyonun mümkün olduğunu bilirler.

Bu özel sorgudan "risk" yoktur. Bir geliştirici, ne tür enjeksiyon mekanizmaları, biçimler veya anlamlara dikkat etmemelidir - bunlar onun işinin hiçbiri değildir.

Yalnızca yanlış biçimlendirilmiş bir sorgu için sonsuz sayıda enjeksiyon için yalnızca bir neden vardır. Sorgularınız düzgün biçimlendirildikçe SQL enjeksiyonları mümkün değildir. SQL injection yöntemlerinden ziyade sorgularınıza odaklanın.

+0

"Bir geliştirici, ne tür enjeksiyon mekanizmaları, biçimler veya anlamlara dikkat etmemelidir - bunlar onun işinin hiçbiri değildir." - Detaylandırır mısın?Bana öyle geliyor ki, SQL enjeksiyonu umurumda olmamalı. Ya da tüm güvenimi kullandığım çerçeveye yerleştir. – roo

+0

Evet, evet. İşte bu - yapmamalısın. –

+0

Bu çılgınlık! İnsanlara bunun gibi düşünmelerini öneriyoruz, o zaman neden https://github.com/colshrapnel/safemysql yazdınız? – roo

5

Char() işlevi, her değeri bir tamsayı olarak yorumlar ve karakterleri verilen tamsayıların kod değerlerine göre bir dize döndürür. Char() ile NULL değerleri atlandı. İşlev, Microsoft SQL Server, Sybase ve MySQL içinde kullanılırken, CHR(), RDBMS'ler tarafından kullanılır. SQL sorgusu içinde bir önlem olarak PHP için addslashes() (örneğin). Char()'u kullanarak, enjekte edilen sorgudaki tırnak işareti gereksinimini ortadan kaldırır.

benzer görünecektir Char() kullanarak bir SQL Injection saldırılarından etkilendiğini bazı PHP kod örneği aşağıdadır: kullanılmıştır

$uname = addslashes($_GET['id']); 
$query = 'SELECT username FROM users WHERE id = ' . $id; 

addslashes() iken hiçbir sonunda tırnak olmadığı için, komut girişini sterilize düzgün başarısız işaret. Bu /etc/passwd dosyasını yüklemek için aşağıdaki SQL enjeksiyon dizesini kullanarak istismar olabilir:

Kaynak: http://hakipedia.com/index.php/SQL_Injection#Char.28.29

+0

Enjeksiyona hoş bir giriş ama soruyu gerçekten yanıtlamıyorsunuz, "_specific_ SQL, ne elde etmeye çalışıyor?" – paxdiablo

+0

Çalıştırmaya çalıştıkları belirli SQL'lerle ilgileniyorum, ancak bunun nasıl çalışabileceği ile de ilgileniyorum. Bir google arama yararlı bir şey vermediğinden, risk altında olabilecek kişiler için bir tartışma başlatmak istedim. – roo

+0

@roo, tartışmalar gerçekten SO için ne değildir. Eğer mevcut saldırının nasıl olacağını bilmek istediğinizi belirtiyorsanız (ve burada olduğu gibi görünüyor), bu başka bir konu. Ancak bir tartışma başlatma arzusu soruları kapatabilir ve silebilir. – paxdiablo