WordPress WPDB SQL Açığı

 

WordPress’de WPDB’de SQL Enjeksiyon Güvenlik Açığı

WordPress SQL açığı Bu aralar, WordPress kod tabanında çok önemli bir SQL Enjeksiyon güvenlik açığı bulunmaktadır.
Bunun WordPress “of the shelf” yani rafta satılmaya hazır, kullananları etkilemediğini belirtmek istiyorum.

Belli bir WordPress kodunu bir WordPress yüklemesinin dışında kullanırsanız, bu açıktan yararlanma imkanı sağlanabilir.

uzun lafın kısası bu “saldırılabilir” bir güvenlik açığı değildir yada başka bir şekilde söylemek gerekirse, bu tehdit seviyesi çok düşük olan yüksek düzeyde bir güvenlik açığıdır.

Ayrıca, bu açığın açıklanmasından bu yana 90 gün geçmesine rağmen WordPress tarafından düzeltilmediğini belirtmek gerekir

Güvenlik Açığı Kapsamı

WordPress’in güvensiz olmadığını ifade etmek istiyorum.
Yanı yüklü örnekler, uygulamaları özelliklerine bağlı olduğunu düşünürsek bu güvenlik açığından etkilenmediğini söyleye biliriz.

Bu sorunu güvenlik açığı olarak algılamamın sebebi, açık kaynaklı projelerin örnek olması gerektiğine inanıyorum.

Güvenlik Açığı

Şimdi size kavramın kodunu burada göstermek istiyorum:

Bu kod, özel olarak yapılandırılmış bir sunucusuyla birlikte yüklendiğini düşünürsek GBK karakterinin beklemeye alındığı için, bu SQL Enjeksiyonu işe yarayacaktır.

Yani temelinde karakter kümesi kullanıcı tarafından ayarlanmazsa ve site belirli bir karakter sınıfı kullanıyorsa Big5 bu nedenle diğerleri arasında, savunmasız kalacaktır.

Ancak yine açıklığa kavuşturayım, bunun gibi son derece ince bir durumda, internette tam anlamıyla 0 uygulamayı doğrudan etkileyecektir.
Bu açıklamanın amacı, insanların etki altında kalması değildir. Bunun 2013 yılı itibariyle olmaması için açıklanmıştır.

Güvenlik Açığı Kodu

Nasıl çalıştığını görmek için WPDB sınıfına bir göz atalım.

Şimdi ara sunucuya bakalım ve _weak_escape() fonksiyonu nedir? Bir gözden geçirelim

Eğer burada konunun farkında değilseniz, 2006’dan itibaren Chris Shiftlett’in addlashes hakkındaki yazısını okumanızı tavsiye ederim.

ifadeleri simüle eden bir hazırlama yöntemi var. Bunun nasıl çalıştığına göstermek istiyorum takip edin. .

Şimdi bunun ismi escape_by_ref Tabiki ki sağlıklı bir işleyişi var

şimdi bir tane daha komut var _real_escape çalışma yöntemi, ne işe yaradığını merak ediyorsanız inceleyin

mysql_real_escape_string() bu bağlantıyı kontrol ediyor, ve eğer henüz bir bağlantı yoksa, güvensiz bir şekilde çalışacağını belirtmek gerekir.

real_escape komutun özelliğin doğruluğunu kontrol eder. Bunun nasıl ayarlandığını merak ediyorsanız:

Set_charset() işlevi, birkaç parçayı kontrol eder ilk olarak, veri tabanı harmanlamalarını destekleyip desteklemediğini kontrol eder.

Ardından, karakter kümelerini destekleyip desteklemediğini kontrol eder.

Ardından, bir karakter seti açıkça ayarlayıp ayarlamadığını kontrol eder.

Ve addslashes() mysql_real_escape_string() geçecektir:


Dolayısıyla, MySQL’in eski bir sürüm 5.0.7’nin altında kullanıyorsanız real_escape_string bu komutlari hiç kullanmanız gerekmiyor.

Yukarıdaki kavramsal kanıt konseptimizde olduğu gibi, karakter kümesini açıkça ayarlamıyorsanız, mysql_real_escape_string() kullanmanız gerekmiyor..

Uzun lafın kısası, bu komut çok dağınık ve güvenliği uç noktalardan değil de, diğer yollardan komutlanmasını sağlar.

Bilgilendirme Zaman Çizelgesi

alt alta yazılmış şeylerin tümüne Çizelge deniliyor

17 Nisan Başlangıç raporu lider geliştiriciye gönderildi
17 Nisan (10 dakika sonra) Sorunun kabul edildiği ve olası çözüm tartışması yapıldı
23 Haziran ilerleme kaydedilmediği için 1 Temmuz’da e-posta ile kendilerine ulaştım.
23 Haziran (10 dakika sonra) Eylem planını belirten yanıt geldi. 24 saat içinde kodun gönderileceği belirtildi
23 Haziran daha fazla zaman istediler bu yüzden 16 Temmuz’a kadar bu açıklamayı ertelemeyi kabul ettim.
14 Temmuz 24 saat içinde” kodu alacağımı belirtildi fakat 2hafta erteleme talep eden bir e-posta aldım.
14 Temmuz herhangi bir ilerleme kaydedilmediği için 2 hafta daha açıklamayı erteleme talebini reddettim.
16 Temmuz´da lider geliştiricisini hayla kodu almadığımi bildir dim.

Bu yüzden 90 gün sonra açıklamaya karar verdim.

Başlangıçta 60 günde açıklamayı düşünüyordum, ancak yüksek bir tehdit seviyesi olmadığı için 75. güne ertelemeye karar verdim.

Ardından, 90 gün daha ertelemeye karar verdim.

Fakat daha fazla ilerlemeyi makul olarak kabul etmedim.

Orijinal rapordan bu yana 90 gün geçti. Düzeltme aslında oldukça açıktır.

Addslashes() örneğini mysql_real_escape_string() ile değiştirmeniz yeterlidir ve eğer bağlantı etkin değilse ve veri tabanı bağlantısını başlatırsanız bir hataya neden olabilirsiniz

Güvenlik Bir Sorumluluktur

Daha önce açık kaynak projelerinin kullanıcıları ve daha büyük topluluğa örnek vererek sorumluluk yüklediğini söylemiştim.

Bu mevzuda WordPress projesinin gerçekten bu dersi öğrenmesi gerekiyor.

Birincisi, addslashes() bir veri tabanı katmanında 2013’te bulunması, rahatsız edicidir.

Rahatsız edici bile bunu tarif etmiyor. Bu sadece büyük bir ihmal.

Kötü olan tarafı, geliştiricilerin sorunu anlamadığı değildir.

Bunun bir sorun olduğunu düşünmedikleri de değil, çünkü ince yada dar olsa da bunun bir sorun olduğunu kabul ediyorlar.

Ve bence çözüm bulamamaları bu durum daha da kötü bir hal almasını sağlıyor.

Bunun tek bir açıklaması ola bilir, bu kasıtlı olduğu anlamına geliyor. Ve affedilmez bir hatadır.

Açıkçası, projedeki bireysel geliştiricilere saldırmaya çalışmıyorum.

Bireysel geliştiriciler aslında akıllı ve rasyonel kişilerdir.

Gördüğüm kadarıyla sorun, projenin bir bütün olarak koyduğu politikalar ve uygulamalardan kaynaklanıyor.

Ancak, raporlamadan sonra gerçekleşen iletişimler devam ettiğini söyleye bilirim.

İlk raporun ardından, diğer yanıtım 2 ay sonra geldi ve gizli olan bu konuyu ortaya çıkarmakla tehdit ettiğim zamandı.

Bunun sonrasında 24 saat içinde, asla sahip olmadığım bir kod sözü verildi.

kişiler tarafından anlaşma gününden 2 gün önce haber aldım ve hayal kırıklığına uğradım çünkü bu konu dünyanın en büyük projelerinden birinin üstesinden gelmek konusu değildir.

ince bir konu olsa bile.Gerçekten bu kadar uzamasından dolayı oldukça hayal kırıklığına uğradım.

Yorum Yap

E-posta hesabınız yayımlanmayacak. Doldurulması zorunlu alanlar işaretlendi *