HTTP - Keamanan
HTTP digunakan untuk komunikasi melalui internet, jadi pengembang aplikasi, penyedia informasi, dan pengguna harus menyadari batasan keamanan di HTTP / 1.1. Diskusi ini tidak menyertakan solusi definitif untuk masalah yang disebutkan di sini tetapi memberikan beberapa saran untuk mengurangi risiko keamanan.
Kebocoran Informasi Pribadi
Klien HTTP sering kali mengetahui informasi pribadi dalam jumlah besar seperti nama pengguna, lokasi, alamat email, sandi, kunci enkripsi, dll. Jadi, Anda harus sangat berhati-hati untuk mencegah kebocoran informasi ini yang tidak disengaja melalui protokol HTTP ke sumber lain.
Semua informasi rahasia harus disimpan di server dalam bentuk terenkripsi.
Mengungkap versi perangkat lunak tertentu dari server mungkin memungkinkan mesin server menjadi lebih rentan terhadap serangan terhadap perangkat lunak yang diketahui mengandung lubang keamanan.
Proksi yang berfungsi sebagai portal melalui firewall jaringan harus mengambil tindakan pencegahan khusus terkait transfer informasi header yang mengidentifikasi host di belakang firewall.
Informasi yang dikirim di bidang 'Dari' mungkin bertentangan dengan kepentingan privasi pengguna atau kebijakan keamanan situs mereka, dan karenanya, tidak boleh dikirim tanpa pengguna dapat menonaktifkan, mengaktifkan, dan mengubah konten bidang.
Klien tidak boleh menyertakan bidang tajuk Perujuk dalam permintaan HTTP (tidak aman), jika halaman perujuk ditransfer dengan protokol aman.
Penulis layanan yang menggunakan protokol HTTP tidak boleh menggunakan formulir berbasis GET untuk pengiriman data sensitif, karena akan menyebabkan data dikodekan dalam URI Permintaan.
File dan Path Names Based Attack
Dokumen harus dibatasi ke dokumen yang dikembalikan oleh permintaan HTTP menjadi hanya yang dimaksudkan oleh administrator server.
Misalnya, UNIX, Microsoft Windows, dan sistem operasi lain digunakan '..'sebagai komponen jalur untuk menunjukkan tingkat direktori di atas yang sekarang. Pada sistem seperti itu, server HTTP HARUS melarang konstruksi apa pun dalam URI Permintaan, jika konstruksi tersebut mengizinkan akses ke sumber daya di luar yang dimaksudkan untuk dapat diakses melalui server HTTP.
Spoofing DNS
Klien yang menggunakan HTTP sangat bergantung pada Layanan Nama Domain, dan karenanya umumnya rentan terhadap serangan keamanan berdasarkan kesalahan asosiasi alamat IP dan nama DNS yang disengaja. Jadi, klien perlu berhati-hati dalam mengasumsikan validitas berkelanjutan dari nomor IP / asosiasi nama DNS.
Jika klien HTTP menyimpan hasil pencarian nama host dalam cache untuk mencapai peningkatan kinerja, mereka harus mengamati informasi TTL yang dilaporkan oleh DNS. Jika klien HTTP tidak mematuhi aturan ini, mereka dapat dipalsukan ketika alamat IP server yang sebelumnya diakses berubah.
Header dan Spoofing Lokasi
Jika satu server mendukung beberapa organisasi yang tidak mempercayai satu sama lain, maka HARUS memeriksa nilai header Lokasi dan Lokasi Konten dalam tanggapan yang dibuat di bawah kendali organisasi tersebut untuk memastikan bahwa mereka tidak mencoba untuk membatalkan sumber daya. yang mereka tidak punya otoritas.
Kredensial Otentikasi
Klien HTTP dan agen pengguna yang ada biasanya menyimpan informasi autentikasi tanpa batas waktu. HTTP / 1.1 tidak menyediakan metode bagi server untuk mengarahkan klien membuang kredensial yang disimpan dalam cache ini yang merupakan risiko keamanan besar.
Ada sejumlah solusi untuk bagian-bagian dari masalah ini, dan oleh karena itu disarankan untuk menggunakan perlindungan kata sandi di screen saver, waktu menganggur habis, dan metode lain yang mengurangi masalah keamanan yang melekat dalam masalah ini.
Proxy dan Caching
Proksi HTTP adalah men-in-the-middle, dan mewakili peluang untuk serangan man-in-the-middle. Proksi memiliki akses ke informasi terkait keamanan, informasi pribadi tentang pengguna dan organisasi individu, dan informasi kepemilikan milik pengguna dan penyedia konten.
Operator proxy harus melindungi sistem tempat proxy berjalan, karena mereka akan melindungi sistem apa pun yang berisi atau mengirimkan informasi sensitif.
Proxy cache memberikan potensi kerentanan tambahan, karena konten cache mewakili target yang menarik untuk eksploitasi jahat. Oleh karena itu, konten cache harus dilindungi sebagai informasi sensitif.