Semua produk perangkat lunak untuk melindungi skrip PHP dibagi menjadi dua kategori: yang memerlukan instalasi modul tambahan di server dan yang berfungsi dengan konfigurasi server web biasa. Yang pertama lebih dapat diandalkan dalam hal keamanan, karena mereka menerjemahkan skrip PHP dari bentuk tekstual ke dalam kode biner khusus, tetapi memerlukan akses ke server dengan hak administrator. Yang terakhir dapat bekerja di hampir semua hosting dengan dukungan PHP, termasuk yang gratis, tetapi tidak terlalu sulit untuk diretas. Kode sumber yang tidak menggunakan enkripsi atau kompresi dapat dibedakan menjadi subkelompok yang terpisah.
Perlindungan tingkat server:
Zend Encoder / Zend SafeGuard Suite adalah perlindungan komersial paling populer, modul untuk dukungan Zend biasanya diinstal pada semua hosting berbayar. Zend menyediakan skrip domain dan ip, waktu skrip percobaan, dan kebingungan yang kuat. Semua sistem operasi didukung. Di domain publik, ada beberapa opsi untuk utilitas penghapusan Zend, semuanya dimodifikasi PHP versi 4 dan 5. Versi Zend yang lebih lama dihapus tanpa masalah, yang terakhir ada kesulitan karena pengaburan kode sumber.Baru, perlindungan komersial yang sedang berkembang secara aktif. Ini menyediakan interaksi dengan skrip yang dilindungi pada tingkat API-nya sendiri; sistem operasi Windows dan Linux didukung. Karena prevalensinya yang rendah, itu tidak diinstal pada hosting virtual biasa, tetapi mungkin diinstal oleh pengguna di server khusus. Tidak ada decoder publik.
Perlindungan komersial praktis tidak ditemukan, tidak diinstal pada hosting virtual. Memungkinkan Anda mengatur periode percobaan untuk pengoperasian skrip dengan memeriksa tanggal pada server waktu eksternal, mengikat skrip yang dilindungi ke server, alamat ip, alamat MAC kartu jaringan, dan data ini digunakan untuk dekripsi. Semua sistem operasi didukung. Tidak ada decoder publik.
phpSHIELD. SourceGuardian untuk prototipe PHP. Setelah penggabungan dua pengembang, itu berhenti berkembang sebagai produk independen. Fungsi utamanya sama, tidak ada dekoder publik.
ionCube PHP Encoder. Produk perlindungan skrip komersial terpopuler kedua. Setelah kemunculan dekoder publik untuk Zend, semakin banyak digunakan dan diinstal pada hosting bersama. Memungkinkan Anda untuk mengenkripsi tidak hanya skrip, tetapi juga templat, dokumen xml, gambar, file biner. Ini mengikat file yang dilindungi ke server, ada obfuscator yang kuat, semua sistem operasi didukung. Tidak ada decoder publik, tetapi dalam beberapa kasus dapat dihapus oleh deZender.
Pengode PHTML. Sistem keamanan komersial langka yang menyediakan fungsionalitas biasa untuk produk jenis ini, berfungsi di semua sistem operasi. Dengan biaya terpisah, Anda dapat membeli kode keamanan asli dan memodifikasinya agar sesuai dengan kebutuhan Anda. Tidak ada decoder publik.
DWebEncoder. Perlindungan eksotis untuk Windows yang dirancang untuk membuat presentasi dan katalog bernaskah di CD. Dalam bentuk terinstal, itu seperti server web independen tempat skrip php yang disandikan dieksekusi. Tidak ada decoder publik.
PHP Kompak. Pembelaannya bersifat teoretis daripada praktis. Itu dikembangkan di salah satu forum domestik, tetapi sepertinya tidak berkembang melampaui rilis penulis. Namun, tidak ada dekoder, serta skrip yang dilindungi.
Add-on open source untuk akselerator php kuno Turck MMCache dan eAccelerator. Mengonversi skrip ke bytecode untuk meningkatkan kecepatan eksekusinya. Ada versi modul untuk Windows dan Linux. Tidak ada dekoder publik, tetapi mungkin kode sumber terbuka proyek akan membantu dalam penelitian ini.
Perlindungan tingkat sumber:
Kunci PHP! ... Perlindungan komersial populer, sangat umum, terutama dalam skrip dari pengembang asing. Memungkinkan Anda mengatur masa percobaan untuk pengoperasian skrip, mengikat domain dan alamat ip, mengompresi skrip menggunakan alat php standar (gzinflate). Satu-satunya bagian yang sulit adalah obfuscator yang baik. Versi perlindungan yang berbeda hanya berbeda dalam modifikasi modul pembongkaran. Mudah dilepas dalam mode manual dan otomatis. Tanpa obfuscator, itu dihapus persis ke kode sumber, dengan obfuscator, itu membutuhkan pemrosesan tambahan.CNCrypto. Bahkan tidak ada versi demo di domain publik, analisis dilakukan menggunakan skrip yang dilindungi. Modul berengsel tidak sulit untuk dibongkar, perlindungan hanya didasarkan pada pengaburan kode sumber yang baik.
PHPCipher. Perlindungan adalah layanan online. Arsip dengan skrip Anda diunggah ke situs dan yang sudah dilindungi diunduh kembali. Lisensi berbayar memungkinkan Anda menandatangani skrip yang dilindungi dengan data Anda dan menggunakannya untuk tujuan komersial. Lisensi gratis memungkinkan untuk penggunaan pribadi saja. Perlindungan itu sendiri adalah modul php yang dilindungi oleh Zend, yang terhubung ke skrip yang dilindungi.Setelah deZend, modul perlindungan dan mendapatkan semua konstanta yang diperlukan darinya dihapus sepenuhnya ke kode sumber. Tidak ada fungsi obfuscator.
Pelindung ByteRun untuk PHP. Produk komersial, tergantung pada jenis lisensi, memungkinkan Anda untuk melindungi skrip baik di tingkat server maupun di tingkat kode sumber. Perlindungan server dengan fitur standar, tidak ada yang istimewa. Perlindungan tingkat skrip dihapus dengan sangat mudah secara otomatis dan manual. Tidak ada dekoder publik untuk versi server.
Perlindungan sangat populer di kalangan pengembang dalam negeri. Ini adalah modul perlindungan yang penuh dengan kode kosong, yang terhubung melalui include ke skrip yang dilindungi. Algoritma decoding sangat sederhana, tidak menyebabkan kesulitan dalam penghapusan manual dan otomatis. Dalam semua kasus, itu dihapus sepenuhnya ke kode sumber, tidak ada fungsi obfuscator. Ada fitur kecil untuk kasus khusus decoding, tetapi mereka tidak akan dijelaskan di sini.
Kunci Kode. Pertahanan populer lainnya, contoh yang bagus dari pemrograman buta huruf. Ini adalah aplikasi php yang memungkinkan Anda untuk mengkodekan skrip itu sendiri dan hasil kerjanya di browser menggunakan javascript. Skrip dapat dilindungi dengan kata sandi, tetapi karena implementasi yang biasa-biasa saja, kata sandi mudah ditemukan bahkan tanpa melepas perlindungan berengsel. Modul perlindungan adalah skrip php yang dipenuhi dengan kode kosong yang terhubung ke skrip yang dilindungi. Algoritme perlindungan sangat sederhana, dihapus sepenuhnya ke kode sumber. Tidak ada fungsi obfuscation.
TrueBug PHP Encoder, baru-baru ini TrueBug PHP Obfuscator & Encoder. Sebuah tapak yang sangat menarik untuk dijelajahi. Sebelum versi 1.0.2, alat php standar untuk kompresi gzip digunakan, sejak versi 1.0.3 penulis telah mengembangkan algoritma kompresi mereka sendiri. Produk baru TrueBug PHP Obfuscator & Encoder menambahkan fungsi kebingungan dan pengoptimalan kode sumber. Satu-satunya titik lemah dari perlindungan ini adalah algoritme penguraian kode skrip yang tidak berubah-ubah, tetapi algoritme itu sendiri berubah untuk setiap versi perlindungan. Setelah diurai, proteksi mudah dihapus persis ke kode sumber, tentu saja, asalkan obfuscator tidak digunakan.
Zorex PHP CryptZ. Perlindungan, seperti CodeLock, adalah aplikasi php, memerlukan database MySQL untuk bekerja. Modul perlindungan adalah skrip php plug-in yang dienkripsi dalam beberapa lapisan. Setelah analisis, algoritme dihapus dengan sangat mudah tepat ke kode sumber. Tidak ada fungsi obfuscator.
Encoder PHP gratis. Layanan online gratis untuk coding script php. Modul perlindungan adalah skrip php plug-in yang dicakup oleh Zend, yang harus diunduh dari situs. Setelah Zend dihapus dan algoritme diuraikan, perlindungan dapat dengan mudah dihapus sepenuhnya ke kode sumber. Algoritma perlindungan tidak berubah, tidak ada fungsi obfuscator.
Skrip php, pengkodean primitif, standar base64. Itu tidak pantas mendapat perhatian lebih dan tidak ada kepentingan praktis.
Kami membuat halaman pendaftaran kami sendiri untuk multisite alih-alih wp-signup.php standar.
Dalam instalasi WordPress biasa, halaman pendaftaran (login, reset kata sandi) menampilkan file wp-login.php.
- /wp-login.php - otorisasi
- /wp-login.php?action=register - registrasi
- /wp-login.php?action=lostpassword - setel ulang sandi
Ada kondisi terpisah untuk multisite di wp-login.php. Jadi, ketika Anda mengklik tautan /wp-login.php?action=register di multisite, WordPress akan mengarahkan ulang ke halaman /wp-signup.php. Dalam banyak tema, halaman tidak terlihat sangat menarik, jadi kami akan membuatnya sendiri.
Situs utama jaringan
Secara default, WordPress membuka halaman pendaftaran (wp-signup.php) di domain utama (situs) jaringan. Namun, Anda dapat membuat halaman pendaftaran terpisah untuk setiap situs di jaringan, meskipun memiliki tema yang berbeda. Kami akan mempertimbangkan kasus ketika semua situs di jaringan memiliki halaman pendaftaran sendiri, tetapi tema yang sama digunakan dan situs hanya berbeda dalam bahasa. Jika Anda menggunakan tema yang berbeda, Anda perlu menulis lebih banyak kode.
fungsi.php?
Tidak. Nama file ini sepertinya disebutkan di setiap artikel WordPress. Dalam kasus kami, mengingat bahwa fungsi pendaftaran dirancang untuk beberapa situs, masuk akal untuk memindahkannya ke plugin MU yang dimuat saat Anda membuka situs apa pun.
Penyimpangan lirik
Perlu dicatat bahwa plugin MU dimuat lebih awal dari plugin biasa dan sebelum inti WordPress dimuat sepenuhnya, jadi memanggil beberapa fungsi dapat menyebabkan kesalahan fatal di PHP. Pemuatan "awal" ini juga memiliki kelebihan. Misalnya, di dalam tema apa pun, Anda tidak dapat melekat pada beberapa tindakan yang dipicu bahkan sebelum file functions.php dimuat dari tema. Contohnya adalah tindakan dari plugin Jetpack dalam bentuk jetpack_module_loaded_related-posts (posting terkait - nama modul) yang memungkinkan untuk melacak aktivitas modul di Jetpack. Tidak mungkin untuk "melekat" pada tindakan ini dari file tema, karena tindakan telah dipicu sebelum tema dimuat - plugin dimuat sebelum tema. Anda dapat melihat gambaran umum dari urutan pemuatan WordPress pada halaman Referensi Tindakan dalam kodeks.
Urutan berkas
Plugin MU dapat berisi sejumlah file dan struktur apa pun yang menurut Anda logis. Saya berpegang pada sesuatu seperti hierarki ini:
| -mu-plugins | - | -load.php | - | - | -selena-network | - | - | - | -signup | - | - | - | - | -plugin.php | - | - | - | - | -... | - | - | - | -jetpack | - | - | - | - | -plugin.php
Semua "plugin" yang diperlukan untuk jaringan kami terhubung di file load.php:
// Muat Traslates untuk semua addons load_muplugin_textdomain ("selena_network", "/ selena-network / bahasa /"); // Pendaftaran Jaringan memerlukan WPMU_PLUGIN_DIR. "/selena-network/signup/plugin.php"; // Plugin lain // membutuhkan WPMU_PLUGIN_DIR ...
Folder plugin disimpan di dalam folder selena-network, masing-masing memiliki plugin.php sendiri, yang kami sertakan di load.php. Ini memberi Anda fleksibilitas dan kemampuan untuk mematikan dan menghidupkan sesuatu dengan cepat.
Alamat halaman pendaftaran
Untuk menentukan alamat halaman pendaftaran, filter wp_signup_location digunakan. Itu dapat ditemukan di dalam file wp-login.php dan bertanggung jawab untuk mengarahkan ulang ke wp-signup.php.
Kasus "daftar": if (is_multisite ()) (wp_redirect (apply_filters ("wp_signup_location", network_site_url ("wp-signup.php"))); exit;
Mari tambahkan fungsi kita ke mu-plugins / selena-network / signup / plugin.php, yang akan mengembalikan alamat halaman pendaftaran di situs saat ini:
Fungsi selena_network_signup_page ($ url) (kembali home_url (). "/ Signup /";) add_filter ("wp_signup_location", "selena_network_signup_page", 99);
selena_network adalah awalan yang saya gunakan atas nama semua fungsi di dalam plugin MU di situs saya untuk menghindari tabrakan, itu harus diganti dengan awalan unik saya sendiri. Filter memiliki prioritas 99 karena beberapa plugin seperti bbPress dan BuddyPress dapat menimpa URL ini dengan milik mereka sendiri (plugin MU memuat lebih awal dari plugin biasa, lihat di atas). Perhatikan bahwa home_url () digunakan sebagai ganti network_site_url () untuk menjaga pengunjung tetap berada di domain yang sama. URL apa pun dapat digunakan sebagai alamat.
Buat Halaman
Sekarang mari kita buat halaman dengan alamat site.com/signup/ melalui antarmuka biasa, dan di folder tema anak, template untuk halaman baru kita adalah page-signup.php. ID unik dapat digunakan sebagai pengganti kata "mendaftar".
Di dalam template baru, Anda perlu memanggil fungsi selena_network_signup_main(), yang akan menampilkan formulir pendaftaran.
Perlu dicatat bahwa seluruh proses dengan template tidak diperlukan dan sebagai gantinya Anda dapat membuat kode pendek Anda sendiri, yang juga akan memanggil fungsi selena_network_signup_main ().
wp-signup.php dan wp-activate.php
Sekarang mari kita mulai membuat fungsi yang akan menampilkan formulir pendaftaran. Untuk melakukan ini, salin file wp-signup.php dan wp-activate.php dari root WordPress ke mu-plugings / selena-network / signup / (dan jangan lupa untuk menghubungkannya di dalam mu-plugins / selena-network / daftar / plugin.php) ... Manipulasi lebih lanjut dengan file sangat sulit dan memakan waktu untuk dijelaskan, jadi Anda harus melakukannya sendiri. Saya hanya akan menjelaskan apa yang sebenarnya perlu dilakukan dan mempublikasikan file sumber proyek saya:
- Di awal file, hapus semua kebutuhan, panggilan fungsi, dan kode lain di luar fungsi.
- Ganti nama semua fungsi dengan menambahkan awalan unik ke nama.
- Bungkus bagian bawah kode wp-signup.php dalam fungsi selena_network_signup_main dan tulis global $active_signup di awal; ...
- Ganti tata letak dengan milik Anda di tempat yang tepat.
Di dalam wp-activate.php, Anda perlu melakukan hal yang kurang lebih sama:
- Hapus semua kode di luar fungsi, bungkus tata letak dalam fungsi terpisah.
- Ubah tata letak jika perlu.
File wp-activate.php bertanggung jawab atas halaman aktivasi akun. Seperti halaman pendaftaran, Anda perlu membuat template terpisah untuk itu, di dalamnya Anda memanggil fungsi dari file wp-activate.php.
Kami mengirim surat aktivasi
Halaman pendaftaran mengirimkan email kepada pengunjung dengan tautan untuk mengaktifkan akun mereka. Secara default, ini dilakukan oleh fungsi wpmu_signup_user_notification() dari file ms-functions.php. Fungsinya dapat dipinjam untuk fungsi Anda. Alasan berhenti menggunakan fitur ini karena mengirimkan link aktivasi akun dari wp-activate.php. Anda dapat "menonaktifkan" fungsi ini menggunakan filter wpmu_signup_user_notification, memberikan false padanya (jika Anda tidak melakukan ini, surat aktivasi akan dikirim dua kali, oke, sebenarnya, dua huruf berbeda).
Fungsi armyofselenagomez_wpmu_signup_user_notification ($ user, $ user_email, $ key, $ meta = array ()) (// ... // Kode dari fungsi wpmu_signup_user_notification () wp_mail ($ user_email, wp_specialchars_decode ($ message_headers), $ message), $ ; return false;) add_filter("wpmu_signup_user_notification", "armyofselenagomez_wpmu_signup_user_notification", 10, 4);
Alhasil, halaman registrasi di tema Selena terlihat jauh lebih bersih dan akurat.
Kesimpulan
Ada banyak cara lain yang kurang tepat untuk melakukan hal yang sama di Internet - pengalihan Apache, formulir AJAX yang tidak akan berfungsi tanpa Java Script, dll. situs web sendiri.
Perhatikan bahwa Anda harus mengedit file dengan hati-hati dan mencoba untuk tidak menyimpang jauh dari aslinya, sehingga di masa depan, jika WordPress mengubah file wp-signup.php dan wp-activate.php, akan lebih mudah untuk membandingkannya untuk menemukan perubahan.
Jangan lupa untuk melihat kode sumber dari semua fungsi yang dijelaskan di atas untuk memahami sepenuhnya apa dan bagaimana yang terjadi di dalam kode.
Bonus. Perlindungan spammer
Bahkan situs WordPress terkecil pun sering mengalami registrasi spam. Anda dapat menulis kondisi tanpa akhir untuk memfilter bot, seringkali lebih seperti mencoba membuat kecerdasan buatan Dalam kasus multisite, pengalihan biasa di Apache sangat membantu saya, yang saat membuka /wp-signup.php dan /wp- acitvate.php, saya meminta 404 (saya bukan ahli dalam konfigurasi Apache, jadi aturan saya mungkin tidak terlalu benar).
RewriteEngine On RewriteBase / RewriteRule ^ wp-signup \ .php - RewriteRule ^ wp-activate \ .php - # BEGIN WordPress # Jangan sentuh aturan WordPress secara default :) # ... # END WordPress
P. S. Saya mencoba menjelaskan sedetail mungkin beberapa hal pihak ketiga, karena ketika saya memulai, terkadang tidak ada yang meminta dan menjelaskan banyak hal. Saya juga percaya bahwa tips kecil tentang materi lain akan mendorong seseorang untuk mempelajari sesuatu yang baru dan memperluas bidang pengetahuan mereka. Ekspresi reguler digunakan dalam entri RewriteRule, sama sekali tidak rumit, misalnya, karakter ^ berarti awal baris.
“Mereka merusak situs web bank untuk uang, Pentagon untuk spionase, dan tidak ada yang membutuhkan proyek saya,” sayangnya, inilah yang dipikirkan sebagian besar pemilik blog pribadi, kartu nama Internet, kantor virtual perusahaan kecil. Hanya sedikit orang yang berpikir tentang cara melindungi situs, tetapi sia-sia. Dalam realitas modern, platform apa pun, terlepas dari jenis atau popularitasnya, menarik di mata para peretas. Siapa yang mungkin membutuhkan sumber daya Anda dan mengapa? Mari kita cari tahu:
1. Lelucon scriptkiddis. Jargon mengacu pada calon peretas yang mengambil langkah pertama mereka di "sisi gelap". Setelah memperoleh beberapa alat, atau dengan menulis beberapa program mereka sendiri, mereka ingin menguji kinerja mereka pada korban pertama yang mereka temui, dan, sebagai aturan, memilih target CMS yang paling mudah (dilindungi dengan lemah dan tidak diperbarui).
2. SEO Hitam. Layanan pengoptimal yang tidak jujur masih digunakan - penempatan tautan tersembunyi dalam kode proyek dengan lebih dari 10 TCI masih dilakukan. Dan, pertama-tama, sumber daya pada mesin sumber terbuka (Joomla, Drupal, OpenCart, dan sebagainya) diserang.
3. Membangun botnet. Melindungi WordPress dengan htaccess dan plugin juga relevan karena sumber daya apa pun dapat digunakan untuk membuat jaringan zombie yang digunakan dalam serangan DDoS, spamming, dll.
4. Kerusakan agunan. Terakhir, Anda tidak boleh diserang - tujuan utamanya adalah hosting, dan situs hanya akan berfungsi sebagai satu kerentanan besar infrastruktur TI penyedia. Tentu saja, peretas tidak akan peduli dengan nasibnya.
Konsekuensi peretasan bisa menjadi yang paling tidak menyenangkan: hilangnya konten, atau sumber daya secara keseluruhan, pesimisme dalam hasil mesin pencari, hilangnya audiens karena tulisan "Situs dapat mengancam keamanan komputer atau perangkat seluler", dan bahkan risiko terlibat dalam kasus kriminal jika tindakan ilegal telah dilakukan berdasarkan sumber daya web Anda.
Jadi, kami dapat dengan yakin mengatakan bahwa masalah keamanan benar-benar memengaruhi setiap webmaster. Dan jika Anda mengabaikannya, semua upaya untuk mempromosikan mesin pencari (dan ini adalah uang dan waktu yang berharga) dapat menjadi sia-sia dalam semalam. Masalahnya sangat mendesak, jadi saya memutuskan untuk memulai serangkaian artikel yang ditujukan untuk ancaman jaringan dan metode untuk menghadapinya. Sistem CMS populer - Wordpress akan dipertimbangkan dalam tiga masalah.
Metode untuk mengamankan situs WordPress
Salah satu metode hacking yang paling primitif adalah brute force. Secara harfiah istilah ini diterjemahkan sebagai "brute force", dan berarti mendapatkan sepasang login / kata sandi dengan penghitungan brute force dari opsi yang mungkin. Seringkali, brute-forcer mencoba membuat hidup mereka lebih mudah dengan memanfaatkan kesalahan dalam pengaturan mesin dan server - ini membantu mereka, misalnya, mengetahui nama akun, yang secara signifikan mengurangi jumlah kombinasi. Ini tentang penghapusan kerentanan ini, serta metode memerangi upaya akses tidak sah yang akan dibahas.
1. Gunakan login administrator yang unik
Secara default, sistem menawarkan untuk membuat pengguna bernama admin. Namun, untuk melindungi situs WordPress Anda, yang terbaik adalah menggunakan login yang terdiri dari serangkaian huruf dan angka acak. Pada sumber daya langsung, nama administrator dapat diubah tanpa masalah menggunakan salah satu dari dua metode:
Melalui panel admin. Buka bagian "Pengguna", klik tombol "Tambah Baru" dan buat akun. Di bidang "Peran", pilih "Administrator" dan konfirmasikan operasi. Kemudian masuk kembali atas nama akun yang baru dibuat, kembali ke bagian "Pengguna", pilih "admin" dan klik "Hapus". Di jendela yang terbuka, letakkan tombol radio di posisi "Tautkan semua konten" dan pilih administrator baru dari daftar tarik-turun, lalu klik "Konfirmasi penghapusan".
... Menggunakan phpMyAdmin. Jauh lebih mudah untuk melakukan prosedur yang sama melalui panel kontrol database. Pilih database yang diperlukan, cari tabel wp_users, cari baris “admin” (ID = 1), klik “Ubah” dan masukkan nama yang diinginkan.
2. Buat akun penerbitan khusus
Jika administrator "ditinggalkan", ini akan memberikan perlindungan tambahan. Buat akun terpisah untuk memposting artikel dan tautkan semua materi yang diterbitkan sebelumnya dengan cara yang dijelaskan dalam paragraf 1. Selanjutnya, tambahkan informasi dan komunikasikan dengan pembaca hanya dari akun baru.
3. Masukkan kata sandi yang kuat
Ikuti rekomendasi yang diterima secara umum: kata sandi harus minimal 10 karakter, harus unik dan terdiri dari urutan acak huruf besar dan kecil, angka dan karakter khusus.
Dalam hal apa pun Anda tidak boleh:
... buat kata sandi dari frasa yang bermakna
... gunakan data faktual apa pun (tanggal lahir, nama gadis, nomor rekening bank, tahun berjalan ...)
Ini akan menghilangkan risiko pencarian kata sandi menggunakan kamus, dan juga akan secara signifikan meningkatkan waktu yang dibutuhkan untuk kekerasan. Jadi, memecahkan urutan 10 karakter, yang hanya terdiri dari huruf kecil dan angka (hki458p1fa), akan memakan waktu 10 hari waktu komputer untuk satu PC, tetapi jika Anda menambahkan huruf besar dan karakter tambahan (Nv6 $3PZ ~ w1), periode ini akan meningkat hingga 526 tahun, menjamin perlindungan WordPress yang hampir mutlak. Membuat dan mengingat kata sandi ini cukup sulit, terutama jika Anda bertanggung jawab atas beberapa proyek. Oleh karena itu, untuk membuat dan menyimpannya, lebih baik menggunakan manajer khusus, misalnya, KeePassX, didistribusikan secara gratis, atau dokumen uji biasa (lebih baik jika dikemas ke dalam arsip dengan kata sandi).
4. Ubah kata sandi untuk database
Aturan di atas juga berlaku untuk keamanan kode akses MySQL. Lagi pula, di sanalah yang berisi semua konten, serta hash dari frasa rahasia administrator. Jika Anda sudah menggunakan kata sandi yang lemah, ada baiknya bersusah payah untuk mengubahnya. Ini dilakukan sebagai berikut:
1. Buka panel kontrol phpMyAdmin Anda
2. Buka tab "Pengguna" dan pilih pemilik database
3. Klik “Edit Hak Istimewa”
4. Temukan kolom "Ubah kata sandi" dan masukkan urutan rahasia baru di bidang yang sesuai
5. Simpan perubahan dengan mengklik "Ok"
Sekarang yang tersisa hanyalah mengedit wp-config.php, jika tidak, WordPress tidak akan dapat terhubung ke database. Temukan definisi baris ('DB_PASSWORD', 'password'); dan masukkan kata sandi baru alih-alih kata kata sandi. Perhatikan bahwa karena karakter (‘) digunakan untuk membatasi perintah SQL, karakter tersebut tidak boleh digunakan sebagai bagian dari frasa sandi.
5. Perbarui kata sandi secara teratur
Mereka harus diubah setidaknya setiap enam bulan. Perubahan frase kode yang luar biasa harus SELALU dilakukan setelah:
Transfer data untuk otentikasi ke pihak ketiga (pemrogram, administrator sistem, pengoptimal, dan spesialis lainnya, bahkan jika mereka bekerja sebagai staf perusahaan hosting)
... masuk ke sumber daya web dari komputer orang lain (di sebuah pesta, di warnet)
... otorisasi dari peralatan yang dapat disusupi (mesin yang terinfeksi virus)
6. Jangan lupa untuk mengganti kunci rahasia untuk cookie
Mereka berada di file wp-config.php. Ada 8 di antaranya:
| define("AUTH_KEY", "kunci unik"); define("SECURE_AUTH_KEY", "kunci unik"); define("LOGGED_IN_KEY", "kunci unik"); define("NONCE_KEY", "kunci unik"); define("AUTH_SALT", "kunci unik"); define("SECURE_AUTH_SALT", "kunci unik"); define("LOGGED_IN_SALT", "kunci unik"); define("NONCE_SALT", "kunci unik"); |
define("AUTH_KEY", "kunci unik"); define("SECURE_AUTH_KEY", "kunci unik"); define("LOGGED_IN_KEY", "kunci unik"); define("NONCE_KEY", "kunci unik"); define("AUTH_SALT", "kunci unik"); define("SECURE_AUTH_SALT", "kunci unik"); define("LOGGED_IN_SALT", "kunci unik"); define("NONCE_SALT", "kunci unik");
Seperti yang Anda duga dari nama variabel, kunci bertanggung jawab untuk mengenkripsi cookie (bahasa gaul yang terkenal: cookie - cookie, salt - salt, kami memberi makan peretas dengan cookie asin), yang digunakan untuk membuat situs "ingat" komputer Anda setelah otorisasi. Intinya adalah bahwa bahkan jika penyerang mendapatkan hash dari kata sandi admin, dia tidak akan dapat membuat cookie yang diperlukan untuk mengakses situs tanpa frasa rahasia yang terdaftar.
Untuk meningkatkan keamanan, urutan karakter default harus diganti dengan yang unik segera setelah CMS disebarkan. Untuk kenyamanan, pengembang telah membuat generator web yang terletak di www.api.wordpress.org/secret-key/1.1/salt/ - ketika Anda masuk, Anda akan melihat kuncinya, dan jika Anda menyegarkan halaman, kombinasinya diperbarui .
7. Otorisasi ganda untuk area admin
Htaccess memungkinkan Anda untuk lebih mengamankan situs WordPress Anda dengan menambahkan otentikasi tingkat server. Kode akan terlihat seperti ini:
| < Files wp- login. php> # Kami menetapkan jenis otentikasi dasar - ini berarti ketika Anda mencoba# mengakses direktori atau file yang ditentukan akan diminta kata sandi: Jenis Auth dasar # Masukkan teks yang akan ditampilkan di header formulir: AuthName "Identifikasi diri Anda" # Tentukan jalur ke file yang berisi frasa sandi: AuthUserFile "/home/site/.htpasswd" # Kami menunjukkan bahwa ketika mengakses file wp-login.php, Anda harus memasukkan kata sandi: Memerlukan pengguna yang valid # Tolak akses ke file .htpasswd kepada pihak ketiga:< Files . htpasswd>pesan izinkan, tolak tolak dari semua |
# Pilih file skrip otorisasi:
Pada saat yang sama, alangkah baiknya untuk menjaga keamanan htaccess itu sendiri. Sebenarnya, arahan seperti itu harus dijabarkan dalam pengaturan hosting utama, tetapi mengingat kecerobohan beberapa penyedia, Anda harus memainkannya dengan aman:
Ganti nama yang diinginkan alih-alih "login". Tetap menghasilkan kata sandi itu sendiri, serta mengenkripsinya, karena menyimpan data seperti itu dalam teks yang jelas adalah kemewahan yang tidak diizinkan. Ada banyak layanan untuk ini, tetapi lebih baik menulis sendiri skrip yang diperlukan. Ini dilakukan sebagai berikut:
1) Buat file .php di notepad, misalnya crypt.php
2) Masukkan kode di sana, ganti kata sandi Anda alih-alih kata "Kata Sandi":
3) Simpan file dan unggah ke direktori root
4) Ikuti tautan site_name.ru / crypt.php - hash kata sandi akan muncul di layar
5) Simpan nilai ini dalam file .htpasswd dan unggah ke direktori root dan hapus crypt.php
Sentuhan terakhir adalah larangan melihat isi direktori sumber daya web. Cukup menambahkan satu baris ke htaccess:
| Opsi Semua - Indeks |
Opsi Semua -Indeks
Hal ini dilakukan agar peretas tidak dapat mengetahui file mana saja yang ada di direktori proyek. Di banyak situs hosting, arahan ini sudah termasuk dalam pengaturan server, tetapi jika poin ini diabaikan, Anda harus mendaftarkannya sendiri.
8. Instal captcha
Menggunakan captcha akan memungkinkan Anda untuk memotong, jika tidak semua, maka setidaknya sebagian besar bot brute-force, dan pada saat yang sama. Direktori plugin perlindungan situs WordPress menawarkan banyak opsi. Selain menghubungkan solusi kepemilikan dari Google, Captcha oleh BestWebSoft dari jenis campuran (grafik dan teks), yang didasarkan pada operasi matematika, sangat menarik. Independensi layanan, kejelasan, dan tingkat kerumitan yang dapat diterima menjadikan modul ini salah satu yang terbaik.
Kustomisasi bukanlah masalah besar. Tab "Dasar" memungkinkan Anda memilih tempat untuk menampilkan captcha, serta menentukan judul dan simbol untuk menandai bidang yang diperlukan.
Bagian "Lanjutan" menyediakan kemampuan untuk membuat pesan kesalahan Anda sendiri, serta mengaktifkan paket gambar tambahan untuk membuat hidup lebih sulit bagi bot.
Fitur berguna lainnya adalah daftar putih alamat IP bawaan yang captchanya tidak akan ditampilkan.
Hasil dari install dan aktivasi plugin akan muncul form pada halaman otorisasi:
9. Ubah alamat admin
Berbicara tentang cara melindungi situs WordPress, perlu disebutkan cara yang lebih radikal, tetapi juga lebih rumit - mengubah URL halaman login di tingkat skrip. Prosedur ini dilakukan dalam beberapa tahap:
1. Ganti nama file wp-login.php. Gunakan urutan acak huruf kecil Latin, angka, dan tanda hubung. Misalnya: abc-123.php
2. Temukan semua referensi ke wp-login.php di file yang dihasilkan dan ganti dengan nama baru.
3. Agar situs berfungsi dengan benar, penggantian juga harus dilakukan di: wp-activate.php, general-template.php, post-template.php, functions.php, class-wp-customize-manager.php, general -template.php, link-template.php, admin-bar.php, post.php, pluggable.php, ms-functions.php, canonical.php, functions.wp-scripts.php, wp-signup.php, my -sites.php, skema.php, ru_RU.po
Setelah manipulasi ini, panel admin akan ditempatkan di situs / abc-123.php. Akses ke file baru harus dibatasi dan dilindungi kata sandi seperti dijelaskan di atas. Dimungkinkan juga untuk menyesatkan calon peretas dengan membuat file wp-login.php palsu dan mengatur kata sandinya juga.
Opsi yang lebih sederhana adalah menggunakan add-on "Ganti nama wp-login.php". Setelah menginstal plugin untuk melindungi situs, bidang baru akan muncul di menu "Pengaturan" -> "Permalinks":
10. Tentukan IP admin
Keamanan tambahan dapat diberikan jika Anda memiliki alamat IP statis. Menolak akses ke wp-login.php dari komputer mana pun selain komputer Anda sendiri akan membuat hidup lebih sulit bagi peretas:
| < Files wp- login. php>pesan tolak, izinkan tolak dari semua izinkan dari 127.0.0.1, 127.0.02 # Pisahkan alamat IP Anda dengan koma |
11. Nonaktifkan kesalahan otorisasi
Saat memaksa kata sandi, penyerang akan merasa sangat berguna untuk mengetahui bahwa data yang dimasukkan salah. Pesan tersebut ditampilkan pada setiap upaya login yang gagal, dan WordPress juga melaporkan apa yang salah dimasukkan, nama pengguna atau kata sandi. Untuk menghilangkannya, Anda hanya perlu menambahkan satu baris ke functions.php:
| add_filter("login_errors", create_function("$a", "return null;")); |
add_filter("login_errors", create_function("$a", "return null;"));
Untuk melakukan ini, pilih "Tampilan" -> "Editor" -> "Fungsi Tema" di panel admin. Kode harus ditulis setelah tag pembuka
12. Gunakan koneksi yang aman.
Untuk mengenkripsi lalu lintas antara komputer pengguna dan server web, ada protokol https, yang penggunaannya mengecualikan kemungkinan penyadapan data penting, dalam kasus kami, data identifikasi. Untuk mengaktifkannya, Anda harus terlebih dahulu membeli sertifikat SSL yang menjalankan dua fungsi sekaligus: otentikasi sumber daya web dan enkripsi informasi yang dikirimkan. Anda bisa mendapatkannya di pusat khusus, atau dari sejumlah pendaftar nama domain. Untuk tujuan non-komersial, cukup memperoleh sertifikat tingkat awal gratis (seperti yang ditawarkan oleh perusahaan www.startssl.com). Adapun proses instalasi, sebagai aturan, dijelaskan secara rinci di bagian bantuan hoster.
Setelah menerima sertifikat SSL, Anda perlu mengonfigurasi pengalihan bagian administratif sumber daya web ke koneksi yang aman. Dalam kasus WordPress, ini dilakukan dengan menggunakan konstruksi berikut:
| < IfModule mod_rewrite. c>Opsi + FollowSymlinks RewriteEngine On RewriteCond% (HTTPS) = mati RewriteCond% (REQUEST_URI) = / wp- login. php RewriteRule (. *) https: |
Anda juga dapat memaksa penggunaan sertifikat SSL di tingkat mesin. Untuk melakukan ini, buka file wp-config.php dan tambahkan setelahnya
| tentukan ("FORCE_SSL_ADMIN", benar); |
tentukan ("FORCE_SSL_ADMIN", benar);
Selain itu, Anda dapat mengatur pengalihan global dari http ke https. Untuk situs baru, pendekatan ini optimal, mengingat Google mendorong proyek yang aman, dengan memberikan beberapa prioritas dalam hasil pencarian:
| < IfModule mod_rewrite. c>Pilihan + FollowSymlinks RewriteEngine pada RewriteCond% (HTTPS) = mati RewriteRule ^ (. *) $ Https: //% (HTTP_HOST)% (REQUEST_URI) |
13. Blokir penyusup
Jika aktivitas mencurigakan dari IP tertentu terdeteksi, ada baiknya memblokir akses mereka ke situs. Ini dilakukan dengan analogi dengan metode sebelumnya. Perbedaannya adalah bahwa arahan ditulis untuk proyek secara keseluruhan, dan kami mencantumkan alamat mereka yang ingin kami blokir:
Pesan Izinkan, Tolak Izinkan dari semua Tolak dari 127.0.0.1, 127.0.02 # Tentukan IP yang tidak diinginkan
Metode ini dapat diandalkan tetapi tidak efektif. Pertama, entah bagaimana perlu untuk mencatat permintaan layanan brute-forcing dan memisahkannya dari pengunjung terhormat. Kedua, dengan serangan besar-besaran, Anda tidak akan dapat melacak dan mengarahkan IP peretas dan bot secara manual. Metode ini hanya bagus jika administrator memiliki daftar alamat yang dapat diandalkan.
Jika tidak, Anda dapat menggunakan plugin keamanan situs WordPress bernama WP Cerber. Solusi ini benar-benar gratis, sambil menawarkan seperangkat alat yang sangat mengesankan yang dirancang untuk mencegah peretasan CMS. Anda dapat menginstalnya langsung dari panel admin.
Secara default, parameter yang cukup masuk akal ditawarkan. Namun, jumlah upaya harus ditingkatkan menjadi 5 untuk menghindari kesalahpahaman.
Kotak centang di seberang "Block IP for any wp-login.php request" harus dicentang jika Anda mengubah alamat admin dengan cara yang dijelaskan sebelumnya.
Untuk tujuan ini, Anda juga dapat menggunakan alat WP Cerber sendiri:
Mode plugin untuk melindungi situs Citadel juga tidak memerlukan konfigurasi tambahan. Ini dirancang untuk "mengampuni" proyek selama serangan brute-force besar-besaran. Lebih baik hapus centang pada kotak di sebelah "Rekam upaya untuk masuk ke file" - ini akan membantu menghilangkan beban tambahan di server.
Tab "Daftar Akses" digunakan untuk membuat daftar IP "hitam" dan "putih" (jika Anda memiliki alamat statis, pastikan untuk menambahkannya ke daftar yang tepercaya), dan bagian "Alat" memungkinkan Anda untuk impor dan ekspor pengaturan yang dibuat sebelumnya. Namun, kemungkinan ini tidak memerlukan pertimbangan tersendiri.
14. Pindahkan file konfigurasi
Seperti yang kami temukan di atas, wp-config.php menyimpan data penting seperti login dan kata sandi untuk mengakses MySQL, serta kunci API. Langkah selanjutnya tampaknya sudah jelas - melindungi WordPress melalui htaccess dengan membatasi akses ke file:
| < Files wp- config. php>Pesan izinkan, tolak Tolak dari semua |
Namun, ada juga metode yang lebih dapat diandalkan. WordPress memiliki fitur yang sangat menarik yang hanya sedikit orang yang tahu. Mesin memungkinkan menempatkan file konfigurasi satu tingkat di atas direktori root.. php dapat dipindahkan ke direktori situs. Dalam hal ini, file akan sepenuhnya tidak dapat diakses melalui Internet, sementara informasi yang terkandung di dalamnya akan tetap dibaca oleh CMS.
15. Tambahkan cek REFERER
Metode yang terbukti baik untuk melindungi WordPress dari spam juga akan membantu saat menghadapi serangan brute force. Lagi pula, pemaksaan kata sandi yang kasar sama sekali bukan pekerjaan manual: program khusus digunakan untuk tujuan ini. Ini berarti bahwa dengan mengaktifkan pemeriksaan header dalam permintaan yang masuk, Anda dapat memotong bot yang datang entah dari mana dengan HTTP REFERER kosong:
| < IfModule mod_rewrite. c>RewriteEngine Pada RewriteCond% (REQUEST_METHOD) POST RewriteCond% (REQUEST_URI). (wp- komentar- posting | wp- login) \. php * RewriteCond% (HTTP_REFERER)!. * tekseo. su.* [ATAU] RewriteCond% (HTTP_USER_AGENT) ^ $ RewriteRule (. *) http: //% (REMOTE_ADDR) / $1 |
16. Lindungi XML-RPC
Sejak versi 3.5, kemampuan untuk menonaktifkan protokol panggilan prosedur jarak jauh XML-RPC telah menghilang dari WordPress. Pada dasarnya, diperlukan untuk berinteraksi dengan aplikasi seluler, tetapi tidak semua orang membutuhkan fungsionalitas seperti itu. Pada saat yang sama, xmlrpc.php secara aktif digunakan untuk melakukan serangan DDoS, menjadi kelemahan dari keseluruhan proyek.
Selain itu, peretas telah berpikir untuk menggunakan XML-RPC untuk brute force. Menggunakan metode wp.getUsersBlogs memungkinkan Anda untuk mengulangi kredensial jauh lebih cepat daripada menggunakan formulir admin. Karena banyak panggilan XML-RPC memerlukan otorisasi, permintaan seperti ini:
| < methodCall> < methodName>wp. getUsersBlogs < params>< param>< value>< string>admin < param>< value>< string> 12345 |
akan menyebabkan mesin memberi tahu Anda apakah kombinasi yang dilewati sudah benar. Untuk menghilangkan momok ini, Anda harus menonaktifkan protokol sepenuhnya. Ini dapat dilakukan dalam beberapa metode:
1) Dengan memblokir akses ke file xmlrpc.php melalui htaccess
require_once (ABSPATH. "wp-settings.php");
perlu mendaftar
function remove_x_pingback ($ headers) (unset ($ headers ["X-Pingback"]); return $ headers;) add_filter ("wp_headers", "remove_x_pingback");
4) Menggunakan plugin penerbitan Kontrol XML-RPC mengembalikan opsi yang sesuai di Pengaturan -> Menulis:
Harap dicatat: add-on menonaktifkan protokol segera setelah aktivasi, dan dalam pengaturan Anda dapat mengaktifkannya dengan mencentang kotak yang sesuai.
17. Pantau serangan brute force
Terakhir, perlu disebutkan plugin yang menarik untuk mencatat upaya peretasan - Otentikasi dan penulis log xmlrpc. Meskipun WP Cerber yang sama memiliki alat pemantauan bawaan, modul ini akan tetap berguna, terutama bagi mereka yang membutuhkan kemampuan protokol yang dijelaskan di atas. AX LogWriter mampu melacak kekerasan melalui xmlrpc.php, sehingga Anda dapat menilai tingkat ancaman dan kelayakan untuk sepenuhnya menolak menggunakan kemampuannya. Akhirnya, bagi mereka yang sama sekali tidak terlibat dalam keamanan proyek mereka, plugin untuk melindungi situs akan membuka mata mereka tentang pentingnya aktivitas yang terdaftar.
Menggunakan AX LogWriter sangatlah mudah. Setelah instalasi, bagian yang sesuai akan muncul di menu admin, di mana Anda dapat membuat semua perubahan yang diperlukan:
Di bidang "Jenis Kesalahan", pilih metode penyimpanan. Mendukung penulisan ke log sistem, log server Apache, serta kemampuan untuk membuat file khusus. Dalam kasus terakhir, ini juga dapat dikonfigurasi dengan Nama Log Kesalahan Kustom dan Jalur Log Kesalahan Kustom. Ini membuka kemungkinan yang luas bagi administrator sistem - misalnya, solusinya dapat digunakan bersama dengan fail2ban. Juga, jangan lupa untuk memilih zona waktu yang sesuai di kolom Zona Waktu.
Log kustom dapat dilihat langsung dari panel admin pada halaman Custom Log Viewer:
Mari kita rangkum:
Metode yang tercantum akan membantu meningkatkan keamanan sumber daya Anda secara signifikan dan melindunginya dari bot-brute-forcing, hooligan jaringan, dan berlatih scriptkiddis. Namun, semua yang dijelaskan di atas hanyalah puncak gunung es. Para penyerang memiliki metode yang jauh lebih canggih di gudang senjata mereka. Dan di artikel selanjutnya kita akan membahas tentang cara melindungi diri dari peretas sejati menggunakan berbagai kerentanan mesin dan perangkat lunak server. Seperti dalam materi ini, selain "aturan kebersihan" umum, pengaturan CMS utama akan dipertimbangkan, cara memodifikasi kode, serta plugin yang paling relevan.
Dalam hal keamanan aplikasi, penting untuk memperhatikan tidak hanya perangkat keras dan sistem operasi, tetapi juga penulisan skrip yang aman. Dalam artikel ini, Anda akan mempelajari cara menjaga aplikasi Anda tetap aman dan tidak terlalu rentan. Di bawah ini adalah daftar langkah-langkah untuk membantu Anda melindungi aplikasi Anda dari semua jenis serangan:
- Validasi data masuk
- Perlindungan terhadap serangan XSS
- Perlindungan terhadap serangan CSRF
- Mencegah Injeksi SQL
- Perlindungan sistem file
- Perlindungan data sesi
- Pemrosesan kesalahan
- Melindungi File yang Disertakan
Validasi data masuk
Saat mendesain aplikasi Anda, Anda perlu berusaha keras untuk melindunginya dari data masuk yang "buruk". Aturan yang harus diikuti adalah sesuatu seperti: "Jangan pernah percaya apa yang telah dimasukkan pengguna." Meskipun sebagian besar pengguna bukanlah ancaman, selalu ada kemungkinan seseorang ingin meretas situs Anda menggunakan data "buruk" yang dimasukkan melalui formulir atau bilah alamat. Jika Anda selalu memvalidasi dan memfilter data yang masuk, maka Anda memiliki peluang bagus untuk menulis aplikasi yang aman.
Selalu periksa data Anda dalam skrip PHP. Jika Anda menggunakan JavaScript untuk memvalidasi data, penyerang dapat menonaktifkannya di browsernya kapan saja. Dalam hal ini, aplikasi Anda berisiko. Tidak ada yang menentang validasi JavaScript, tetapi untuk perlindungan yang baik, Anda perlu memeriksa ulang data dalam skrip PHP.
Perlindungan terhadap serangan XSS
Skrip lintas situs atau serangan XSS adalah serangan yang didasarkan pada penyuntikan kode ke halaman yang berpotensi rentan. Bahayanya adalah kode berbahaya dapat dimasukkan melalui formulir dan kemudian ditampilkan di browser.
Misalkan situs Anda memiliki formulir untuk memasukkan komentar, yang segera ditampilkan setelah ditambahkan. Penyerang dapat memasukkan komentar yang berisi kode JavaScript. Setelah mengirimkan formulir, data dikirim ke server dan dimasukkan ke dalam database. Setelah itu, data diambil dari database dan komentar baru ditampilkan di halaman HTML, termasuk kode JavaScript yang disematkan. Itu dapat mengarahkan pengguna ke beberapa halaman berbahaya atau situs phishing.
Untuk melindungi aplikasi Anda, jalankan data yang masuk melalui fungsi strip_tags (), yang akan menghapus semua tag yang ada. Saat menampilkan data di browser, gunakan fungsi htmlentities().
Perlindungan terhadap serangan CSRF
Jenis serangan berikutnya yang akan kita lihat adalah serangan CSRF atau pemalsuan permintaan lintas situs. Penyerang menggunakan berbagai trik untuk mendapatkan informasi rahasia atau membuat kesepakatan tanpa sepengetahuan korban. Ini terutama terjadi di situs yang tidak terlindungi dengan baik, di mana logika bisnis didasarkan pada pekerjaan permintaan GET.
Secara umum, permintaan GET bersifat idempoten. Idempotensi, dalam konteks ini, berarti bahwa satu halaman yang sama dapat diakses beberapa kali tanpa campur tangan pihak luar. Itulah sebabnya permintaan GET harus digunakan hanya untuk mendapatkan akses ke informasi, tetapi tidak untuk melakukan berbagai jenis transaksi.
Contoh sederhana berikut menunjukkan bagaimana situs yang tidak aman dapat terkena serangan CSRF:
Misalkan Bob ingin melakukan serangan CSRF pada Alice. Dia membentuk alamat url khusus dan mengirimkannya ke Alice melalui email:
Kunjungi situs web saya!
Jika Alice diotorisasi di situs web example.com dan mengikuti tautan ini, maka $ 1000 akan ditransfer dari akunnya ke akun Bob. Atau, Bob juga dapat mengirim gambar dan mengisi URL "buruk" di atribut src.
Browser tidak akan dapat menampilkan gambar ini, karena tidak ada, tetapi permintaan akan dibuat tanpa sepengetahuan dan partisipasi Alice.
Untuk mencegah serangan semacam ini, gunakan hanya permintaan POST ke proses yang dirancang untuk mengubah informasi dalam database. Jangan gunakan $ _REQUEST. Gunakan $ _GET untuk menangani parameter GET, dan $ _POST untuk mengambil parameter POST.
Sebagai tindakan tambahan, Anda dapat membuat token unik dan melampirkannya ke setiap permintaan POST. Saat pengguna masuk ke sistem, Anda dapat membuat token acak dan menulisnya ke sesi. Karena semua formulir ditampilkan kepada pengguna, token ini harus ditulis ke bidang tersembunyi. Logika bisnis aplikasi harus menyediakan fungsionalitas yang akan memeriksa token dari formulir dan token yang disimpan dalam sesi.
Mencegah Injeksi SQL
Anda harus menggunakan PDO untuk menjalankan kueri terhadap database. Dengan kueri berparameter dan pernyataan yang disiapkan, Anda dapat mengurangi ancaman injeksi SQL.
Mari kita lihat contoh berikut:
Dalam kode di atas, kami mengirim permintaan ke metode persiapan (), termasuk parameter bernama:: nama dan: usia. Dengan demikian, kueri telah dikompilasi sebelumnya untuk substitusi data lebih lanjut. Ketika metode eksekusi () dipanggil, permintaan sepenuhnya terbentuk dan dieksekusi. Jika Anda menggunakan teknik ini, maka semua upaya penyerang untuk melakukan injeksi SQL akan dibatalkan.
Perlindungan sistem file
Sebagai pengembang yang bertanggung jawab, Anda harus selalu menulis kode yang tidak membahayakan sistem file Anda. Mari kita lihat kode yang mengirimkan file untuk diunduh tergantung pada data yang dikirimkan oleh pengguna.
Skrip ini sangat berbahaya, karena memungkinkan untuk mengakses direktori apa pun yang dapat diakses dari file dengan skrip: direktori dengan sesi, folder sistem, dan banyak lagi.
Perlindungan data sesi
Secara default, semua informasi sesi ditulis ke direktori temp. Jika Anda menggunakan shared hosting, seseorang selain Anda dapat menulis skrip dan membaca data sesi. Karena itu, berhati-hatilah menyimpan kata sandi atau nomor kartu kredit dalam sesi.
Jika Anda masih perlu menyimpan data tersebut dalam satu sesi, maka enkripsi adalah ukuran terbaik. Ini tidak sepenuhnya menyelesaikan masalah, karena data terenkripsi tidak 100% aman, tetapi informasi yang disimpan tidak akan dapat dibaca. Juga, Anda harus mempertimbangkan bahwa data sesi dapat disimpan di tempat lain, seperti database. PHP memiliki metode session_set_save_handler() khusus yang memungkinkan Anda menyimpan data sesi dengan cara Anda sendiri.
Sejak PHP 5.4, Anda dapat meneruskan objek bertipe SessionHandlerInterface ke session_set_save_handler ().
Pemrosesan kesalahan
Selama pengembangan aplikasi, ada baiknya memperhatikan semua jenis kesalahan yang mungkin muncul, namun, mereka harus disembunyikan dari pengguna akhir. Jika kesalahan ditampilkan kepada pengguna, maka ini membuat situs Anda rentan. Dengan demikian, solusi terbaik adalah konfigurasi yang berbeda untuk server target dan server pengembangan.
Di server publik, Anda perlu menonaktifkan opsi seperti display_errors dan display_start_up_errors, tetapi opsi seperti error_reporting dan log_errors harus aktif sehingga semua kesalahan yang ditemui pengguna dicatat.
Anda juga dapat menggunakan set_error_handler untuk mendefinisikan penangan kesalahan Anda sendiri. Namun, mungkin ada batasan, karena handler asli lebih rendah daripada mekanisme PHP asli. Kesalahan E_CORE_ERROR, E_STRICT, atau E_COMPILER_ERROR tidak dapat ditangkap dalam file yang sama sebagai penangan tertentu. Selain itu, kesalahan yang mungkin terjadi pada pawang itu sendiri juga tidak dapat ditangkap.
Untuk cara yang lebih elegan dalam menangkap pengecualian, kode yang berpotensi berbahaya harus ditempatkan di blok coba/tangkap. Semua pengecualian asli harus menjadi objek kelas atau subkelas Pengecualian. Jika pengecualian dilemparkan, maka pengecualian tersebut dapat ditangani di blok try/catch.
Melindungi File yang Disertakan
Seringkali, file lain dimuat dalam skrip PHP, seperti menghubungkan ke database dan banyak lainnya. Beberapa pengembang memberikan file ini ekstensi .inc. PHP tidak mengurai file seperti itu secara default. Jika Anda mengatasinya secara langsung, pengguna akan dapat melihat teks file ini. Jika hacker berhasil mendapatkan akses ke file yang menyimpan koneksi data ke database, maka nanti dia bisa mendapatkan akses ke semua data aplikasi Anda. Jadi selalu gunakan ekstensi .php untuk file yang diunggah dan simpan di tempat yang tidak dapat diakses langsung oleh pengguna.
Hasil
Jika Anda mengikuti 8 aturan yang tercantum, maka ini akan sangat meningkatkan ketahanan aplikasi Anda terhadap berbagai jenis serangan. Jangan percaya data yang dimasukkan oleh pengguna, lindungi file dan database Anda.
Mari kita pikirkan siapa hacker itu? Seorang hacker bukanlah seorang cracker! Orang sering mengacaukan konsep-konsep ini. Seorang hacker, pertama-tama, adalah orang dengan pemikiran out-of-the-box, dan ini adalah kekuatannya, bisa dikatakan.
Agar berhasil melawan peretas, Anda juga perlu belajar berpikir di luar kotak. Seperti yang mereka katakan, baji dihancurkan oleh baji.
Hari ini saya akan menawarkan cara yang sangat tidak biasa untuk melindungi diri Anda dari serangan seperti php include. Tentu saja, dia tidak cocok untuk semua orang. Dan jika jujur dia melindungi bukan dari serangan itu sendiri, tetapi dari deteksinya. Tertarik?
Bagaimana menemukan termasuk ...
Pertama-tama mari kita pahami dengan tepat bagaimana penyerang mencoba menemukan kerentanan.
Ini terlihat seperti ini. Penyerang memodifikasi semua parameter yang masuk satu per satu, dengan asumsi bahwa data parameter ini masuk ke fungsi include. Nah, atau jika, dengan cara sederhana, ia mencoba untuk "melampirkan" file. Dan untuk menentukan apakah ada kerentanan atau tidak, dia perlu memasukkan beberapa file ke sistem target (jika dia tahu - ada kerentanan, tidak - tidak ada kerentanan).
Secara alami, jika penyerang bertindak dari luar, maka dia tidak tahu struktur lokasi direktori dan file, dan tidak dapat melampirkan file apa pun, karena dia tidak akan tahu jalurnya. Tetapi ada file yang selalu ada di sistem, dan yang selalu memiliki izin baca. Untuk Linux, ini adalah /etc/passwd, dan untuk Windows, biarkan menjadi C:\boot.ini. Tapi omong-omong, Windows kurang menarik bagi kami, jadi selanjutnya kami akan berbicara tentang passwd
/ etc / passwd
Mungkin Anda telah menemukan lebih banyak catatan formulir di log Anda:
Tindakan = .. / etc / passwd% 00
? tindakan = .. / .. / etc / passwd% 00
? tindakan = .. / .. / .. / etc / passwd% 00
? action = .. / .. / .. / .. / etc / passwd% 00
? action = .. / .. / .. / .. / .. / etc / passwd% 00
? lakukan = .. / etc / passwd% 00
? do = .. / .. / etc / passwd% 00
? do = .. / .. / .. / etc / passwd% 00
? do = .. / .. / .. / .. / etc / passwd% 00
? do = .. / .. / .. / .. / .. / etc / passwd% 00
?id = .. / etc / passwd% 00
?id = .. / .. / etc / passwd% 00
?id = .. / .. / .. / etc / passwd% 00
?id = .. / .. / .. / .. / etc / passwd% 00
?id = .. / .. / .. / .. / .. / etc / passwd% 00
Jika ya, maka Anda harus tahu bahwa Anda mencoba menemukan php include (baik, atau kemampuan untuk membaca file arbitrer, tetapi kami tidak tertarik dengan ini sekarang). Jadi, jika salah satu parameter Anda tidak diproses dengan benar dan berakhir di suatu fungsi termasuk (), maka file / etc / passwd akan ditambahkan, isinya akan ditafsirkan sebagai skrip php, dan karena tidak mengandung tag kode php, maka akan ditampilkan di browser tidak berubah. Ini akan berfungsi sebagai "penanda" bagi penyerang untuk memiliki kerentanan.
Mengapa saya menulis ini, karena ketika mencari sertakan, penyerang pasti (saya jamin dalam 90% kasus) akan mencoba menambahkan file / etc / passwd.
Lindungi diri Anda, Pak!
Mungkin Anda sekarang berpikir: "Apakah dia ingin menawarkan paket WAF dan filter biasa dengan adanya /etc/passwd di dalamnya?" Tidak. Ini adalah cara standar. Ini adalah contoh bagaimana orang biasa berpikir.
Mari kita sedikit kreatif. Mengapa kita tidak menambahkan beberapa kode php ke isi file passwd? Dan jika tiba-tiba penyerang berhasil menghubungkannya, maka kode php kita akan dieksekusi. (Apakah Anda menganggapnya tidak masuk akal? - lihat kesimpulannya)
Karena kita tahu bahwa satu-satunya yang akan menebak untuk memasukkan file ini adalah cracker, kode php kita harus melarangnya, dan untuk mencegah sistem kita diretas lebih lanjut, blokir file yang rentan, dan sebaiknya beri tahu administrator tentang kejadian itu.
Tetapi bagaimana Anda menambahkan kode php ke /etc/passwd karena sintaksnya diatur secara ketat? Setiap pengguna memiliki bidang "komentar" - deskripsi pengguna, Anda dapat memasukkan apa pun yang Anda inginkan di sana (kecuali titik dua, tentu saja). Oleh karena itu, kami mengambil dan menambahkan pengguna ke sistem dengan komentar yang kami butuhkan. Setelah itu, /etc/passwd akan berisi baris berikut
root: x: 0: 0: Pengguna super: /:
daemon: *: 1: 5 :: /: / sbin / sh
bin: *: 2: 2 :: / usr / bin: / sbin / sh
sys: *: 3: 3 :: /:
adm: *: 4: 4 :: / var / adm: / sbin / sh
pengguna keamanan: *: 1001: 1001::/:
Nah, dalam skrip plug-in, kami sudah melakukan tindakan yang Anda butuhkan - blokir pengguna, blokir permintaan, beri tahu administrator.
Akibatnya, kami memiliki semacam jebakan yang dapat melindungi situs Anda dari peretasan.
Kesimpulan
Ya, saya sepenuhnya menyadari bahwa semua yang tertulis di atas tampak seperti omong kosong. Dan saya sangat mengerti bahwa tidak ada yang akan menggunakan ini dalam praktik. Tapi bukan untuk itu saya menulis. Saya menulis untuk menunjukkan contoh pendekatan non-standar di bidang perlindungan.
Terima kasih atas perhatiannya =)
