ເຜີຍແຜ່ຜົນການກວດສອບລູກຄ້າ Mozilla VPN ແລ້ວ

Mozilla ໄດ້ປະກາດການສໍາເລັດການກວດສອບເອກະລາດຂອງຊອບແວລູກຄ້າສໍາລັບການເຊື່ອມຕໍ່ກັບບໍລິການ Mozilla VPN. ການກວດສອບໄດ້ລວມເອົາການວິເຄາະຂອງແອັບພລິເຄຊັນລູກຄ້າທີ່ຢືນຢູ່ຄົນດຽວທີ່ຂຽນໂດຍໃຊ້ Qt Library ແລະສາມາດໃຊ້ໄດ້ສໍາລັບ Linux, macOS, Windows, Android ແລະ iOS. Mozilla VPN ຖືກຂັບເຄື່ອນໂດຍຫຼາຍກວ່າ 400 ເຊີບເວີຂອງຜູ້ໃຫ້ບໍລິການ VPN ຊູແອັດ Mullvad, ທີ່ຕັ້ງຢູ່ໃນຫຼາຍກວ່າ 30 ປະເທດ. ການເຊື່ອມຕໍ່ກັບການບໍລິການ VPN ແມ່ນເຮັດໂດຍໃຊ້ WireGuard protocol.

ການກວດສອບໄດ້ດໍາເນີນໂດຍ Cure53, ເຊິ່ງໃນເວລາດຽວໄດ້ກວດສອບໂຄງການ NTPsec, SecureDrop, Cryptocat, F-Droid ແລະ Dovecot. ການກວດສອບໄດ້ກວມເອົາການກວດສອບລະຫັດແຫຼ່ງແລະລວມເອົາການທົດສອບເພື່ອກໍານົດຈຸດອ່ອນທີ່ເປັນໄປໄດ້ (ບັນຫາທີ່ກ່ຽວຂ້ອງກັບການເຂົ້າລະຫັດລັບບໍ່ໄດ້ຖືກພິຈາລະນາ). ​ໃນ​ໄລຍະ​ກວດກາ, ​ໄດ້​ກຳນົດ​ບັນຫາ​ຄວາມ​ປອດ​ໄພ 16 ​ເລື່ອງ, ​ໃນ​ນັ້ນ​ມີ 8 ຂໍ້​ແນະນຳ, 5 ​ເລື່ອງ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ມອບ​ໝາຍ​ລະດັບ​ອັນຕະລາຍ​ຕ່ຳ, XNUMX ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ມອບ​ໝາຍ​ຂັ້ນ​ກາງ, ​ແລະ ໜຶ່ງ​ແມ່ນ​ລະດັບ​ອັນຕະລາຍ​ສູງ.

ຢ່າງໃດກໍ່ຕາມ, ມີພຽງແຕ່ຫນຶ່ງບັນຫາທີ່ມີລະດັບຄວາມຮຸນແຮງປານກາງໄດ້ຖືກຈັດປະເພດເປັນຈຸດອ່ອນ, ເນື່ອງຈາກວ່າມັນເປັນພຽງແຕ່ຫນຶ່ງທີ່ສາມາດຂູດຮີດ. ບັນຫານີ້ເຮັດໃຫ້ເກີດການຮົ່ວໄຫລຂອງຂໍ້ມູນການນໍາໃຊ້ VPN ໃນລະຫັດກວດຈັບ portal captive ເນື່ອງຈາກການຮ້ອງຂໍ HTTP ໂດຍກົງທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດທີ່ສົ່ງຢູ່ນອກອຸໂມງ VPN, ເປີດເຜີຍທີ່ຢູ່ IP ຕົ້ນຕໍຂອງຜູ້ໃຊ້ຖ້າຜູ້ໂຈມຕີສາມາດຄວບຄຸມການຈະລາຈອນທາງຜ່ານໄດ້. ບັນຫາແມ່ນໄດ້ຮັບການແກ້ໄຂໂດຍການປິດການທໍາງານຂອງຮູບແບບການກວດພົບປະຕູ captive ໃນການຕັ້ງຄ່າ.

ບັນຫາທີສອງຂອງຄວາມຮຸນແຮງຂະຫນາດກາງແມ່ນກ່ຽວຂ້ອງກັບການຂາດການທໍາຄວາມສະອາດທີ່ເຫມາະສົມຂອງຄ່າທີ່ບໍ່ແມ່ນຕົວເລກຢູ່ໃນຫມາຍເລກພອດ, ເຊິ່ງເຮັດໃຫ້ການຮົ່ວໄຫລຂອງຕົວກໍານົດການຢືນຢັນ OAuth ໂດຍການປ່ຽນເລກພອດດ້ວຍສາຍເຊັ່ນ "[email protected]", ເຊິ່ງຈະນໍາໄປສູ່ການຕິດຕັ້ງແທັກ[email protected]/?code=..." alt=""> ເຂົ້າຫາ example.com ແທນ 127.0.0.1.

ບັນຫາທີສາມ, ຖືກທຸງວ່າເປັນອັນຕະລາຍ, ອະນຸຍາດໃຫ້ແອັບພລິເຄຊັນທ້ອງຖິ່ນໃດນຶ່ງທີ່ບໍ່ມີການພິສູດຢືນຢັນໃນການເຂົ້າເຖິງລູກຄ້າ VPN ຜ່ານ WebSocket ທີ່ຜູກມັດກັບ localhost. ເປັນຕົວຢ່າງ, ມັນສະແດງໃຫ້ເຫັນວິທີການ, ກັບລູກຄ້າ VPN ທີ່ມີການເຄື່ອນໄຫວ, ເວັບໄຊທ໌ໃດກໍ່ຕາມສາມາດຈັດຕັ້ງການສ້າງແລະການສົ່ງຮູບຫນ້າຈໍໂດຍການສ້າງເຫດການ screen_capture. ບັນຫາບໍ່ໄດ້ຖືກຈັດປະເພດເປັນຊ່ອງໂຫວ່, ເພາະວ່າ WebSocket ຖືກນໍາໃຊ້ພຽງແຕ່ໃນການທົດສອບພາຍໃນແລະການນໍາໃຊ້ຊ່ອງທາງການສື່ສານນີ້ພຽງແຕ່ວາງແຜນໃນອະນາຄົດເພື່ອຈັດການໂຕ້ຕອບກັບ browser add-on.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru