Bugünlerde en yaygın kullanılan güvenlik en iyi uygulamalarından biri, vhost'un belge kökünden bir dizinden daha yukarı hareket ediyorwp-config.php gibi görünüyor . Bunun için hiçbir zaman iyi bir açıklama bulamadım, ancak webroot içindeki kötü amaçlı veya virüslü bir komut dosyasının veritabanı şifresini okuma riskini en aza indirdiğini varsayıyorum.

Ancak, WordPress'in erişmesine izin vermek zorundasınız, bu nedenle open_basedirdizini belge kökünün üstüne eklemek için genişletmeniz gerekiyor . Bu sadece tüm amacı bozmakla kalmıyor ve potansiyel olarak sunucu kayıtlarını, yedekleri vb. Saldırganlara da maruz bırakmıyor mu?

Veya teknik, yalnızca PHP motoru tarafından ayrıştırılmak yerine, wp-config.phpisteyen herkese düz metin olarak gösterilebilecek bir durumu önlemeye mi çalışıyor http://example.com/wp-config.php? Bu çok nadir görülen bir durum gibi gözüküyor ve günlükleri / yedekleri / etc'yi HTTP isteklerine maruz bırakmanın olumsuzluklarından ağır basmıyor.

Belki de bazı hosting kurulumlarında diğer dosyaları göstermeden doküman kökünün dışına taşımak mümkündür fakat diğer kurulumlarda bu mümkün değildir.

Sonuç: Bu konuda pek çok ileri geri döndükten sonra, yetkili olanlar olarak düşünülmesi gerektiğini düşündüğüm iki cevap ortaya çıkmıştır. Aaron Adams hareketli wp-config lehine iyi bir dava yapar ve chrisguitarguy buna karşı iyi bir dava yapar . Bu konuya yeniyseniz ve her şeyi okumak istemiyorsanız, okumanız gereken iki cevap. Diğer cevaplar gereksiz veya yanlış.

Kısa cevap: evet

Bu sorunun cevabı kesin bir evet , ve başka türlü söylemesi tamamen sorumsuz .

Uzun cevap: gerçek dünyadan bir örnek

wp-config.phpWeb kökünün dışına taşınmanın içeriğinin yakalanmasını özellikle engellediği gerçek sunucumdan gerçek bir örnek vermeme izin verin .

Böcek:

Plesk'deki bir hatanın bu açıklamasına bir göz atın (11.0.9 MU # 27'de düzeltildi):

Plesk, aboneliği barındırma planıyla eşitledikten sonra alt etki alanı iletmeyi sıfırladı (117199)

Kulağa zararsız geliyor, değil mi?

İşte bu hatayı tetiklemek için yaptıklarım:

1. Başka bir URL'ye (örn yönlendirmek için bir alt kurma site.staging.server.comiçin site-staging.ssl.server.com).
2. Aboneliğin servis planını değiştirdi (örneğin PHP yapılandırması).

Bunu yaptığımda, Plesk alt etki alanını varsayılanlara sıfırlar: ~/httpdocs/tercüman olmadan (örn. PHP) içerik sunma .

Ve farketmedim. Haftalarca.

Sonuç:

• İle wp-config.phpWeb köküne bir istek için /wp-config.phpWordPress yapılandırma dosyasını indirilmiş olacaktı.
• İle wp-config.phpweb kökü dışarıda bir istek için /wp-config.phptamamen zararsız dosyasını indirdim. Gerçek wp-config.phpdosya indirilemedi.

Bu nedenle, wp-config.phpweb kökünün dışına çıkmanın gerçek dünyada güvenlik açısından iyi bir avantaj sağladığı açıktır .

wp-config.phpSunucunuzdaki herhangi bir yere nasıl taşınır

WordPress, wp-config.phpdosyanız için WordPress kurulumunuzun üstünde bir dizine otomatik olarak bakacaktır , bu nedenle taşıdığınız yer o zaman biter!

Ama ya başka bir yere taşıdıysanız? Kolay. wp-config.phpAşağıdaki kodla WordPress dizininde yeni bir oluşturun :

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

(Yukarıdaki yolu, taşınan wp-config.phpdosyanızın asıl yoluyla değiştirdiğinizden emin olun .)

Bir sorunla karşılaşırsanız open_basedir, open_basedirPHP yapılandırmanızdaki yönergenin yeni yolunu eklemeniz yeterlidir:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

Bu kadar!

Aksine argümanları ayırmak

wp-config.phpWeb kökünün dışına taşınmaya karşı her argüman yanlış varsayımlara dayanır.

Bağımsız Değişken 1: PHP devre dışı bırakılmışsa, zaten

Birinin [ wp-config.php] içeriğini sunucuların PHP yorumlayıcısını atlatması durumunda görmesinin tek yolu … Eğer bu olursa zaten başınız belada demektir: Sunucunuza doğrudan erişimleri var.

YANLIŞ : Yukarıda tarif ettiğim senaryo, bir izinsiz giriş değil, yanlış yapılanmanın sonucudur.

Bağımsız Değişken 2: Yanlışlıkla PHP'yi devre dışı bırakmak nadirdir ve bu nedenle önemsizdir

Bir saldırgan PHP işleyicisini değiştirmek için yeterli erişime sahipse, çoktan batırdınız. Kazara değişiklikler benim deneyimimde çok nadirdir ve bu durumda şifreyi değiştirmek kolaylaşır.

YANLIŞ : Yukarıda tarif ettiğim senaryo, ortak bir sunucu yapılandırmasını etkileyen, ortak bir sunucu yazılımı parçasındaki bir hatanın sonucudur. Bu pek "nadir" (ve ayrıca güvenlik, nadir senaryo için endişelenmek anlamına gelir).

WTF : İzinsiz girişlerden sonra şifreyi değiştirmek, izinsiz giriş sırasında hassas bilgilerin toplanıp toplanmayacağı konusunda pek yardımcı olmaz. Gerçekten, biz hala WordPress'in yalnızca günlük bloglama için kullanıldığını ve saldırganların yalnızca tahrifatla ilgilendiğini düşünüyor muyuz? Sunucumuzu korumak konusunda endişelenelim, sadece birisi girdikten sonra geri yüklemekle kalmayacak.

Bağımsız Değişken 3: Erişimi reddetmek wp-config.phpyeterince iyi

Sanal ana bilgisayar konfigürasyonunuz yoluyla dosyaya erişimi kısıtlayabilir veya .htaccess- dosyaya dış erişimi etkin bir şekilde belge kökünün dışına taşınacak şekilde sınırlandırabilirsiniz.

YANLIŞ : Sanal bir ana bilgisayar için sunucu varsayılanlarınızın şu şekilde olduğunu hayal edin: PHP yok .htaccess, hayır , allow from all(üretim ortamında pek olağandışı değil). Yapılandırmanız rutin bir işlem sırasında bir şekilde sıfırlanırsa - örneğin panel güncellemesi gibi - her şey varsayılan durumuna dönecek ve siz açığa çıkacaksınız.

Ayarlar yanlışlıkla yanlışlıkla varsayılanlara sıfırlandığında güvenlik modeliniz başarısız olursa, daha fazla güvenlik gerekir.

WTF : Neden birisi özellikle daha az güvenlik katmanı önermektedir? Pahalı araçların sadece kilitleri yoktur; ayrıca alarmlara, immobilizerlere ve GPS izleyicilere sahiptir. Bir şey korumaya değerse, doğru yapın.

Tartışma 4: Yetkisiz erişim çok wp-config.phpönemli değil

Veri tabanı bilgileri gerçekten [ wp-config.php] içindeki tek hassas şeydir .

YANLIŞ : Kimlik doğrulama anahtarları ve tuzları, herhangi bir sayıda olası kaçırma saldırısında kullanılabilir.

WTF : Veritabanı kimlik bilgileri tek şey olsa bile wp-config.php, sen edilmelidir dehşete onlara ellerini sürebilmek bir saldırganın.

Bağımsız Değişken 5: wp-config.phpWeb kökünün dışına çıkmak bir sunucuyu daha az güvenli yapar

WordPress'in [ wp-config.php] erişimine izin vermeniz gerekir, bu nedenle open_basedirdizini belge kökünün üstüne eklemek için genişletmeniz gerekir .

YANLIŞ : Varsayının içeride wp-config.phpolduğunu httpdocs/, sadece hareket ettirin ../phpdocs/ve open_basedirsadece httpdocs/ve içerecek şekilde ayarlayın phpdocs/. Örneğin:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

( Varsa /tmp/, her zaman veya kullanıcı tmp/dizininizi eklemeyi unutmayın .)

Sonuç: konfigürasyon dosyaları her zaman daima daima web kökünün dışında bulunmalıdır.

Güvenliği önemsiyorsanız wp-config.php, web kökünüzün dışına çıkacaksınız.

En büyük şey wp-config.phpbazı hassas bilgiler içeriyor: veritabanı kullanıcı adınız / şifreniz, vs.

Yani fikir: onu belge kökünün dışına taşıyın ve hiçbir şey için endişelenmenize gerek yok. Saldırgan, bu dosyaya hiçbir zaman harici bir kaynaktan erişemez.

İşte ovmak, ancak: wp-config.phpaslında ekrana hiçbir şey yazdırmaz. Sadece WP kurulumunuzda kullanılan çeşitli sabitleri tanımlar. Böylece birileri bu dosyanın içeriğini görmek için tek yol, sunucularınızı PHP tercümanını aşarsa olur - .phpsadece düz metin olarak işlemek için dosya alırlar . Bu durumda, zaten başınız belada demektir: sunucunuza doğrudan erişimi var (ve muhtemelen kök izinleri var) ve ne isterlerse yapabilirler.

Devam edeceğim ve belge kökü dışına taşınmanın wp-configbir güvenlik perspektifinden faydalanamayacağını - yukarıda belirtilen nedenlerden dolayı söyleyeceğim :

1. Dosyaya erişimi, sanal host config veya .htaccess üzerinden kısıtlayabilirsiniz - dosyaya dış erişimi etkin bir şekilde sınırlandırmak için, belge kökünün dışına taşınacak şekilde kısıtlayabilirsiniz.
2. wp-configSSH üzerinden sunucunuza (sınırlı) erişim sağlasalar bile, dosyayı okuma hakkına sahip olmayan herhangi bir kullanıcının izin vermemesi için dosya izinlerinin sıkı olduğundan emin olabilirsiniz .
3. Hassas bilgileriniz, veritabanı ayarları, yalnızca tek bir sitede kullanılır. Bir saldırgan bu bilgilere erişmiş olsa bile, etkileyeceği tek site wp-config.phpdosyanın ait olduğu WordPress kurulumu olacaktır . Daha da önemlisi, söz konusu veritabanı kullanıcısı yalnızca söz konusu WP kurulumunun veritabanını okuma ve yazma iznine sahiptir ve başka hiçbir şey yapmaz - diğer kullanıcılara izin verme yetkisi yoktur. Diğer bir deyişle, eğer bir saldırgan veritabanınıza erişirse, bu sadece bir yedekten geri yükleme meselesidir (4. maddeye bakınız) ve veri tabanı kullanıcısını değiştirme meselesi
4. Sık sık yedekleme yapıyorsunuz. Genellikle göreceli bir terimdir: Her gün 20 makale gönderirseniz, her gün veya birkaç günde bir yedekleme yaparsanız daha iyi olur. Haftada bir kez posta gönderirseniz, haftada bir kez yedekleme yapmanız yeterlidir.
5. Sitenizi sürüm kontrolü altında (buna benzer şekilde ) sahip olursunuz ; bu , bir saldırganın erişim sağlasa bile, kod değişikliklerini kolayca algılayabilir ve geri alabilirsiniz. Bir saldırganın erişimi varsa wp-config, muhtemelen başka bir şeyle uğraşıyorlardır.
6. Veri tabanı bilgisi gerçekten hassas olan şey ve gerçekten wp-configdikkatli olduğunuz için (3. ve 4. maddelere bakınız), çok fazla bir şey değil. Tuzlar ve benzeri her zaman değiştirilebilir. Olan tek şey, kullanıcıların çerezlerinde oturum açtığını geçersiz kılmasıdır.

Bana wp-configgöre, belgeselden uzaklaşmak gizlilikten kaynaklanıyor - ki bu çok saman bir adam.

Bence Max'in bilgili bir cevap olduğunu ve bu hikayenin bir tarafı olduğunu düşünüyorum. WordPress Codex daha tavsiye vardır :

Ayrıca, yalnızca sizin (ve web sunucusunun) bu dosyayı okuyabildiğinden emin olun (genellikle 400 veya 440 izni demektir).

.Htaccess olan bir sunucu kullanıyorsanız, onun için sörf yapan herhangi birisine erişimi engellemek için bu dosyaya (en üste) koyabilirsiniz:

<files wp-config.php>
order allow,deny
deny from all
</files>

Wp-config.php dosyasındaki 400 veya 440 izninin ayarlanmasının, eklentilerin yazmasını veya değiştirilmesini engelleyebileceğini unutmayın. Örneğin gerçek bir durum, eklentileri önbelleğe almak olacaktır (W3 Total Cache, WP Super Cache vb.) Bu durumda, 600 ile giderim ( /home/userdizindeki dosyalar için varsayılan izin ).

Biri bizden içeri girmemizi istedi, ben de cevaplayacağım.

Evet, wp-config.php dosyanızı sitenizin kök dizininden izole etmenin güvenlik yararları vardır.

1- PHP işleyiciniz bir şekilde bozulursa veya değiştirilirse, DB bilgileriniz gösterilmez. Ve evet, bunun sunucu güncellemeleri sırasında paylaşılan ana makinelerde birkaç kez olduğunu gördüm. Evet, site bu süre zarfında kırılacak, ancak şifreleriniz eksiksiz olacak.

2- En iyi uygulamalar daima yapılandırma dosyalarının veri dosyalarından izole edilmesini önerir. Evet, WordPress (veya herhangi bir web uygulaması) ile bunu yapmak zordur, ancak yukarı taşımak biraz tecrit yapar.

3- Herhangi birinin? -S dosyasını bir dosyaya geçirip kaynağı görüntüleyebileceği PHP-CGI güvenlik açığını unutmayın. http://www.kb.cert.org/vuls/id/520827

Sonunda, bunlar küçük ayrıntılardır, ancak riski en aza indirmeye yardımcı olurlar. Özellikle paylaşılan bir ortamdaysanız, herhangi birinin veritabanınıza erişebileceği bir yerdeyseniz (tek ihtiyaçları olan bir kullanıcı / şifredir).

Ancak küçük dikkat dağıtma işlemlerinin (erken optimizasyonlar) bir siteyi düzgün bir şekilde güvenli hale getirmek için gerçekten gerekli olanın önüne geçmesine izin vermeyin:

1- Her zaman güncel tutun

2- Güçlü şifreler kullanın

3- Erişimi kısıtla (izinler yoluyla). Burada bir yazımız var:

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

Teşekkürler,

Kesinlikle evet.

Wp-config.php dosyasını genel dizinin dışına taşıdığınızda , php işleyicisi kötü amaçlı (ya da yanlışlıkla!) Değiştiğinde tarayıcı kullanarak okumayı önlersiniz.

DB giriş bilgilerinizin / şifrenizin okunması, sunucu bir topal yönetici hatası nedeniyle zorlukla bulaştığında mümkündür. Yöneticiden para cezası alın ve daha iyi ve daha güvenilir bir sunucu ana bilgisayarı elde edin. Buna rağmen daha pahalı olabilir.

Sadece argüman uğruna, wp_config.php dosyanızı taşımanızın mutlaka yalnızca üst dizine taşımak zorunda olduğunuz anlamına gelmediğini açıklığa kavuşturmak istiyorum. Diyelim ki / root / html gibi bir yapınız var, burada html WP kurulumunu ve HTML içeriğinizi içerir. Wp_config.php dosyasını / root dizinine taşımak yerine, her ikisini de html dizininin dışında olan ve aynı zamanda sunucu kök dizininde olmayan / root / secure ... gibi bir yere taşıyabilirsiniz. Tabii ki, php'nin de bu güvenli klasörde çalışabildiğinden emin olmanız gerekir.

WP, / root / secure gibi bir kardeş klasöründe wp_config.php dosyasını arayacak şekilde yapılandırılamadığından ek bir adım atmanız gerekir. Wp_config.php dosyasını / root / html içinde bıraktım ve hassas kısımları kestim (veritabanı girişi, tuz, tablo öneki) ve bunları config.php adlı ayrı bir dosyaya taşıdım. Daha sonra, PHP includekomutunu wp_config.php dosyasına şu şekilde ekleyin :include('/home/content/path/to/root/secure/config.php');

Temel olarak kurulumumda yaptığım şey bu. Şimdi, yukarıdaki tartışmaya dayanarak, hala gerekli olup olmadığını ya da iyi bir fikir olup olmadığını değerlendiriyorum. Ancak sadece yukarıdaki yapılandırmanın mümkün olduğunu eklemek istedim. Yedeklemelerinizi ve diğer kök dosyalarınızı göstermez ve güvenli klasör kendi genel URL’si ile ayarlanmadıkça göz atılamaz.

Ayrıca, orada bir .htaccess dosyası oluşturarak güvenli klasöre erişimi sınırlayabilirsiniz:

order deny,allow
deny from all
allow from 127.0.0.1

Atatcker'ların kod enjekte etmelerini sağlayan çok sayıda kötü yazılı tema ve eklenti var (Timthumb ile güvenlik konusunu unutmayın). Saldırgan olsaydım, neden wp-config.php'yi aramalıyım? Basitçe bu kodu enjekte edin:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Wp-config.php dosyanızı gizlemeyi deneyebilirsiniz. WordPress tüm hassas bilgileri küresel olarak erişilebilir hale getirdiği sürece, wp-config.php dosyasını gizlemenin bir faydası yoktur.

Wp-config.php dosyasındaki kötü kısım, hassas verileri tutmamasıdır. Kötü olan kısım, hassas verileri global erişilebilir bir sabit olarak tanımlamaktır.

Güncelleme

Sorunları define()ve hassas verileri küresel bir sabit olarak tanımlamanın neden kötü bir fikir olduğunu açıklamak istiyorum.

Bir web sitesine saldırmanın birçok yolu vardır. Komut dosyası enjeksiyonu, bir web sitesine saldırmanın tek yoludur.

Sunucunun, bir saldırganın bellek dökümüne erişmesine izin veren bir güvenlik açığı olduğunu varsayalım. Saldırgan, bellekte tüm değişkenlerin tüm değerlerini bulur. Genel erişilebilir bir sabit tanımlarsanız, komut dosyası sona erene kadar bellekte kalması gerekir. Sabit yerine bir değişken oluşturmak için, çöp toplayıcısının değişkenin artık gerekmediğinden sonra belleğin üzerine yazma (ya da serbest bırakma) olasılığı yüksektir.

Hassas verileri korumanın daha iyi bir yolu, kullandıktan hemen sonra bunları silmektir:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

Hassas verileri kullandıktan sonra, atama null, bellekteki verilerin üzerine yazacaktır. Saldırganın $db_con, hassas verileri içerdiği anda bellek dökülmesini alması gerekir . Ve yukarıdaki örnekte çok kısa bir süre var (eğer Database_Handler sınıfı bunun bir kopyasını kaydetmiyorsa).

Güvenlik avantajlarından ayrı olarak, aynı zamanda WordPress dosyalarını alt modül / harici olarak tutarken WordPress örneğinizi sürüm kontrolü altında tutmanıza izin verir. Mark Jaquith, WordPress-Skeleton projesini böyle ayarlamıştır. Ayrıntılar için https://github.com/markjaquith/WordPress-Skeleton#assumptions adresini ziyaret edin.