Salah satu praktik terbaik keamanan paling umum akhir-akhir ini tampaknya memindahkan wp-config.phpsatu direktori lebih tinggi daripada root dokumen vhost . Saya tidak pernah benar-benar menemukan penjelasan yang baik untuk itu, tetapi saya berasumsi itu untuk meminimalkan risiko skrip berbahaya atau terinfeksi dalam webroot dari membaca kata sandi basis data.

Tapi, Anda masih harus membiarkan WordPress mengaksesnya, jadi Anda perlu memperluas open_basediruntuk memasukkan direktori di atas root dokumen. Bukankah itu hanya mengalahkan seluruh tujuan, dan juga berpotensi mengekspos log server, cadangan, dll untuk penyerang?

Atau teknik ini hanya mencoba untuk mencegah situasi di mana wp-config.phpakan ditampilkan sebagai teks biasa kepada siapa pun yang meminta http://example.com/wp-config.php, alih-alih diurai oleh mesin PHP? Itu tampak seperti kejadian yang sangat langka, dan itu tidak akan melebihi kerugian dari mengekspos log / backup / etc untuk permintaan HTTP.

Mungkin dimungkinkan untuk memindahkannya di luar root dokumen di beberapa pengaturan hosting tanpa mengekspos file lain, tetapi tidak pada pengaturan lainnya?

Kesimpulan: Setelah banyak bolak-balik tentang masalah ini, muncul dua jawaban yang menurut saya harus dianggap sebagai yang berwibawa. Aaron Adams membuat kasus yang baik dalam mendukung wp-config, dan chrisguitarguymakes kasus yang bagus untuk menentangnya . Itulah dua jawaban yang harus Anda baca jika Anda baru di utas dan tidak ingin membaca semuanya. Jawaban lainnya adalah redundan atau tidak akurat.

Jawaban singkat: ya

Jawaban untuk pertanyaan ini adalah ya tegas , dan mengatakan sebaliknya sepenuhnya tidak bertanggung jawab .

Jawaban panjang: contoh dunia nyata

Izinkan saya untuk memberikan contoh yang sangat nyata, dari server saya yang sangat nyata, di mana pindah ke wp-config.phpluar root web secara khusus mencegah kontennya ditangkap .

Serangga:

Lihatlah deskripsi bug di Plesk ini (diperbaiki pada 11.0.9 MU # 27):

Plesk me-reset penerusan subdomain setelah menyinkronkan berlangganan dengan paket hosting (117199)

Kedengarannya tidak berbahaya, bukan?

Nah, inilah yang saya lakukan untuk memicu bug ini:

1. Mengatur subdomain untuk mengarahkan ke URL lain (misalnya site.staging.server.comuntuk site-staging.ssl.server.com).
2. Mengubah paket layanan berlangganan (mis. Konfigurasi PHP-nya).

Ketika saya melakukan ini, Plesk mereset subdomain ke default: menyajikan konten ~/httpdocs/, tanpa penerjemah (mis. PHP) aktif.

Dan saya tidak menyadarinya. Selama berminggu-minggu.

Hasil:

• Dengan wp-config.phpdi root web, permintaan untuk /wp-config.phpmengunduh file konfigurasi WordPress.
• Dengan di wp-config.phpluar root web, permintaan untuk /wp-config.phpmengunduh file yang sama sekali tidak berbahaya. File asli wp-config.phptidak dapat diunduh.

Jadi, jelas bahwa pindah ke wp-config.phpluar root web memiliki manfaat keamanan yang bonafid di dunia nyata .

Cara pindah wp-config.phpke lokasi mana pun di server Anda

WordPress akan secara otomatis mencari satu direktori di atas instalasi WordPress Anda untuk wp-config.phpfile Anda , jadi jika Anda memindahkannya, Anda sudah selesai!

Tetapi bagaimana jika Anda memindahkannya ke tempat lain? Mudah. Buat yang baru wp-config.phpdi direktori WordPress dengan kode berikut:

<?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');

(Pastikan untuk mengubah jalur di atas ke jalur sebenarnya dari wp-config.phpfile yang Anda pindahkan .)

Jika Anda mengalami masalah dengan open_basedir, tambahkan saja jalur baru ke open_basedirarahan dalam konfigurasi PHP Anda:

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

Itu dia!

Memilih argumen yang bertentangan

Setiap argumen yang menentang pindah ke wp-config.phpluar root web bergantung pada asumsi yang salah.

Argumen 1: Jika PHP dinonaktifkan, mereka sudah masuk

Satu-satunya cara seseorang akan melihat bahwa konten [ wp-config.php] adalah jika mereka menghindari server Anda penerjemah PHP ... Jika itu terjadi, Anda sudah dalam masalah: mereka memiliki akses langsung ke server Anda.

FALSE : Skenario yang saya jelaskan di atas adalah hasil dari kesalahan konfigurasi, bukan intrusi.

Argumen 2: Menonaktifkan PHP secara tidak sengaja jarang terjadi, dan karenanya tidak signifikan

Jika penyerang memiliki akses yang cukup untuk mengubah handler PHP, Anda sudah kacau. Perubahan yang tidak disengaja sangat langka dalam pengalaman saya, dan dalam hal ini akan mudah untuk mengubah kata sandi.

SALAH : Skenario yang saya jelaskan di atas adalah hasil dari bug di bagian umum dari perangkat lunak server, yang mempengaruhi konfigurasi server umum. Ini hampir tidak "langka" (dan selain itu, keamanan berarti mengkhawatirkan skenario yang jarang terjadi).

WTF : Mengubah kata sandi setelah intrusi sangat membantu jika informasi sensitif diambil selama intrusi. Sungguh, apakah kita masih berpikir WordPress hanya digunakan untuk blogging biasa, dan bahwa penyerang hanya tertarik pada deflasi? Mari kita khawatirkan melindungi server kita, bukan hanya mengembalikannya setelah seseorang masuk.

Argumen 3: Menolak akses ke wp-config.phpcukup baik

Anda dapat membatasi akses ke file melalui konfigurasi host virtual Anda atau .htaccess- secara efektif membatasi akses luar ke file dengan cara yang sama seperti bergerak di luar root dokumen.

SALAH : Bayangkan default server Anda untuk host virtual adalah: tidak ada PHP, tidak .htaccess, allow from all(hampir tidak biasa dalam lingkungan produksi). Jika konfigurasi Anda entah bagaimana diatur ulang selama operasi rutin - seperti, katakanlah, pembaruan panel - semuanya akan kembali ke keadaan default, dan Anda terbuka.

Jika model keamanan Anda gagal ketika pengaturan secara tidak sengaja diatur ulang ke default, Anda memerlukan keamanan lebih.

WTF : Mengapa ada orang yang secara khusus merekomendasikan lebih sedikit lapisan keamanan? Mobil mahal tidak hanya memiliki kunci; mereka juga memiliki alarm, immobilizer, dan pelacak GPS. Jika ada sesuatu yang layak dilindungi, lakukan dengan benar.

Argumen 4: Akses tidak sah ke wp-config.phpbukan masalah besar

Informasi basis data adalah satu-satunya hal sensitif di [ wp-config.php].

SALAH : Kunci dan garam otentikasi dapat digunakan dalam sejumlah potensi serangan pembajakan.

WTF : Sekalipun kredensial basis data adalah satu-satunya yang ada di dalamnya wp-config.php, Anda harus takut penyerang akan mendapatkannya.

Argumen 5: Bergerak di wp-config.phpluar root web sebenarnya membuat server kurang aman

Anda masih harus membiarkan WordPress mengakses [ wp-config.php], jadi Anda perlu memperluas open_basediruntuk memasukkan direktori di atas root dokumen.

SALAH : Dengan asumsi wp-config.phpada httpdocs/, cukup pindahkan ke ../phpdocs/, dan setel open_basediruntuk menyertakan saja httpdocs/dan phpdocs/. Misalnya:

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

(Ingatlah untuk selalu memasukkan /tmp/, atau tmp/direktori pengguna Anda , jika Anda memilikinya.)

Kesimpulan: file konfigurasi harus selalu selalu selalu berada di luar akar web

Jika Anda peduli dengan keamanan, Anda akan pindah ke wp-config.phpluar root web Anda.

Yang terbesar adalah wp-config.phpberisi beberapa informasi sensitif: nama pengguna / kata sandi database Anda, dll.

Jadi idenya: pindahkan di luar root dokumen, dan Anda tidak perlu khawatir tentang apa pun. Penyerang tidak akan pernah dapat mengakses file itu dari sumber eksternal.

Namun, inilah intinya: wp-config.phptidak pernah mencetak apa pun di layar. Ini hanya mendefinisikan berbagai konstanta yang digunakan di seluruh instalasi WP Anda. Dengan demikian satu-satunya cara seseorang akan melihat bahwa isi file itu adalah jika mereka menghindari server Anda penerjemah PHP - mereka mendapatkan .phpfile untuk di render sebagai hanya teks biasa. Jika itu terjadi, Anda sudah dalam masalah: mereka memiliki akses langsung ke server Anda (dan mungkin izin root) dan dapat melakukan apa pun yang mereka suka.

Saya akan melanjutkan dan mengatakan tidak ada manfaatnya untuk pindah ke wp-configluar akar dokumen dari perspektif keamanan - karena alasan di atas dan ini:

1. Anda dapat membatasi akses ke file melalui konfigurasi host virtual atau .htaccess Anda - secara efektif membatasi akses luar ke file dengan cara yang sama seperti bergerak di luar root dokumen akan
2. Anda dapat memastikan izin file ketat wp-configuntuk mencegah pengguna mana pun tanpa hak istimewa yang memadai untuk membaca file bahkan jika mereka mendapatkan akses (terbatas) ke server Anda melalui SSH.
3. Informasi sensitif Anda, pengaturan basis data, hanya digunakan pada satu situs. Jadi, bahkan jika seorang penyerang mendapatkan akses ke informasi itu, satu-satunya situs yang akan terpengaruh adalah instalasi WordPress tempat wp-config.phpfile tersebut berada. Lebih penting lagi, bahwa pengguna basis data hanya memiliki izin untuk membaca dan menulis ke basis data instalasi WP dan dan tidak ada yang lain - tidak ada akses untuk memberikan izin pengguna lain. Artinya, dengan kata lain, jika penyerang mendapatkan akses ke basis data Anda, itu hanyalah masalah memulihkan dari cadangan (lihat poin 4) dan mengubah pengguna basis data.
4. Anda sering cadangan. Sering menjadi istilah relatif: jika Anda memposting 20 artikel setiap hari, Anda lebih baik membuat cadangan setiap hari atau setiap beberapa hari. Jika Anda memposting sekali seminggu, mencadangkan seminggu sekali kemungkinan sudah cukup.
5. Anda memiliki situs Anda di bawah kontrol versi ( seperti ini ), yang berarti bahkan jika penyerang memperoleh akses, Anda dapat dengan mudah mendeteksi perubahan kode dan mengembalikannya. Jika penyerang memiliki akses ke wp-config, mereka mungkin mengacaukan sesuatu yang lain.
6. Informasi basis data benar-benar satu-satunya hal yang sensitif wp-config, dan karena Anda berhati-hati tentang hal itu (lihat poin 3 dan 4), itu bukan masalah besar. Garam dan semacamnya dapat diubah kapan saja. Satu-satunya hal yang terjadi adalah ia membatalkan cookie pengguna yang masuk.

Bagi saya, wp-configkeluar dari root dokumen berbau keamanan oleh ketidakjelasan - yang sangat banyak.

Saya pikir Max adalah jawaban yang luas, dan itulah satu sisi dari cerita. The WordPress Codex memiliki lebih menyarankan :

Juga, pastikan bahwa hanya Anda (dan server web) yang dapat membaca file ini (umumnya berarti 400 atau 440 izin).

Jika Anda menggunakan server dengan .htaccess, Anda dapat meletakkan ini di file itu (di bagian paling atas) untuk menolak akses ke siapa pun yang berselancar untuknya:

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

Perhatikan bahwa pengaturan 400 atau 440 izin pada wp-config.php dapat mencegah plugin menulis atau memodifikasinya. Contoh asli adalah caching plugins (W3 Total Cache, WP Super Cache, dll.) Dalam hal ini, saya akan menggunakan 600 (izin default untuk file dalam /home/userdirektori).

Seseorang meminta kami untuk bersinar, dan saya akan menjawab di sini.

Ya, ada manfaat keamanan dari mengisolasi wp-config.php Anda dari direktori root situs Anda.

1- Jika handler PHP Anda rusak atau diubah dengan cara tertentu, informasi DB Anda tidak akan diekspos. Dan ya, saya melihat ini terjadi beberapa kali pada host bersama selama pembaruan server. Ya, situs akan rusak selama periode itu, tetapi kata sandi Anda akan tetap utuh.

2- Praktik terbaik selalu merekomendasikan mengisolasi file konfigurasi dari file data. Ya, sulit untuk melakukannya dengan WordPress (atau aplikasi web apa pun), tetapi memindahkannya sedikit terisolasi.

3 - Ingat kerentanan PHP-CGI, di mana siapa pun bisa meneruskan? -S ke file dan melihat sumbernya. http://www.kb.cert.org/vuls/id/520827

Pada akhirnya, itu adalah detail kecil, tetapi mereka memang membantu meminimalkan risiko. Khususnya jika Anda berada di lingkungan bersama, di mana siapa pun dapat mengakses database Anda (yang mereka butuhkan adalah pengguna / pass).

Tapi jangan biarkan gangguan kecil (optimasi prematur) terjadi di depan apa yang benar-benar diperlukan untuk mendapatkan situs dengan benar:

1- Selalu perbarui

2- Gunakan kata sandi yang kuat

3- Batasi akses (melalui izin). Kami punya posting tentang itu di sini:

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

Terima kasih,

Pasti ya.

Ketika Anda memindahkan wp-config.php di luar direktori publik, Anda melindunginya dari membaca menggunakan browser ketika php handler berubah menjadi berbahaya (atau tidak sengaja!).

Membaca login / kata sandi DB Anda dimungkinkan ketika server hampir tidak terinfeksi melalui kesalahan administrator lumpuh. Isi denda administrator dan dapatkan host server yang cenderung lebih baik dan lebih dapat diandalkan. Padahal itu mungkin lebih mahal.

Saya hanya ingin mengklarifikasi, demi argumen, bahwa memindahkan file wp_config.php Anda tidak selalu berarti Anda harus memindahkannya hanya ke direktori induk. Katakanlah Anda memiliki struktur seperti / root / html, di mana html berisi instalasi WP dan semua konten HTML Anda. Alih-alih memindahkan wp_config.php ke / root, Anda bisa memindahkannya ke sesuatu seperti / root / secure ... yang keduanya di luar direktori html dan juga tidak di direktori root server. Tentu saja, Anda perlu memastikan bahwa php dapat berjalan di folder aman ini juga.

Karena WP tidak dapat dikonfigurasi untuk mencari wp_config.php di folder saudara seperti / root / secure, Anda harus mengambil langkah tambahan. Saya meninggalkan wp_config.php di / root / html, dan memotong bagian sensitif (login database, garam, awalan tabel) dan memindahkannya ke file terpisah yang disebut config.php. Kemudian Anda menambahkan includeperintah PHP ke wp_config.php Anda, seperti ini:include('/home/content/path/to/root/secure/config.php');

Ini pada dasarnya adalah apa yang telah saya lakukan dalam pengaturan saya. Sekarang, berdasarkan diskusi di atas, saya masih mengevaluasi apakah itu perlu atau bahkan ide yang bagus. Tetapi saya hanya ingin menambahkan bahwa konfigurasi di atas dimungkinkan. Itu tidak mengekspos cadangan Anda dan file root lainnya, dan selama folder aman tidak diatur dengan URL publiknya sendiri, itu tidak dapat dijelajahi.

Selain itu, Anda dapat membatasi akses ke folder aman dengan membuat file .htaccess di sana dengan:

order deny,allow
deny from all
allow from 127.0.0.1

Ada banyak tema dan plugin yang ditulis dengan buruk di luar sana yang memungkinkan atatckers untuk menyuntikkan kode (ingat masalah keamanan dengan Timthumb). Jika saya akan menjadi seorang penyerang, mengapa saya harus mencari wp-config.php? Cukup menyuntikkan kode ini:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Anda dapat mencoba menyembunyikan wp-config.php Anda. Selama WordPress membuat semua informasi sensitif dapat diakses secara global, tidak ada untungnya menyembunyikan wp-config.php.

Bagian buruk di wp-config.php bukanlah ia menyimpan data sensitif. Bagian yang buruk adalah mendefinisikan data sensitif sebagai konstanta yang dapat diakses secara global.

Memperbarui

Saya ingin menjelaskan masalah dengan define()dan mengapa itu adalah ide yang buruk untuk mendefinisikan data sensitif sebagai konstanta global.

Ada banyak cara untuk menyerang situs web. Injeksi skrip hanya satu cara untuk menyerang situs web.

Dengan asumsi server memiliki kerentanan yang memungkinkan penyerang mengakses dump memori. Penyerang akan menemukan di memori dump semua nilai semua variabel. Jika Anda menetapkan konstanta yang dapat diakses secara global, ia harus tetap dalam memori hingga skrip berakhir. Membuat variabel alih-alih konstanta, ada kemungkinan besar bahwa pemulung akan menimpa (atau membebaskan) memori setelah variabel tidak lagi diperlukan.

Cara yang lebih baik untuk melindungi data sensitif adalah menghapusnya segera setelah menggunakannya:

$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;

Setelah menggunakan data sensitif, penugasan nullakan menimpa data dalam memori. Seorang penyerang harus mendapatkan memori dump tepat pada saat ketika $db_conberisi data sensitif. Dan itu adalah waktu yang sangat singkat dalam contoh di atas (jika kelas Database_Handler tidak menyimpan salinannya).

Terlepas dari manfaat keamanan, itu juga memungkinkan Anda untuk menyimpan contoh WordPress Anda di bawah kontrol versi sambil menjaga file inti WordPress sebagai submodule / eksternal. Ini adalah bagaimana Mark Jaquith mengatur proyek WordPress-Skeleton-nya. Lihat https://github.com/markjaquith/WordPress-Skeleton#assumptions untuk detailnya.