Waspada: Fungsi PHP dan WordPress yang Dapat Membuat Situs Anda Tidak Aman

Keamanan situs web WordPress (atau apa pun) adalah masalah multi-segi. Langkah terpenting yang dapat dilakukan siapa pun untuk memastikan bahwa situs aman adalah dengan mengingat bahwa tidak ada proses atau metode tunggal yang cukup untuk memastikan tidak ada hal buruk yang terjadi. Tetapi ada hal-hal yang dapat Anda lakukan untuk membantu. Salah satunya adalah waspada, dalam kode yang Anda tulis dan kode dari orang lain yang Anda terapkan, untuk fungsi yang dapat memiliki konsekuensi negatif. Dalam artikel ini, kami akan membahasnya secara tepat: fungsi yang harus dipikirkan dengan jelas oleh pengembang WordPress sebelum menggunakannya.

WordPress sendiri menyediakan perpustakaan fungsi yang cukup besar, beberapa di antaranya bisa berbahaya. Di luar itu, ada banyak sekali fungsi PHP yang akan digunakan oleh developer WordPress (PHP) dengan frekuensi tertentu yang bisa berbahaya saat digunakan.

Semua fungsi ini memiliki kegunaan yang sah dan aman, tetapi juga fungsi yang dapat memudahkan kode Anda disalahgunakan untuk tujuan yang buruk. Kami akan membahas hal-hal yang paling mungkin menjadi penyebab kerentanan keamanan, dan mengapa Anda harus memperhatikannya. Pertama-tama kita akan menjalankan fungsi PHP dalam kode Anda yang dapat digunakan oleh aktor jahat untuk kejahatan, dan kemudian berbicara tentang fungsi PHP khusus WordPress yang juga dapat menyebabkan sakit kepala.

Fungsi PHP Yang Harus Diwaspadai

Seperti yang kami katakan, PHP berisi banyak fungsi yang mudah digunakan. Beberapa dari fungsi tersebut terkenal karena kemudahannya untuk melakukan hal-hal buruk dengannya. Semua fungsi ini memiliki penggunaan yang tepat, tetapi berhati-hatilah tentang cara Anda menggunakannya dan bagaimana kode lain yang Anda tarik ke dalam sebuah proyek.

Kami akan menganggap Anda sudah mendapatkan kutipan ajaib dan daftar global dimatikan jika versi PHP Anda mendukungnya. Mereka dimatikan secara default di PHP 5 dan lebih tinggi, tetapi dapat diaktifkan untuk versi di bawah 5.4. Beberapa host mengizinkannya, tapi menurut saya artikel keamanan PHP tidak akan lengkap tanpa menyertakannya.

Atau disebutkan bahwa PHP 5.6 adalah versi 5.x terakhir yang masih dengan dukungan keamanan berkelanjutan. Anda harus berada di atasnya, setidaknya. Dan Anda harus memiliki rencana untuk beralih ke PHP 7 sebelum dukungan 5.6 berakhir pada akhir 2018.

Setelah itu, Anda hanya akan memiliki beberapa fungsi berisiko untuk ditangani. Dimulai dengan…

extract Apakah Berita Buruk, Terutama Pada $_POST Atau Serupa

Untungnya, penggunaan fungsi extract PHP sebagian besar tidak disukai. Inti dari penggunaannya adalah Anda dapat menjalankannya pada larik data, dan pasangan nilai kuncinya akan menjadi variabel hidup dalam kode Anda. Jadi

 $arr = array( 'red' => 5 ); extract($arr); echo $red; // 5

akan bekerja. Ini keren, tetapi juga sangat berbahaya jika Anda mengekstrak $_GET , $_POST , dll. Dalam kasus tersebut, pada dasarnya Anda membuat ulang sendiri masalah register_globals : penyerang luar dapat mengubah nilai variabel Anda dengan mudah dengan menambahkan string kueri atau bidang formulir. Solusi terbaiknya sederhana: jangan gunakan extract .

Jika Anda membuat larik yang Anda ekstrak sendiri, penggunaan extract , bukanlah masalah keamanan khusus, dan dalam beberapa kasus, ini bisa berguna. Tetapi semua penggunaannya memiliki masalah membingungkan pembaca masa depan. Membuat array dan memanggil extract lebih membingungkan daripada hanya mendeklarasikan variabel Anda. Jadi saya mendorong Anda untuk melakukan deklarasi manual sebagai gantinya, kecuali jika itu benar-benar tidak layak.

Jika Anda harus menggunakan extract pada input pengguna, Anda harus selalu menggunakan flag EXTR_SKIP . Ini masih memiliki masalah kebingungan, tetapi menghilangkan kemungkinan bahwa nilai preset Anda dapat diubah oleh orang luar yang jahat melalui string kueri sederhana atau modifikasi formulir web. (Karena "melompat" sudah menetapkan nilai.)

“ eval Is Evil” Karena Kode Sewenang-wenang Itu Menakutkan

eval di PHP dan hampir semua bahasa lain yang membawanya selalu berada di urutan teratas dalam daftar seperti ini. Dan untuk alasan yang bagus. Dokumentasi resmi PHP di PHP.net mengatakannya dengan jujur:

PERHATIAN : Konstruksi bahasa eval() sangat berbahaya karena memungkinkan eksekusi kode PHP arbitrer. Oleh karena itu, penggunaannya tidak disarankan. Jika Anda telah dengan hati-hati memverifikasi bahwa tidak ada pilihan lain selain menggunakan konstruksi ini, berikan perhatian khusus untuk tidak meneruskan data yang diberikan pengguna ke dalamnya tanpa memvalidasinya dengan benar sebelumnya.

eval memungkinkan string arbitrer apa pun dalam program Anda dijalankan seolah-olah itu adalah kode PHP. Itu berarti berguna untuk "pemrograman meta" di mana Anda sedang membangun sebuah program yang dapat dengan sendirinya membangun sebuah program. Ini juga sangat berbahaya karena jika Anda pernah mengizinkan sumber arbitrer (seperti kotak teks pada halaman web) untuk segera diteruskan ke evaluator string eval Anda, Anda tiba-tiba membuatnya mudah bagi penyerang jahat untuk melakukan hampir semua hal yang dapat dilakukan PHP lakukan di server Anda. Ini termasuk, tentu saja, menghubungkan ke database, menghapus file, dan hampir semua hal lain yang dapat dilakukan seseorang ketika SSH dimasukkan ke dalam mesin. Ini buruk.

Jika Anda harus menggunakan eval dalam program Anda, Anda harus berusaha keras untuk memastikan bahwa Anda tidak mengizinkan input pengguna yang sewenang-wenang diteruskan ke dalamnya. Dan jika Anda harus mengizinkan pengguna sewenang-wenang mengakses input ke eval , batasi apa yang dapat mereka lakukan melalui daftar hitam perintah yang tidak boleh Anda jalankan, atau (lebih baik, tetapi jauh lebih sulit untuk diterapkan) daftar putih yang hanya merupakan perintah yang Anda anggap aman. Lebih baik lagi, hanya izinkan sejumlah kecil perubahan parameter tertentu, seperti hanya bilangan bulat yang divalidasi.

Tapi selalu ingat baris ini dari Rasmus Lerdorf, pendiri PHP:

"Jika `eval()` adalah jawabannya, Anda hampir pasti mengajukan pertanyaan yang salah."

Variasi Pada eval

Ada, selain eval yang terkenal, berbagai cara lain yang secara historis didukung oleh PHP string-evaluated-as code. Dua yang paling relevan untuk pengembang WordPress adalah preg_replace dengan /e modifier, dan create_function . Masing-masing bekerja sedikit berbeda, dan preg_replace setelah PHP 5.5.0 tidak berfungsi sama sekali. (PHP 5.5 dan di bawahnya tidak lagi mendapatkan pembaruan keamanan resmi, dan karenanya sebaiknya tidak digunakan.)

/e Pengubah Dalam Regex Juga "Jahat"

Jika Anda menjalankan PHP 5.4.x atau lebih rendah, Anda harus memperhatikan panggilan preg_replace PHP yang diakhiri dengan e. Itu bisa terlihat seperti:

 $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );)

PHP menawarkan berbagai cara untuk "memangari" dalam ekspresi reguler Anda, tetapi hal inti yang ingin Anda perhatikan adalah "e" sebagai karakter terakhir dari argumen pertama preg_replace . Jika ada, Anda sebenarnya meneruskan seluruh segmen yang ditemukan sebagai argumen ke PHP sebaris Anda, dan kemudian eval . Ini memiliki masalah yang sama persis dengan eval jika Anda membiarkan input pengguna masuk ke fungsi Anda. Kode contoh dapat diganti dengan menggunakan preg_replace_callback . Keuntungannya adalah Anda telah menuliskan fungsi Anda, jadi lebih sulit bagi penyerang untuk mengubah apa yang dievaluasi. Jadi Anda akan menulis di atas sebagai:

 // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html );

Membiarkan Input Pengguna create_function s Juga Buruk…

PHP juga memiliki fungsi create_function . Ini sekarang tidak digunakan lagi di PHP 7.2, tetapi sangat mirip dengan eval dan memiliki kelemahan dasar yang sama: memungkinkan string (argumen kedua) diubah menjadi PHP yang dapat dieksekusi. Dan itu memiliki risiko yang sama: terlalu mudah bagi Anda untuk secara tidak sengaja memberikan cracker pintar kemampuan untuk melakukan apa pun di server Anda jika Anda tidak berhati-hati.

Yang ini, jika Anda menggunakan PHP di atas 5.3, bahkan lebih mudah diperbaiki daripada preg_replace . Anda bisa membuat fungsi anonim Anda sendiri tanpa menggunakan string sebagai perantara. Ini lebih aman dan lebih mudah dibaca, setidaknya di mata saya.

assert Juga eval -Seperti

assert bukan fungsi yang saya lihat banyak digunakan pengembang PHP, di WordPress atau di luarnya. Tujuannya adalah untuk pernyataan yang sangat ringan tentang prasyarat untuk kode Anda. Tapi itu, juga, mendukung operasi eval -type. Karena alasan itu, Anda harus waspada terhadapnya seperti halnya Anda terhadap eval . Pernyataan berbasis string (jantung mengapa hal ini buruk) juga tidak digunakan lagi di PHP 7.2, yang berarti hal ini seharusnya tidak terlalu menjadi perhatian di masa mendatang.

Menyertakan File Variabel Adalah Cara Yang Memungkinkan Eksekusi PHP yang Tidak Terkendali

Kami telah menyelidiki dengan baik mengapa eval buruk, tetapi sesuatu seperti include atau require($filename'.php') dapat, terutama jika $filename diatur dari nilai yang dapat dikontrol pengguna, menjadi berita buruk yang sama. Alasannya agak berbeda dari eval . Nama file variabel sering digunakan untuk hal-hal seperti perutean URL-ke-file sederhana di aplikasi PHP non-WordPress. Tetapi Anda mungkin melihatnya digunakan di WordPress juga.

Inti masalah bahwa ketika Anda include atau require (atau include_once atau require_once ) Anda membuat skrip Anda mengeksekusi file yang disertakan. Ini, kurang lebih, secara konseptual eval file itu, meskipun kita jarang berpikir seperti itu.

Jika Anda telah menulis semua file yang mungkin include oleh variabel Anda, dan telah mempertimbangkan apa yang akan terjadi ketika itu terjadi, Anda baik-baik saja. Tapi itu berita buruk jika Anda tidak mempertimbangkan apa yang akan dilakukan dengan include password.php atau wp-config.php . Ini juga merupakan berita buruk jika seseorang dapat menambahkan file berbahaya dan kemudian menjalankan penyertaan Anda (walaupun pada saat itu Anda mungkin include masalah yang lebih besar).

Solusi untuk ini tidak terlalu sulit: hard-code termasuk jika Anda bisa. Jika Anda tidak bisa, buat daftar putih (lebih baik) atau daftar hitam file yang dapat disertakan. Jika file dalam daftar putih (yaitu: Anda telah mengaudit apa yang dilakukannya saat ditambahkan), Anda akan tahu bahwa Anda aman. Jika tidak ada dalam daftar putih Anda, skrip Anda tidak akan menyertakannya. Dengan tweak sederhana itu, Anda cukup aman. Daftar putih akan terlihat seperti ini:

 $white_list = ['db.php', filter.php', 'condense.php'] If (in_array($white_list, $file_to_include)) { include($file_to_include); }

Jangan Pernah Melewati Input Pengguna Ke shell_exec Dan Varian

Ini adalah salah satu yang besar. shell_exec , system , exec , dan backticks di PHP semuanya mengizinkan kode yang Anda jalankan untuk berbicara dengan shell yang mendasarinya (biasanya Unix). Ini mirip dengan apa yang membuat eval berbahaya tetapi berlipat ganda. Berlipat ganda karena jika Anda membiarkan input pengguna lewat sini dengan sembarangan, penyerang bahkan tidak terikat oleh batasan PHP.

Kemampuan untuk menjalankan perintah shell dari PHP bisa sangat berguna sebagai pengembang. Tetapi jika Anda membiarkan input pengguna di sana, mereka memiliki kemampuan untuk diam-diam mendapatkan banyak kekuatan berbahaya. Jadi saya akan mengatakan bahwa input pengguna tidak boleh diteruskan ke fungsi shell_exec -type.

Cara terbaik yang dapat saya pikirkan untuk menangani situasi seperti ini, jika Anda tergoda untuk mengimplementasikannya, adalah dengan memberikan pengguna akses ke satu set kecil perintah shell yang telah ditentukan sebelumnya dan diketahui aman. Itu mungkin untuk mengamankan. Tetapi meskipun demikian, saya akan memperingatkan Anda untuk sangat berhati-hati.

Perhatikan Untuk unserialize ; Ini Menjalankan Kode Secara Otomatis

Tindakan inti memanggil serialize pada objek PHP yang hidup, menyimpan data itu di suatu tempat, dan kemudian menggunakan nilai yang disimpan itu nanti untuk unserialize serial objek itu kembali ke kehidupan itu keren. Ini juga cukup umum, tetapi bisa berisiko. Mengapa berisiko? Jika input ke panggilan unserialize itu tidak sepenuhnya aman (misalnya disimpan sebagai cookie daripada di database Anda…), penyerang dapat mengubah status internal objek Anda dengan cara yang membuat panggilan unserialize melakukan sesuatu yang buruk.

Eksploitasi ini lebih esoteris dan cenderung tidak diperhatikan daripada masalah eval . Tetapi jika Anda menggunakan cookie sebagai mekanisme penyimpanan untuk data bersambung, jangan gunakan serialize untuk data tersebut. Gunakan sesuatu seperti json_encode dan json_decode . Dengan kedua PHP itu tidak akan pernah mengeksekusi kode apa pun secara otomatis.

Kerentanan inti di sini adalah ketika PHP unserialize sa string ke dalam kelas, ia memanggil metode __wakeup ajaib di kelas itu. Jika input pengguna yang tidak divalidasi diizinkan untuk tidak unserialized , sesuatu seperti panggilan database atau penghapusan file dalam metode __wakeup berpotensi diarahkan ke lokasi yang berbahaya atau tidak diinginkan.

unserialize berbeda dari kerentanan eval karena memerlukan penggunaan metode sihir pada objek. Alih-alih membuat kode mereka sendiri, penyerang dipaksa untuk menyalahgunakan metode yang sudah Anda tulis pada suatu objek. Baik metode ajaib __destruct dan __toString pada objek juga berisiko, seperti yang dijelaskan oleh halaman Wiki OWASP ini.

Secara umum, Anda baik-baik saja jika Anda tidak menggunakan metode __wakeup , __destruct , atau __toString di kelas Anda. Tetapi karena nanti Anda mungkin melihat seseorang menambahkannya ke kelas, sebaiknya jangan pernah membiarkan pengguna mendekati panggilan Anda untuk serialize dan unserialize dan meneruskan semua data publik untuk penggunaan semacam itu meskipun sesuatu seperti JSON ( json_encode dan json_decode ) di mana ada tidak pernah eksekusi kode otomatis.

Mengambil URL Dengan file_get_contents Beresiko

Praktik umum saat menulis beberapa kode PHP dengan cepat yang harus memanggil URL eksternal adalah dengan meraih file_get_contents . Cepat, mudah, tetapi tidak super aman.

Masalah dengan file_get_contents tidak kentara, tetapi cukup umum bahwa host terkadang mengonfigurasi PHP untuk tidak mengizinkan Anda mengakses URL eksternal. Ini dimaksudkan untuk melindungi Anda.

Masalahnya di sini adalah file_get_contents akan mengambil halaman jarak jauh untuk Anda. Tetapi ketika melakukan itu, itu tidak memeriksa integritas koneksi protokol HTTPS. Artinya, skrip Anda berpotensi menjadi korban serangan man-in-the-middle yang memungkinkan penyerang memasukkan apa pun yang mereka inginkan ke hasil halaman file_get_contents Anda.

Ini adalah serangan yang lebih esoteris. Tetapi untuk melindunginya ketika saya menulis PHP modern (berbasis Komposer), saya hampir selalu menggunakan Guzzle untuk membungkus API cURL yang lebih aman. Di WordPress, bahkan lebih mudah: gunakan wp_remote_get . Ini bekerja jauh lebih konsisten daripada file_get_contents , dan itu akan menjadi default untuk memverifikasi koneksi SSL. (Anda dapat menonaktifkannya, tetapi, um, mungkin tidak…) Lebih baik lagi, tetapi sedikit lebih menjengkelkan untuk dibicarakan, adalah wp_safe_remote_get , dll. Ini bekerja secara identik dengan fungsi tanpa safe_ dalam namanya, tetapi mereka akan membuat memastikan bahwa pengalihan dan penerusan yang tidak aman tidak terjadi di sepanjang jalan.

Jangan Mempercayai Validasi URL Secara Buta Dari filter_var

Jadi yang ini agak tidak jelas, jadi berikan dukungan kepada Chris Weigman untuk menjelaskannya dalam pembicaraan WordCamp ini. Secara umum, filter_var PHP adalah cara yang bagus untuk memvalidasi atau membersihkan data. (Meskipun, jangan bingung tentang apa yang Anda coba lakukan…)

Masalahnya di sini cukup spesifik: jika Anda mencoba menggunakannya untuk memastikan bahwa URL aman, filter_var tidak memvalidasi protokol. Itu tidak sering menjadi masalah, tetapi jika Anda meneruskan input pengguna ke metode ini untuk validasi, dan menggunakan FILTER_VALIDATE_URL , sesuatu seperti javascript://comment%0aalert(1) akan berhasil. Artinya, ini bisa menjadi vektor yang sangat bagus untuk serangan XSS dasar di tempat yang tidak Anda duga.

Untuk memvalidasi URL, fungsi esc_url WordPress akan memiliki dampak yang serupa, tetapi hanya memungkinkan melalui protokol yang diizinkan. javascript tidak ada dalam daftar default, jadi itu akan membuat Anda tetap aman. Namun, tidak seperti filter_var , itu akan mengembalikan string kosong (bukan salah) untuk protokol yang tidak diizinkan yang diteruskan ke sana.

Fungsi Khusus WordPress Untuk Mengawasi

Selain fungsi inti-PHP yang berpotensi rentan, ada beberapa fungsi khusus WordPress yang bisa sedikit bermasalah. Beberapa di antaranya sangat mirip dengan berbagai fungsi berbahaya yang tercantum di atas, beberapa sedikit berbeda.

Unserialize WordPress Dengan maybe_unserialize

Yang ini mungkin sudah jelas jika Anda membaca yang di atas. Di WordPress ada fungsi yang disebut maybe_unserialize dan, seperti yang Anda duga, itu membatalkan serialisasi apa yang diteruskan ke sana jika perlu.

Tidak ada kerentanan baru yang diperkenalkan, masalahnya hanyalah seperti fungsi inti unserialize , yang satu ini dapat menyebabkan objek yang rentan dieksploitasi saat tidak diserialisasi.

is_admin Tidak Menjawab Jika Seorang Pengguna Adalah Administrator!

Yang ini cukup sederhana, tetapi fungsinya ambigu dalam nama, sehingga cenderung membingungkan orang atau terlewatkan jika Anda sedang terburu-buru. Anda harus selalu memeriksa bahwa pengguna yang mencoba melakukan tindakan di WordPress memiliki hak dan hak istimewa yang diperlukan untuk melakukan tindakan itu. Untuk itu, Anda harus menggunakan fungsi current_user_can .

Tetapi Anda mungkin, secara keliru, berpikir bahwa is_admin akan memberi tahu apakah Anda jika pengguna saat ini adalah akun tingkat Administrator dan dengan demikian harus dapat mengatur opsi yang digunakan plugin Anda. Ini adalah kesalahan. Apa yang dilakukan is_admin di WordPress adalah memberi tahu Anda jika pemuatan halaman saat ini berada di sisi administrasi situs (vs. sisi depan). Jadi setiap pengguna yang dapat mengakses halaman administrasi (seperti “Dasbor”) berpotensi lulus pemeriksaan ini. Selama Anda ingat bahwa is_admin adalah tentang jenis halaman, bukan pengguna saat ini, Anda akan baik-baik saja.

add_query_arg() Tidak Membersihkan URL

Ini tidak begitu umum, tetapi ada gelombang besar pembaruan di ekosistem WordPress beberapa tahun yang lalu karena dokumentasi publik tentang fungsi ini tidak benar. Masalah intinya adalah bahwa fungsi add_query_arg (dan kebalikannya remove_query_arg ) tidak secara otomatis membersihkan URL situs jika URL tidak diteruskan ke sana, dan orang-orang mengira itu terjadi. Banyak plugin telah disesatkan oleh Codex, dan akibatnya menggunakannya dengan tidak aman.

Hal inti yang harus mereka lakukan berbeda: membersihkan hasil panggilan ke fungsi ini sebelum menggunakannya. Jika Anda melakukannya, Anda benar-benar aman dari serangan XSS yang Anda kira. Jadi itu terlihat seperti:

 echo esc_url( add_query_arg( 'foo', 'bar' ) );

$wpdb->query() Terbuka Untuk Serangan Injeksi SQL

Jika Anda tahu tentang injeksi SQL, ini mungkin tampak konyol, bahkan berlebihan untuk dicantumkan. Karena masalahnya adalah dengan cara apa pun Anda mengakses database (misalnya menggunakan driver database mysqli atau PDO PHP) untuk membuat kueri database yang memungkinkan serangan injeksi SQL.

Alasan saya secara khusus memanggil $wpdb->query adalah karena beberapa metode lain (seperti insert , delete , dll.) pada $wpdb menangani serangan injeksi untuk Anda. Selain itu, jika Anda terbiasa membuat kueri basis data WordPress dasar dengan WP_Query atau yang serupa, Anda tidak perlu mempertimbangkan injeksi SQL. Inilah mengapa saya menyebutnya: untuk memastikan Anda memahami bahwa serangan injeksi pada database dimungkinkan saat Anda pertama kali mencoba menggunakan $wpdb untuk membuat kueri Anda sendiri.

Apa yang harus dilakukan? Gunakan $wpdb->prepare() dan kemudian $wpdb->query() . Anda juga ingin memastikan bahwa Anda mempersiapkan diri sebelum metode "mendapatkan" lain dari $wpdb seperti, get_row() dan get_var() . Kalau tidak, Bobby Tables mungkin akan menangkap Anda.

esc_sql Tidak Mengamankan Anda Dari Injeksi SQL

Untuk sebagian besar pengembang WordPress, saya akan mengatakan bahwa esc_sql tidak mendaftar dengan arti apa pun, tetapi seharusnya. Seperti yang baru saja kami sebutkan, Anda harus menggunakan wpdb->prepare() sebelum Anda membuat kueri basis data. Ini akan membuat Anda tetap aman. Tapi itu menggoda dan dimengerti bahwa pengembang dapat meraih esc_sql sebagai gantinya. Dan mereka mungkin berharap itu akan aman.

Masalahnya adalah esc_sql tidak memiliki perlindungan yang kuat terhadap injeksi SQL. Ini benar-benar versi yang dimuliakan dari fungsi add_slashes PHP, yang telah Anda hindari untuk digunakan untuk melindungi database Anda selama bertahun-tahun.

Masih Banyak Yang Harus Dilakukan, Tapi Ini Awal yang Besar

Ada lebih banyak keamanan daripada sekadar mencari fungsi dalam kode Anda yang dapat disalahgunakan oleh penyerang. Kami tidak, misalnya, membahas secara mendalam perlunya memvalidasi dan membersihkan semua data yang Anda terima dari pengguna dan menghindarinya sebelum Anda memasukkannya ke halaman web (walaupun baru-baru ini saya menerbitkan artikel tentang topik itu, “Melindungi WordPress Anda Situs Terhadap Serangan Scripting Lintas Situs"). Tetapi Anda dapat dan harus menggunakan ini sebagai bagian dari strategi keamanan yang lebih luas.

Menyimpan daftar fungsi yang mudah disalahgunakan ini di sisi Anda saat Anda melakukan pemeriksaan akhir sebelum menggunakan plugin baru di WordPress adalah ide bagus. Tetapi Anda juga ingin memastikan bahwa Anda memercayai keamanan hosting Anda, memastikan pengguna Anda memiliki kata sandi yang baik, dan banyak lagi.

Hal inti yang perlu diingat tentang keamanan adalah bahwa tautan terlemah Anda adalah yang terpenting. Praktik yang baik di satu area mendukung kemungkinan titik lemah di tempat lain, tetapi mereka tidak pernah bisa sepenuhnya memperbaikinya. Tapi hati-hati dengan fungsi-fungsi ini, dan Anda akan memiliki banyak manfaat.