Chrome ຈະເລີ່ມປິດກັ້ນຊັບພະຍາກອນ HTTP ໃນໜ້າ HTTPS ແລະກວດສອບຄວາມແຮງຂອງລະຫັດຜ່ານ

ກູໂກ ເຕືອນ ກ່ຽວກັບການປ່ຽນວິທີການປຸງແຕ່ງເນື້ອຫາປະສົມຢູ່ໃນຫນ້າທີ່ເປີດຜ່ານ HTTPS. ກ່ອນຫນ້ານີ້, ຖ້າມີອົງປະກອບຢູ່ໃນຫນ້າທີ່ເປີດຜ່ານ HTTPS ທີ່ຖືກໂຫລດຈາກໂດຍບໍ່ມີການເຂົ້າລະຫັດ (ຜ່ານ http:// protocol), ຕົວຊີ້ວັດພິເສດຈະສະແດງ. ໃນອະນາຄົດ, ມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະສະກັດການໂຫຼດຂອງຊັບພະຍາກອນດັ່ງກ່າວໂດຍຄ່າເລີ່ມຕົ້ນ. ດັ່ງນັ້ນ, ຫນ້າທີ່ເປີດຜ່ານ "https://" ຈະຖືກຮັບປະກັນວ່າມີພຽງແຕ່ຊັບພະຍາກອນທີ່ດາວໂຫລດຜ່ານຊ່ອງທາງການສື່ສານທີ່ປອດໄພ.

ມັນໄດ້ຖືກສັງເກດເຫັນວ່າໃນປັດຈຸບັນຫຼາຍກ່ວາ 90% ຂອງເວັບໄຊທ໌ຖືກເປີດໂດຍຜູ້ໃຊ້ Chrome ໂດຍໃຊ້ HTTPS. ການປະກົດຕົວຂອງຊ່ອງສຽບທີ່ໂຫລດໂດຍບໍ່ມີການເຂົ້າລະຫັດຈະສ້າງໄພຂົ່ມຂູ່ດ້ານຄວາມປອດໄພໂດຍຜ່ານການດັດແປງເນື້ອຫາທີ່ບໍ່ມີການປ້ອງກັນຖ້າມີການຄວບຄຸມຊ່ອງທາງການສື່ສານ (ຕົວຢ່າງ, ເມື່ອເຊື່ອມຕໍ່ຜ່ານ Wi-Fi ເປີດ). ຕົວຊີ້ວັດເນື້ອຫາປະສົມໄດ້ຖືກພົບເຫັນວ່າບໍ່ມີປະສິດຕິຜົນແລະເຂົ້າໃຈຜິດຕໍ່ຜູ້ໃຊ້, ຍ້ອນວ່າມັນບໍ່ໄດ້ສະຫນອງການປະເມີນທີ່ຊັດເຈນກ່ຽວກັບຄວາມປອດໄພຂອງຫນ້າ.

ໃນປັດຈຸບັນ, ປະເພດທີ່ເປັນອັນຕະລາຍທີ່ສຸດຂອງເນື້ອຫາທີ່ປະສົມເຊັ່ນ: scripts ແລະ iframes, ຖືກບລັອກໄວ້ແລ້ວໂດຍຄ່າເລີ່ມຕົ້ນ, ແຕ່ຮູບພາບ, ໄຟລ໌ສຽງແລະວິດີໂອຍັງສາມາດດາວໂຫລດຜ່ານ http://. ຜ່ານການຫຼອກລວງຮູບພາບ, ຜູ້ໂຈມຕີສາມາດທົດແທນ cookies ຕິດຕາມຜູ້ໃຊ້, ພະຍາຍາມໃຊ້ຊ່ອງໂຫວ່ໃນໂປເຊດເຊີຮູບພາບ, ຫຼືເຮັດການປອມແປງໂດຍການປ່ຽນຂໍ້ມູນທີ່ສະຫນອງໃນຮູບພາບ.

ການແນະນໍາການສະກັດກັ້ນແມ່ນແບ່ງອອກເປັນຫຼາຍຂັ້ນຕອນ. Chrome 79, ກໍານົດສໍາລັບເດືອນທັນວາ 10th, ຈະມີການຕັ້ງຄ່າໃຫມ່ທີ່ຈະຊ່ວຍໃຫ້ທ່ານສາມາດປິດການປິດກັ້ນສໍາລັບສະຖານທີ່ສະເພາະ. ການຕັ້ງຄ່ານີ້ຈະຖືກນໍາໃຊ້ກັບເນື້ອຫາປະສົມທີ່ຖືກບລັອກໄວ້ແລ້ວ, ເຊັ່ນ: scripts ແລະ iframes, ແລະຈະຖືກເອີ້ນຜ່ານເມນູທີ່ເລື່ອນລົງເມື່ອທ່ານຄລິກໃສ່ສັນຍາລັກລັອກ, ແທນທີ່ຕົວຊີ້ວັດທີ່ສະເຫນີກ່ອນຫນ້ານີ້ສໍາລັບການປິດການບລັອກ.

Chrome 80, ເຊິ່ງຄາດວ່າໃນວັນທີ 4 ກຸມພາ, ຈະໃຊ້ໂຄງການປິດກັ້ນແບບອ່ອນໆສໍາລັບໄຟລ໌ສຽງ ແລະວິດີໂອ, ເຊິ່ງຫມາຍເຖິງການປ່ຽນລິ້ງ http:// ໂດຍອັດຕະໂນມັດກັບ https://, ເຊິ່ງຈະຮັກສາການທໍາງານໄດ້ຖ້າຊັບພະຍາກອນທີ່ມີບັນຫາແມ່ນສາມາດເຂົ້າເຖິງໄດ້ຜ່ານ HTTPS. . ຮູບພາບຈະສືບຕໍ່ໂຫຼດໂດຍບໍ່ມີການປ່ຽນແປງ, ແຕ່ຖ້າດາວໂຫຼດຜ່ານ http://, ຫນ້າ https:// ຈະສະແດງຕົວຊີ້ບອກການເຊື່ອມຕໍ່ທີ່ບໍ່ປອດໄພສໍາລັບຫນ້າທັງຫມົດ. ເພື່ອປ່ຽນເປັນ https ຫຼືບລັອກຮູບພາບໂດຍອັດຕະໂນມັດ, ຜູ້ພັດທະນາເວັບໄຊຈະສາມາດໃຊ້ຄຸນສົມບັດ CSP upgrade-insecure-requests ແລະ block-all-mixed-content. Chrome 81, ກໍານົດສໍາລັບ 17 ມີນາ, ຈະແກ້ໄຂອັດຕະໂນມັດ http:// ເປັນ https:// ສໍາລັບການອັບໂຫລດຮູບພາບປະສົມ.

ນອກຈາກນັ້ນ, Google ປະ​ກາດ ກ່ຽວກັບການເຊື່ອມໂຍງກັບຫນຶ່ງໃນການປ່ອຍຕໍ່ໄປຂອງຕົວທ່ອງເວັບ Chome ຂອງອົງປະກອບການກວດສອບລະຫັດຜ່ານໃຫມ່, ກ່ອນຫນ້ານີ້ ພັດທະນາ ເປັນ ນອກ​ຈາກ​ນັ້ນ​. ການປະສົມປະສານຈະນໍາໄປສູ່ຮູບລັກສະນະໃນຕົວຈັດການລະຫັດຜ່ານຂອງ Chrome ປົກກະຕິຂອງເຄື່ອງມືສໍາລັບການວິເຄາະຄວາມຫນ້າເຊື່ອຖືຂອງລະຫັດຜ່ານທີ່ຜູ້ໃຊ້ໃຊ້. ເມື່ອທ່ານພະຍາຍາມເຂົ້າສູ່ລະບົບເວັບໄຊທ໌ໃດນຶ່ງ, ການເຂົ້າສູ່ລະບົບ ແລະລະຫັດຜ່ານຂອງທ່ານຈະຖືກກວດສອບກັບຖານຂໍ້ມູນຂອງບັນຊີທີ່ຖືກລະເມີດ, ໂດຍມີຄໍາເຕືອນທີ່ສະແດງຂຶ້ນຫາກກວດພົບບັນຫາ. ການກວດສອບແມ່ນດໍາເນີນຕໍ່ກັບຖານຂໍ້ມູນທີ່ກວມເອົາຫຼາຍກວ່າ 4 ຕື້ບັນຊີທີ່ຖືກລະເມີດທີ່ປາກົດຢູ່ໃນຖານຂໍ້ມູນຜູ້ໃຊ້ທີ່ຮົ່ວໄຫຼ. ການເຕືອນໄພຈະຖືກສະແດງຂຶ້ນຖ້າທ່ານພະຍາຍາມໃຊ້ລະຫັດຜ່ານເລັກນ້ອຍເຊັ່ນ "abc123" (ໂດຍ ສະຖິຕິ Google 23% ຂອງຄົນອາເມລິກາໃຊ້ລະຫັດຜ່ານທີ່ຄ້າຍຄືກັນ), ຫຼືເມື່ອໃຊ້ລະຫັດຜ່ານດຽວກັນຢູ່ໃນຫຼາຍເວັບໄຊທ໌.

ເພື່ອຮັກສາຄວາມລັບ, ເມື່ອເຂົ້າເຖິງ API ພາຍນອກ, ພຽງແຕ່ສອງ bytes ທໍາອິດຂອງ hash ຂອງການເຂົ້າສູ່ລະບົບແລະລະຫັດຜ່ານຖືກສົ່ງ (ລະບົບ hashing algorithm ຖືກນໍາໃຊ້. Argon2). hash ເຕັມຈະຖືກເຂົ້າລະຫັດດ້ວຍລະຫັດທີ່ສ້າງຂຶ້ນໃນດ້ານຂອງຜູ້ໃຊ້. hashs ຕົ້ນສະບັບໃນຖານຂໍ້ມູນ Google ຍັງຖືກເຂົ້າລະຫັດເພີ່ມເຕີມແລະພຽງແຕ່ສອງ bytes ທໍາອິດຂອງ hash ໄດ້ຖືກປະໄວ້ສໍາລັບການດັດສະນີ. ການກວດສອບສຸດທ້າຍຂອງ hashes ທີ່ຕົກຢູ່ພາຍໃຕ້ຄໍານໍາຫນ້າສອງໄບທີ່ສົ່ງຜ່ານແມ່ນດໍາເນີນຢູ່ຂ້າງຜູ້ໃຊ້ໂດຍໃຊ້ເທກໂນໂລຍີ cryptographic "ຕາບອດ“, ເຊິ່ງທັງສອງຝ່າຍບໍ່ຮູ້ເນື້ອໃນຂອງຂໍ້ມູນທີ່ຖືກກວດສອບ. ເພື່ອປົກປ້ອງເນື້ອໃນຂອງຖານຂໍ້ມູນຂອງບັນຊີທີ່ຖືກປະນີປະນອມທີ່ຖືກກໍານົດໂດຍ brute force ກັບຄໍາຮ້ອງຂໍສໍາລັບຄໍານໍາຫນ້າໂດຍຕົນເອງມັກ, ຂໍ້ມູນທີ່ຖືກສົ່ງໄດ້ຖືກເຂົ້າລະຫັດໃນການເຊື່ອມຕໍ່ກັບລະຫັດທີ່ສ້າງຂຶ້ນບົນພື້ນຖານຂອງການປະສົມປະສານການເຂົ້າສູ່ລະບົບແລະລະຫັດຜ່ານ.

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