Web14: Isu keselamatan dalam protokol HTTP

Artikel ini membentangkan beberapa isu keselamatan dalam protokol HTTP , yang dibangkitkan dalam dua dokumen RFC 7230 dan RFC 7231. Contoh dalam artikel tentang ralat khusus dirujuk daripada OWASP.

1. Risiko daripada faktor perantaraan

HTTP membenarkan penggunaan perantara untuk bertindak balas kepada permintaan melalui satu siri sambungan. Terdapat tiga elemen perantara biasa: proksi, pintu masuk dan terowong.

Permintaan atau respons perlu melalui titik A, B dan C. Mereka boleh mengakses maklumat sensitif yang dihantar, seperti maklumat peribadi pengguna atau organisasi. Kekurangan perhatian yang diberikan kepada keselamatan dan privasi oleh perantara boleh membawa kepada pelbagai kemungkinan serangan.

Pembangun dan pembangun sistem harus mempertimbangkan faktor privasi dan keselamatan semasa proses reka bentuk, pengekodan dan penggunaan sistem.

Pengguna perlu sedar tentang bahaya menggunakan proksi atau gerbang yang tidak dipercayai.

2. Pemisahan Tindak Balas

Pemisahan tindak balas (aka suntikan CRLF) ialah teknik eksploitasi web yang popular. Penyerang menghantar data yang dikodkan, dalam beberapa parameter permintaan, yang kemudiannya dinyahkod dan diulang dalam medan tertentu pengepala respons.

Jika data ini ialah simbol yang mewakili penghujung respons, dan tindak balas seterusnya dimulakan, respons asal akan dibahagikan kepada dua dan kandungan respons kedua akan dikawal oleh penyerang. Penyerang kemudiannya boleh membuat permintaan lain dalam sambungan berterusan yang sama, dan menipu penerima (termasuk perantara) untuk mempercayai bahawa respons kedua ini adalah sebagai tindak balas kepada permintaan kedua.

3. Minta Penyeludupan

Penyeludupan permintaan ialah teknik yang mengeksploitasi perbezaan dalam pemprosesan permintaan oleh pelbagai jenis pelayan untuk menyembunyikan permintaan yang kelihatan tidak berbahaya yang dilampirkan pada permintaan asal.

Mari kita pertimbangkan contoh berikut:

Katakan permintaan POST mengandungi dua medan "panjang kandungan" dalam pengepala dengan dua nilai berbeza. Sesetengah pelayan akan menolak permintaan ini (IIS dan Apache), tetapi yang lain tidak. Contohnya, SunONE W/S 6.1 menggunakan medan Panjang Kandungan dahulu, manakala Proksi sunONE 3.6 mengambil medan Panjang Kandungan kedua.

Dengan mengandaikan SITE ialah DNS SunONE W/S, terletak di belakang Proksi SunONE, terdapat fail poison.html terletak pada SunONE W/S. Berikut ialah cara untuk mengeksploitasi HTTP Request Suggling berdasarkan ketidakkonsistenan dalam pemprosesan antara dua pelayan:

[Perhatikan bahawa setiap baris berakhir dengan CRLF (“”), kecuali baris 10]

Mari kita pertimbangkan apa yang berlaku apabila permintaan dihantar kepada W/S melalui pelayan Proksi. Pertama, proksi akan menganalisis permintaan dari baris 1 hingga 7 (biru) dan menemui dua medan Panjang Kandungan. Seperti yang dinyatakan di atas, ia akan mengabaikan medan pertama dan memahami bahawa badan permintaan adalah 44 bait panjang. Oleh itu, ia menganggap data dari baris 8 hingga 10 sebagai badan permintaan pertama (dari baris 8 hingga 10, data adalah tepat 44 bait panjang). Proksi kemudiannya akan menganalisis baris 11 hingga 14 (berwarna merah) sebagai permintaan kedua pelanggan.

Sekarang mari kita lihat bagaimana W/S mentafsir data di atas, kerana ia dimajukan daripada proksi. Tidak seperti proksi, W/S akan menggunakan medan Panjang Kandungan pertama dan mentafsirkannya seperti berikut: permintaan pertama tidak mempunyai kandungan dan permintaan kedua bermula dari baris 8 (perhatikan bahawa W/S akan menghuraikan dari baris 11 dan seterusnya sebagai nilai daripada padang Bla).

Seterusnya, mari kita lihat bagaimana respons dikembalikan kepada pelanggan. Permintaan yang W/S faham ialah “POST /foobar.html” (dari baris 1) dan “GET /poison.html” (dari baris 8), jadi ia akan menghantar 2 respons kepada pelanggan dengan kandungan halaman foobar. html dan racun.html. Proksi memahami bahawa 2 respons ini sepadan dengan 2 permintaan: "POST /foobar.html" (dari baris 1) dan "GET /page_to_poison.html" (baris 11). Proksi akan cache kandungan halaman poison.html yang sepadan dengan URL "page_to_poison.html" (keracunan cache). Dari situ, apabila pelanggan meminta "page_to_poison.html" ia akan menerima kandungan halaman poison.html.

4. Serangan berdasarkan laluan fail

Pelayan web kerap menggunakan sistem fail tempatan mereka untuk mengurus pemetaan nama fail dalam URI kepada sumber sebenar pada pelayan. Kebanyakan sistem fail tidak direka bentuk untuk melindungi daripada laluan fail berniat jahat. Oleh itu, pelayan perlu mengelak daripada mengakses fail sistem yang penting.

Contohnya, UNIX, Microsoft Windows dan beberapa sistem pengendalian lain menggunakan “..” sebagai elemen laluan untuk mewakili direktori satu tahap di atas fail/direktori semasa. Tanpa kawalan input dan kebenaran yang betul, fail/folder sensitif sistem boleh diakses dengan memasukkan laluan yang menghala ke fail/folder ini.

5. Jenis serangan: Suntikan Perintah, Suntikan Kod, Suntikan Pertanyaan

[Pelayan web sering menggunakan parameter dalam URI sebagai input untuk melaksanakan perintah sistem dan pertanyaan pangkalan data. Walau bagaimanapun, data yang diterima dalam permintaan tidak boleh sentiasa dipercayai. Penyerang boleh mencipta dan mengubah suai komponen dalam permintaan (seperti kaedah, medan dalam pengepala, badan...), untuk melaksanakan perintah sistem, menanyakan pangkalan data...

Sebagai contoh, SQL Injection ialah serangan biasa di mana pelayan web menerima parameter dalam URI yang merupakan sebahagian daripada pertanyaan SQL. Oleh itu, penyerang boleh menipu pelayan web untuk melaksanakan pertanyaan SQL yang tidak sah, untuk mencuri atau mensabotaj pangkalan data.
Secara umum, data yang dihantar oleh pengguna tidak boleh digunakan secara langsung untuk melaksanakan operasi pada pelayan. Data ini perlu melalui penapis, yang menentukan apa yang sah dan apa yang tidak sah, dengan itu menghapuskan data yang tidak diingini.

6. Mendedahkan maklumat peribadi

Pelanggan selalunya mengandungi banyak maklumat peribadi, termasuk maklumat yang diberikan oleh pengguna untuk berinteraksi dengan pelayan (seperti nama pengguna, kata laluan, lokasi, alamat e-mel, dsb.) dan maklumat tentang aktiviti penyemakan imbas web. pengguna (sejarah, penanda halaman, dan lain-lain.). Apabila melaksanakan, perhatian harus diberikan untuk mencegah perkara yang boleh mendedahkan maklumat peribadi ini.

7. Mendedahkan maklumat sensitif dalam URI

URI, mengikut reka bentuk, bertujuan untuk dikongsi dengan semua pengguna dan tidak dijamin selamat. URI sering dipaparkan dalam kod sumber tapak web dan disimpan dalam penanda halaman tanpa mekanisme perlindungan. Oleh itu, ia akan menjadi tidak selamat jika URI mengandungi maklumat sensitif, maklumat peribadi, dsb.

Elakkan menggunakan kaedah GET untuk menghantar maklumat peribadi ke pelayan, kerana ia akan dipaparkan dalam URI. Gunakan kaedah POST sebaliknya.

8. Mendedahkan maklumat perisian yang digunakan

Medan Ejen Pengguna, Melalui, Pelayan dalam pengepala biasanya memberikan maklumat tentang perisian yang digunakan oleh pengirim. Secara teorinya, ini membolehkan penyerang untuk lebih mudah mengeksploitasi kelemahan yang diketahui dalam perisian ini.