mata utama
Suntikan SQL:allow_url_fopen
allow_url_include
sesi rampasan: session_regenerate_id()
Keselamatan bukan sekadar satu siri operasi, tetapi juga cara berfikir, cara melihat masalah, dan cara menangani dunia. Ini bermakna "Saya tidak tahu apa yang akan mereka lakukan, tetapi saya tahu mereka akan cuba mengawal sistem saya" dan kemudian secara proaktif menghalang masalah daripada jatuh ke dalam emosi negatif. Walau bagaimanapun, anda tidak boleh melanggar peraturan statistik. Tiada siapa yang akan membaca artikel bertajuk "Coding for Security". Semua orang mahu artikel dengan nombor, seperti: "8 serangan keselamatan PHP yang paling biasa dan bagaimana untuk mengelakkannya", "23 perkara tidak dikatakan kepada supermodel" dan "15 Alasan untuk mengelakkan keracunan radiasi." Oleh itu, berikut adalah "Sepuluh Kelemahan Keselamatan PHP Teratas". suntikan sql
Tempat teratas ialah serangan suntikan SQL. Dalam kes ini, seseorang memasuki coretan kod SQL (contoh klasik memadam penyata pangkalan data, walaupun terdapat banyak operasi lain yang merosakkan) sebagai nilai ke dalam URL atau borang web anda. Sekarang jangan risau bagaimana dia tahu nama meja anda; Anda berjuang dengan musuh yang jahat dan bijak. Jadi, apa yang boleh anda lakukan untuk mengelakkan ini? Pertama, anda perlu ragu -ragu dengan sebarang input yang anda terima dari pengguna. Saya percaya semua orang mesra? Lihatlah keluarga pasangan anda ... mereka pelik, pelik, dan ada juga yang berbahaya. Cara untuk mengelakkan masalah tersebut adalah dengan menggunakan pernyataan pra -proses PDO. Saya tidak mahu membincangkan PDO secara terperinci sekarang. Cukup katakan bahawa pernyataan pra -proses memisahkan data dari arahan. Melakukannya menghalang data daripada dirawat sebagai apa -apa selain daripada data. Untuk maklumat lanjut, anda boleh melihat artikel "berhijrah dari Extension MySQL ke PDO" yang ditulis oleh Timothy Boronczyk.
serangan skrip lintas tapak (XSS)
Curn orang-orang hitam yang bergantung pada penipuan ini untuk bertahan. Ibu bapa, bercakap dengan anak -anak hari ini supaya mereka tidak menjadi penyerang XSS jahat! Inti dari sebarang serangan XSS adalah untuk menyuntik kod (biasanya kod JavaScript, tetapi boleh menjadi kod klien) ke dalam output skrip PHP anda. Serangan semacam ini mungkin apabila anda memaparkan input yang dihantar kepada anda, sebagai contoh, anda mungkin melakukan ini dalam jawatan forum. Penyerang boleh menyiarkan kod JavaScript dalam mesejnya yang boleh menyebabkan kerosakan yang tidak terkatakan di laman web anda. Tolong jangan biarkan saya menerangkan secara terperinci; Untuk maklumat lanjut dan bagaimana untuk melindungi diri anda, saya cadangkan membaca artikel -artikel yang sangat baik ini mengenai phpmaster:
kebocoran kod sumber
Ini mempunyai kaitan dengan keupayaan untuk melihat nama dan kandungan fail yang tidak sepatutnya dilihat oleh orang apabila konfigurasi Apache gagal. Ya, saya faham, ini tidak mungkin berlaku, tetapi ia boleh berlaku dan mudah untuk melindungi diri anda, jadi mengapa tidak? Kita semua tahu bahawa PHP adalah pelayan - anda tidak boleh melihat kod sumber untuk melihat kod skrip. Tetapi jika Apache gagal dan skrip anda tiba -tiba berfungsi dalam teks biasa, orang akan melihat kod sumber yang tidak sepatutnya dilihat. Sesetengah kod ini mungkin menyenaraikan fail konfigurasi yang boleh diakses, atau mengandungi maklumat sensitif, seperti kelayakan pangkalan data. Inti penyelesaiannya ialah bagaimana anda menyediakan struktur direktori aplikasi anda. Iaitu, ia bukan masalah bagi orang jahat untuk melihat beberapa kod, masalahnya ialah kod yang mereka dapat lihat jika fail sensitif disimpan dalam direktori awam. Simpan fail penting di luar direktori yang boleh diakses awam untuk mengelakkan akibat kesilapan ini. Untuk maklumat lanjut, termasuk contoh struktur direktori anda, lihat titik 5 dalam artikel ini. Untuk lebih banyak perbincangan mengenai topik ini, lihat perbincangan forum ini.
fail jauh mengandungi
Sila tunggu dan beritahu saya: Kemasukan fail jauh bermaksud bahawa fail jauh dimasukkan ke dalam permohonan anda. Sangat mendalam, bukan? Tetapi mengapa ini masalah? Kerana fail jauh tidak boleh dipercayai. Ia mungkin telah diubahsuai secara berniat jahat, mengandungi kod yang anda tidak mahu lari dalam permohonan anda. Katakan laman web www.myplace.com anda mengandungi perpustakaan www.goodpeople.com/script.php. Suatu malam, www.goodpeople.com telah digodam dan kandungan fail digantikan dengan kod berniat jahat yang akan memusnahkan permohonan anda. Kemudian seseorang melawat laman web anda, anda memperkenalkan kod terkini, dan kemudian - bang! Jadi bagaimana anda menghentikannya? Nasib baik, menetapkan masalah ini agak mudah. Anda hanya perlu pergi ke php.ini anda dan periksa tetapan bendera ini.
allow_url_fopen
- Menunjukkan sama ada fail luaran boleh dimasukkan. Tetapan lalai adalah "ON", tetapi anda harus mematikannya. allow_url_include
- Menunjukkan sama ada fungsi include()
, require()
, include_once()
, dan require_once()
boleh merujuk fail jauh. Ia dimatikan secara lalai, dan mematikan allow_url_fopen
juga memaksa ia dimatikan. Sesi Hijacking
rampasan sesi adalah apabila orang jahat mencuri dan menggunakan ID sesi orang lain, yang seperti kunci kepada peti deposit selamat yang selamat. Apabila sesi ditubuhkan di antara klien dan pelayan web, PHP boleh menyimpan ID sesi dalam kuki bernama phpsessId pada klien. Menghantar ID dengan permintaan halaman untuk mengakses maklumat sesi yang berterusan pada pelayan (ini mengisi variabel Super Global $_SESSION
array). Sekiranya seseorang mencuri kunci sesi, adakah itu buruk? Jawapannya ialah: Jika anda tidak melakukan apa -apa tindakan penting dalam sesi itu, jawapannya tidak. Walau bagaimanapun, jika anda menggunakan sesi itu untuk mengesahkan pengguna, ia akan membolehkan beberapa orang bermakna log masuk dan masuk ke sesuatu. Ini sangat buruk jika pengguna penting dan mempunyai banyak kebenaran. Jadi bagaimana orang mencuri ID sesi ini, dan apa yang boleh kita, orang -orang kita yang tegak dan takut kepada Tuhan, lakukan? ID sesi biasanya dicuri melalui serangan XSS, jadi menghalang serangan XSS adalah perkara yang baik yang boleh mendapat manfaat berganda. Ia juga penting untuk menukar ID sesi seberapa kerap mungkin. Ini akan memendekkan tetingkap masa yang dicuri anda. Dalam PHP, anda boleh menjalankan fungsi session_regenerate_id()
untuk menukar ID sesi dan memberitahu pelanggan. Bagi pengguna yang menggunakan Php 5.2 dan kemudian (anda menggunakannya?), Terdapat tetapan php.ini yang menghalang JavaScript daripada mengakses ID Sesi (session.cookie.httponly
). Sebagai alternatif, anda boleh menggunakan fungsi session_set_cookie_parms()
. Jika anda menggunakan perkhidmatan hosting yang dikongsi (yang menyimpan maklumat sesi dalam direktori yang boleh diakses secara global, contohnya /tmp
), maka ID sesi juga mungkin mempunyai kelemahan di sisi pelayan. Anda boleh menyekat masalah ini dengan hanya menyimpan ID sesi di lokasi yang hanya boleh diakses oleh skrip anda (pada cakera atau dalam pangkalan data).
Pemalsuan permintaan lintas tapak
Pemalsuan permintaan lintas tapak (CSRF), yang juga dikenali sebagai strategi Brett Mafrick atau Sean Spencer, melibatkan menipu pengguna yang agak tidak dikenali untuk menghantar satu yang harus kita katakan adalah yang paling tidak menguntungkan sendiri. Tetapi bukannya membiarkan saya terus membincangkan serangan CSRF, merujuk kepada contoh yang luar biasa dari kandungan tersebut pada PHPMaster: Mencegah Pemalsuan Permintaan Lintas Laman, yang ditulis oleh Martin Psinas.
katalog traversal
serangan semacam ini, seperti banyak serangan lain, mencari laman web dengan keselamatan yang lemah, dan apabila ia mendapati laman web, ia menyebabkan akses kepada fail yang pemiliknya tidak berniat untuk mengakses secara terbuka. Ia juga dipanggil ../
(titik, titik, slash) serangan, serangan memanjat, dan serangan balik. Terdapat beberapa cara untuk mencegah serangan ini. Pertama sekali, saya sangat berharap ia tidak akan berlaku kepada anda. Kadang -kadang membuat keinginan untuk peri dan unicorns membantu. Kadang -kadang tidak. Pendekatan kedua adalah menggunakan senarai putih untuk menentukan halaman mana yang boleh dikembalikan untuk permintaan yang diberikan. Pilihan lain adalah untuk menukar laluan fail ke laluan mutlak dan pastikan mereka merujuk fail dalam direktori yang dibenarkan.
Ringkasan
Ini adalah 10 isu teratas yang boleh menyebabkan permohonan PHP anda digodam jika anda tidak sengaja mengelakkannya. Ya, 10. Kira ... 1,2,3 ... Apa? Anda hanya menghitung 8? Ok, mungkin 7. Nah, ini menunjukkan anda boleh dengan mudah tertipu dan saya bukan lelaki yang jahat! gambar dari Fotolia
soalan yang sering ditanya untuk kelemahan keselamatan php (FAQ)
Kelemahan keselamatan PHP yang paling biasa termasuk suntikan SQL, serangan skrip lintas tapak (XSS), pemalsuan permintaan lintas tapak (CSRF), kelemahan inklusi fail, dan suntikan objek PHP. Sekiranya ditangani secara tidak wajar, kelemahan ini boleh membawa kepada akses yang tidak dibenarkan, kecurian data, dan juga pengambilalihan pelayan. Adalah penting bagi pemaju untuk memahami kelemahan ini dan melaksanakan langkah -langkah keselamatan yang sesuai untuk melindungi aplikasi PHP mereka.
Penyataan pra -proses atau pertanyaan parameter boleh digunakan untuk mencegah suntikan SQL. Kaedah ini memastikan bahawa input pengguna sentiasa dianggap sebagai data literal, bukan sebahagian daripada arahan SQL. Ini berkesan menghapuskan risiko suntikan SQL. Di samping itu, sentiasa mengesahkan dan membersihkan input pengguna untuk memastikan ia tidak mengandungi kod berniat jahat.
Serangan skrip lintas tapak (XSS) adalah kelemahan yang membolehkan penyerang menyuntik skrip berniat jahat ke laman web yang dilihat oleh pengguna lain. Ini boleh membawa kepada rampasan sesi, kecurian identiti dan masalah serius yang lain. Untuk mengelakkan XSS, sentiasa mengekodkan input pengguna dan tidak pernah memasukkan data yang tidak dipercayai ke dalam output HTML.
Token AnticsRF boleh digunakan untuk mencegah serangan CSRF. Ini adalah satu -satunya nilai rawak yang berkaitan dengan sesi pengguna. Mereka dimasukkan ke dalam setiap permintaan perubahan negeri (seperti penyerahan borang) dan diperiksa oleh pelayan. Jika token hilang atau tidak betul, permintaan itu akan ditolak.
Kerentanan inklusi fail merujuk kepada keadaan di mana aplikasi menggunakan input pengguna untuk membina laluan fail untuk operasi. Penyerang boleh memanipulasi input untuk mengandungi fail dari pelayan jauh, mengakibatkan pelaksanaan kod, kebocoran data, atau penafian perkhidmatan. Untuk mengurangkan kelemahan ini, elakkan menggunakan input pengguna dalam laluan fail, atau mengesahkan dan membersihkan input dengan teliti.
PHP Object Suntikan adalah kelemahan, yang berlaku apabila input pengguna digunakan untuk memberi contoh kelas. Penyerang boleh memanipulasi input untuk membuat contoh mana -mana kelas dan melaksanakan kaedahnya. Untuk mengelakkan ini, jangan sekali -kali tidak mengawasi data dari sumber yang tidak dipercayai.
Sesi PHP boleh dilindungi dengan menggunakan kuki yang selamat, membiayai semula ID sesi selepas log masuk, dan melaksanakan masa tamat sesi. Di samping itu, data sesi disimpan di sebelah pelayan dan hanya ID sesi yang digunakan untuk merujuknya.
Beberapa amalan terbaik untuk keselamatan PHP termasuk: menyimpan versi PHP yang terkini, menyediakan dengan konfigurasi keselamatan, mengesahkan dan membersihkan input pengguna, menggunakan algoritma hashing kata laluan yang selamat, dan melaksanakan pengendalian ralat yang betul.
Kelemahan PHP boleh dikesan melalui semakan kod, ujian penembusan dan menggunakan alat keselamatan automatik. Secara kerap mengkaji aplikasi untuk kelemahan keselamatan adalah bahagian penting dalam mengekalkan aplikasi PHP yang selamat.
Terdapat banyak sumber untuk belajar tentang keselamatan PHP, termasuk manual PHP, tutorial dalam talian, blog keselamatan dan forum. Di samping itu, organisasi seperti OWASP menyediakan panduan komprehensif mengenai keselamatan aplikasi web.
Atas ialah kandungan terperinci PHP Master | Kelemahan keselamatan PHP 10 teratas. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!