versi baharu utiliti untuk menerima dan menghantar data melalui rangkaian - , yang menyediakan keupayaan untuk merumus permintaan secara fleksibel dengan menentukan parameter seperti kuki, agen_pengguna, perujuk dan sebarang pengepala lain. cURL menyokong HTTP, HTTPS, HTTP/2.0, HTTP/3, SMTP, IMAP, POP3, Telnet, FTP, LDAP, RTSP, RTMP dan protokol rangkaian lain. Pada masa yang sama, kemas kini telah dikeluarkan untuk perpustakaan libcurl, yang sedang dibangunkan secara selari, menyediakan API untuk menggunakan semua fungsi curl dalam program dalam bahasa seperti C, Perl, PHP, Python.
Keluaran baharu menambah pilihan "--cuba semula-semua-ralat" untuk mencuba semula operasi jika berlaku sebarang ralat dan membetulkan dua kelemahan:
- membolehkan anda menulis ganti fail tempatan dalam sistem apabila mengakses pelayan yang dikawal oleh penyerang. Masalah hanya muncul apabila pilihan “-J” (“–remote-header-name”) dan “-i” (“—head”) digunakan secara serentak. Pilihan "-J" membolehkan anda menyimpan fail dengan nama yang dinyatakan dalam pengepala
"Pelupusan Kandungan". Jika fail dengan nama yang sama sudah wujud, program curl biasanya enggan melakukan timpa ganti, tetapi jika pilihan "-i" hadir, logik semakan rosak dan fail ditimpa (semakan dijalankan pada peringkat menerima badan respons, tetapi dengan pilihan “-i” pengepala HTTP dipaparkan dahulu dan mempunyai masa untuk disimpan sebelum badan respons mula diproses). Hanya pengepala HTTP ditulis pada fail, tetapi pelayan boleh menghantar data sewenang-wenangnya dan bukannya pengepala dan ia akan ditulis. - boleh membawa kepada kebocoran kepada pelayan DNS beberapa kata laluan akses tapak (Asas, Digest, NTLM, dll.). Dengan menggunakan simbol "@" dalam kata laluan, yang juga digunakan sebagai pemisah kata laluan dalam URL, apabila ubah hala HTTP dicetuskan, curl akan menghantar bahagian kata laluan selepas simbol "@" bersama-sama dengan domain untuk diselesaikan nama. Contohnya, jika anda memberikan kata laluan "passw@rd123" dan nama pengguna "dan", curl akan menjana URL "https://dan:passw@[e-mel dilindungi]/path" bukannya "https://dan:passw%[e-mel dilindungi]/path" dan akan menghantar permintaan untuk menyelesaikan hos "[e-mel dilindungi]" bukannya "example.com".
Masalah muncul apabila sokongan untuk pengalihan HTTP relatif didayakan (dilumpuhkan melalui CURLOPT_FOLLOWLOCATION). Jika DNS tradisional digunakan, maklumat tentang sebahagian kata laluan boleh diperoleh oleh pembekal DNS dan oleh penyerang yang mempunyai keupayaan untuk memintas trafik rangkaian transit (walaupun permintaan asal adalah melalui HTTPS, kerana trafik DNS tidak disulitkan). Apabila DNS-over-HTTPS (DoH) digunakan, kebocoran adalah terhad kepada pengendali DoH.
Sumber: opennet.ru