1. Enam prinsip asas ujian keselamatan:
Pengesahan: Pengembalian permintaan daripada pengguna yang disahkan
Kawalan akses: Kawalan kebenaran dan perlindungan data untuk pengguna yang tidak disahkan
Integriti : Pengguna mesti menerima maklumat yang dihantar oleh pelayan dengan tepat
Kerahsiaan: Maklumat mesti dihantar dengan tepat kepada pengguna yang dimaksudkan
Kebolehpercayaan: Berapa kerapkah ia gagal? Berapa lama masa yang diambil untuk rangkaian pulih daripada kegagalan? Apakah langkah-langkah yang diambil untuk menangani kegagalan bencana? (Secara peribadi, saya faham bahawa tempat ini sepatutnya lebih cenderung kepada kategori toleransi kesalahan dan ujian toleransi bencana)
Bukan penolakan: Pengguna seharusnya dapat membuktikan bahawa data yang diterima datang daripada pelayan tertentu
2. Kandungan ujian keselamatan biasa
Kawalan Kebenaran
Suntikan SQL
Ujian Keselamatan URL
XSS (Skrip Merentas tapak)
CSRF (Pemalsuan Permintaan Rentas Tapak) )
Kerentanan melompat URL
Pertimbangan keselamatan lain
3. Secara umumnya terdapat sebab berikut:
1 Sistem aplikasi yang kompleks mempunyai sejumlah besar kod dan banyak pembangun, jadi kecuaian tidak dapat dielakkan.
2. Sistem telah dinaik taraf berulang kali dan kakitangan telah ditukar dengan kerap, mengakibatkan kod tidak konsisten.
3. Sistem Web berbilang seperti sistem warisan sejarah dan sistem operasi percubaan dijalankan bersama pada pelayan yang sama.
4. Pembangun belum menerima latihan pengekodan selamat atau syarikat itu tidak mempunyai standard pengekodan selamat bersatu.
5. Penguji tidak berpengalaman atau dikeluarkan tanpa ujian penilaian keselamatan profesional.
6. Tiada pengesahan input pengguna, berikut adalah beberapa contoh:
1) Jangan sekali-kali mempercayai input pengguna, sahkan input pengguna
2) Input angka mestilah nombor undang-undang
3) Input aksara memerlukan pemprosesan khas simbol pengekodan
4) Sahkan semua titik input, termasuk Dapatkan, Kirim, Kuki dan pengepala HTTP lain
4. Biasa kelemahan dan penyelesaian dalam ujian keselamatan:
1. Serangan skrip merentas tapak XSS
SS serupa dengan suntikan SQL, XSS Memasukkan skrip berniat jahat melalui halaman web terutamanya menggunakan HTML dan JavaScript bahagian hadapan skrip. Apabila pengguna melayari web, kaedah serangan dilaksanakan untuk mengawal tingkah laku penyemak imbas pengguna.
XSS yang berjaya boleh mendapatkan kuki pengguna dan menggunakan kuki untuk mencuri kebenaran operasi pengguna untuk tapak web itu juga boleh mendapatkan senarai kenalan pengguna dan menggunakan identiti penyerang untuk menyasarkan sasaran tertentu banyak spam kepada kumpulan, dsb.
XSS dibahagikan kepada tiga kategori: jenis storan (XSS berterusan), jenis pantulan (XSS tidak berterusan) dan jenis DOM.
Kaedah ujian:
Dalam antara muka input data, masukkan:
Atau tukar parameter dalam permintaan url kepada <script>alert(/123/)</script> Jika kotak dialog muncul pada halaman, ia menunjukkan bahawa terdapat kelemahan XSS.
2. Suntikan SQL
Suntikan SQL adalah untuk memasukkan arahan SQL ke dalam borang Web untuk menyerahkan atau memasukkan nama domain atau aksara pertanyaan permintaan halaman
, akhirnya menipu pelayan untuk melaksanakan perintah SQL Berniat jahat.
Kemudaratan yang mungkin disebabkan oleh suntikan SQL termasuk: halaman web dan data diusik, data teras dicuri dan pelayan tempat pangkalan data berada diserang dan bertukar menjadi hos boneka.
Contohnya, sesetengah tapak web tidak menggunakan sql yang telah dikompilasi, dan beberapa medan yang dimasukkan oleh pengguna pada antara muka ditambahkan pada sql Kemungkinan besar medan ini mengandungi beberapa arahan sql yang berniat jahat. Contohnya: kata laluan = "1' ATAU '1'='1"; walaupun anda tidak tahu kata laluan pengguna, anda boleh log masuk seperti biasa.
Kaedah ujian:
Pada halaman di mana anda perlu membuat pertanyaan, masukkan syarat pertanyaan yang betul dan 1=1 dan penyata sql mudah lain, semak keputusan respons, jika keputusan dikembalikan dengan memasukkan syarat pertanyaan yang betul adalah konsisten, ini bermakna Aplikasi tidak menapis input pengguna, dan pada mulanya boleh ditentukan bahawa terdapat kelemahan suntikan SQL di sini
Cadangan pengubahsuaian:
Sahkan input pengguna, anda boleh menggunakan ungkapan biasa atau mengehadkan panjang ;Tukar kata kunci berikut, dsb.;
||alert|and|exec|execute|sisip|pilih|delete|update|count|drop|chr|mid |master|truncate|declare|sitename|netuser |xp_cmdshell|or|+|,|like'|and|exec|execute|sisipkan|buat|jatuhkan|jadual|dari|geran|group_concat|nama_lajur|information_schema.columns|table_schema| kesatuan|di mana|pilih|padam|kemas kini|. mengikut|kiraan|chr|pertengahan|induk|penggal|deklarasi|atau|--|+|,|suka|//
Jangan gunakan pemasangan dinamik sql, anda boleh menggunakan sql berparameter atau menggunakannya secara langsung Prosedur tersimpan melakukan pertanyaan dan akses data
Jangan gunakan sambungan pangkalan data dengan keistimewaan pentadbir, gunakan sambungan pangkalan data berasingan dengan keistimewaan terhad untuk setiap aplikasi; >Maklumat pengecualian aplikasi hendaklah diberikan sepenuhnya Jika boleh, adalah lebih baik untuk membungkus mesej ralat asal dengan mesej ralat tersuai.
3. Kerentanan lompat URL
Kerentanan lompat URL, iaitu, kelemahan ubah hala yang tidak disahkan, merujuk kepada program web yang melompat terus ke URL dalam parameter atau diperkenalkan dalam halaman URL mana-mana pembangun diubah hala ke kawasan pihak ketiga yang tidak selamat, sekali gus menyebabkan isu keselamatan.
Kaedah ujian:
1 Gunakan alat tangkapan paket untuk menangkap permintaan.
2 Dapatkan URL 302, ubah suai alamat sasaran, dan semak sama ada ia boleh melompat.
ps: Walau bagaimanapun, banyak lompatan kini mempunyai pengesahan perujuk ditambah, menyebabkan penyerang gagal untuk melompat.
4. Kerentanan muat naik fail
Serangan muat naik fail bermakna penyerang memuat naik fail boleh laku ke pelayan dan melaksanakannya.
Kaedah serangan ini adalah yang paling langsung dan berkesan. Fail yang dimuat naik boleh menjadi virus, Trojan, skrip berniat jahat, cangkerang web, dsb.
Webshell ialah persekitaran pelaksanaan arahan yang wujud dalam bentuk fail web seperti asp, php, jsp atau cgi Ia juga boleh dikatakan sebagai pintu belakang web. Selepas penyerang menghalang atau memasukkan cangkerang web ke dalam sistem yang terjejas, dia boleh memasuki sistem dengan mudah melalui cangkerang web dan mengawal pelayan laman web.
Kaedah ujian:
Sahkan dengan ketat jenis fail yang dimuat naik, saiz, dsb., dan larang muat naik fail dengan kod hasad.
Sahkan kebenaran pelaksanaan direktori yang berkaitan Anda boleh mengakses semua direktori pada pelayan web melalui penyemak imbas dan menyemak sama ada struktur direktori dikembalikan Jika struktur direktori dipaparkan, mungkin terdapat masalah keselamatan.
5. Serangan permintaan palsu rentas tapak CSRF
CSRF menggunakan identiti pengguna log masuk untuk menghantar permintaan berniat jahat atas nama pengguna untuk menyelesaikan operasi yang menyalahi undang-undang.
Contohnya: Jika pengguna menyemak imbas dan mempercayai tapak web A yang mempunyai kerentanan CSRF, penyemak imbas menjana kuki yang sepadan dan pengguna melawati tapak web berbahaya B tanpa keluar dari tapak web.
Tapak web berbahaya B meminta akses kepada tapak web A dan membuat permintaan. Penyemak imbas melawati tapak web A dengan maklumat kuki pengguna Kerana tapak web A tidak mengetahui sama ada permintaan itu daripada pengguna itu sendiri atau dari tapak web berbahaya, ia akan memproses permintaan daripada tapak web berbahaya, sekali gus melengkapkan simulasi operasi pengguna . Ini adalah idea asas serangan CSRF.
Kaedah ujian:
1 Buka dua halaman dalam penyemak imbas yang sama Selepas kebenaran satu halaman tamat tempoh, bolehkah halaman yang satu lagi berjaya dikendalikan, di sana adalah risiko.
2. Gunakan alat untuk menghantar permintaan, jangan tambah medan perujuk dalam pengepala permintaan http, semak respons mesej yang dikembalikan, dan ubah hala ke antara muka ralat atau antara muka log masuk.
Atas ialah kandungan terperinci Apakah kelemahan keselamatan web biasa dan kaedah ujian?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!