PHP Master | Kelemahan keselamatan PHP 10 teratas

mata utama

Suntikan SQL:

Ini adalah kelemahan keselamatan utama dalam PHP, di mana penyerang memasukkan coretan kod SQL ke dalam URL atau borang web anda. Kenyataan preprocessing PDO boleh digunakan untuk mencegah serangan tersebut, yang memisahkan data dari arahan, memastikan data hanya dianggap sebagai data.
• Serangan skrip lintas tapak (XSS):
serangan XSS berlaku apabila kod berniat jahat disuntik ke dalam output skrip PHP anda. Serangan sedemikian boleh dicegah dengan mengesahkan dan membersihkan input pengguna, memastikan bahawa input tidak mengandungi kod yang berbahaya.
• fail jauh mengandungi:
Ini melibatkan termasuk fail luaran dalam aplikasi anda, yang boleh menyebabkan kemudaratan jika mereka rosak. Ini boleh dielakkan dengan melumpuhkan tetapan
• dan dalam fail php.ini. allow_url_fopen allow_url_include sesi rampasan:
rampasan sesi berlaku apabila ID sesi pengguna dicuri dan digunakan oleh penyerang. Serangan sedemikian boleh dicegah dengan menggunakan fungsi
• untuk menukar ID sesi secara berkala dan menyimpan ID sesi di tempat yang hanya boleh diakses oleh skrip anda. 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:

• "serangan skrip lintas tapak" yang ditulis oleh George Fekette
• "Menggunakan fungsi penapis untuk pengesahan input" oleh Toby Osbourn

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)

Apakah kelemahan keselamatan PHP yang paling biasa?

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.

Bagaimana untuk mencegah suntikan SQL di PHP?

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.

Apakah serangan skrip lintas tapak (XSS) dan bagaimana untuk mencegahnya?

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.

Bagaimana untuk melindungi permohonan PHP saya dari serangan pemalsuan permintaan lintas tapak (CSRF)?

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.

Apakah fail yang mengandungi kelemahan dan bagaimana mengurangkannya?

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.

Apakah suntikan objek php dan bagaimana untuk mencegahnya?

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.

bagaimana melindungi sesi php saya?

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.

Apakah beberapa amalan terbaik untuk keselamatan PHP?

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.

Bagaimana untuk mengesan kelemahan PHP dalam permohonan saya?

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.

sumber apa yang ada untuk mengetahui lebih lanjut mengenai keselamatan PHP?

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!