TL; DR
ການປະນີປະນອມ npm ຂອງ axios ສະແດງໃຫ້ເຫັນ ວິທີການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງທີ່ທັນສະໄໝ ໃຊ້ປະໂຫຍດຈາກ dependencies ທີ່ເຊື່ອຖືໄດ້ເພື່ອເຂົ້າເຖິງຂໍ້ມູນທີ່ລະອຽດອ່ອນໃນເວລາເຮັດວຽກ. ເຫດການນີ້ໄດ້ຖືກວິເຄາະໂດຍນັກຄົ້ນຄວ້າດ້ານຄວາມປອດໄພຫຼາຍຄົນ, ລວມທັງການແຍກລາຍລະອຽດຈາກ Unit42 ການຄຸ້ມຄອງອຸດສາຫະກໍາທີ່ເນັ້ນໃຫ້ເຫັນຮູບແບບການອ້າງອີງທີ່ກ່ຽວຂ້ອງກັບກິດຈະກໍາຂອງຊາດ.
ເຫດການນີ້ສົ່ງຜົນກະທົບຕໍ່:
- ທີມງານ DevOps ກຳລັງດຳເນີນການ CI/CD pipelines ດ້ວຍການພິສູດຢືນຢັນຕົວຕົນໂດຍອີງໃສ່ສະພາບແວດລ້ອມ
- ບໍລິການ Backend ທີ່ຈັດການຄຳຮ້ອງຂໍ API ທີ່ຖືກກວດສອບແລ້ວ
- ແອັບພລິເຄຊັນທີ່ໃຊ້ axios ສຳລັບການສື່ສານ HTTP ພາຍໃນ ແລະ ພາຍນອກ
ເນື່ອງຈາກ axios ຕັ້ງຢູ່ໃນຊັ້ນການຮ້ອງຂໍ, ລຸ້ນທີ່ຖືກລະເມີດສາມາດເຂົ້າເຖິງ:
- ຫົວຂໍ້ການອະນຸຍາດ ແລະ API tokens
- ຕົວແປ ແລະ ຄວາມລັບຂອງສະພາບແວດລ້ອມ
- ການສື່ສານການບໍລິການພາຍໃນ
ຜົນກະທົບທີ່ແທ້ຈິງບໍ່ແມ່ນການເພິ່ງພາອາໄສເອງ, ແຕ່ແມ່ນສິ່ງທີ່ມັນສາມາດເຂົ້າເຖິງໄດ້ເມື່ອຖືກປະຕິບັດແລ້ວ.
ການກະ ທຳ ທັນທີ:
- ລັອກລຸ້ນທີ່ຂຶ້ນກັບ ແລະ ກວດສອບການອັບເດດຫຼ້າສຸດ
- ໝູນວຽນລະຫັດ API, ໂທເຄັນ ແລະ CI/CD ສິດທິພິເສດ
- ຕິດຕາມຄຳຮ້ອງຂໍຂາອອກ ແລະ ກິດຈະກຳການກວດສອບຄວາມຖືກຕ້ອງ
- ການກວດສອບ pipelineສຳລັບຄວາມລັບທີ່ຖືກເປີດເຜີຍ
ສິ່ງທີ່ເກີດຂຶ້ນໃນການໂຈມຕີ Axios npm
ເຫດການ axios ຕິດຕາມຮູບແບບທີ່ເພີ່ມຂຶ້ນໃນການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງ, ບ່ອນທີ່ຜູ້ໂຈມຕີແນໃສ່ dependency ທີ່ໃຊ້ກັນຢ່າງກວ້າງຂວາງແທນທີ່ຈະເປັນຊ່ອງໂຫວ່ຂອງແອັບພລິເຄຊັນ.
ໂດຍການປະນີປະນອມແພັກເກດທີ່ເຊື່ອຖືໄດ້, ຜູ້ໂຈມຕີໄດ້ຮັບການປະຕິບັດພາຍໃນຫຼາຍພັນສະພາບແວດລ້ອມພ້ອມໆກັນ.
ເນື່ອງຈາກ axios ແມ່ນໜຶ່ງໃນລູກຄ້າ HTTP ທີ່ຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງທີ່ສຸດໃນລະບົບນິເວດ JavaScript, ມັນຈຶ່ງຖືກປະສົມປະສານຢ່າງເລິກເຊິ່ງເຂົ້າໃນ:
- ບໍລິການດ້ານຫຼັງ
- ແອັບພລິເຄຊັນດ້ານໜ້າ
- CI/CD pipelines
ນີ້ເຮັດໃຫ້ມັນເປັນເປົ້າໝາຍທີ່ມີມູນຄ່າສູງ.
ເມື່ອເວີຊັນທີ່ເປັນອັນຕະລາຍຖືກນຳສະເໜີ ແລະ ປະຕິບັດແລ້ວ, ມັນຈະສືບທອດສິດອະນຸຍາດດຽວກັນກັບແອັບພລິເຄຊັນທີ່ນຳເຂົ້າມັນ. ນັ້ນລວມທັງການເຂົ້າເຖິງການຈະລາຈອນເຄືອຂ່າຍ, ຂໍ້ມູນປະຈຳຕົວ ແລະ ການບໍລິການພາຍໃນ.
ການປະນີປະນອມດັ່ງກ່າວຍັງໄດ້ຮັບຄວາມສົນໃຈຢ່າງກວ້າງຂວາງນອກເໜືອໄປຈາກຊຸມຊົນຄວາມປອດໄພ, ໂດຍມີລາຍງານຕ່າງໆເຊັ່ນ Axios ການຄຸ້ມຄອງ
ຊີ້ໃຫ້ເຫັນເຖິງການເຊື່ອມໂຍງທີ່ເປັນໄປໄດ້ກັບຜູ້ກະທຳທີ່ເປັນໄພຂົ່ມຂູ່ຂັ້ນສູງ ແລະ ການໂຄສະນາທີ່ປະສານງານກັນ.
ສິ່ງທີ່ Axios Attack ເຮັດຕົວຈິງໃນເວລາແລ່ນ
ກຸນແຈສຳຄັນໃນການເຂົ້າໃຈການໂຈມຕີນີ້ແມ່ນການສຸມໃສ່ພຶດຕິກຳໃນເວລາແລ່ນ.
Axios ເຮັດວຽກຢູ່ຊັ້ນ HTTP, ຊຶ່ງໝາຍຄວາມວ່າມັນຈັດການກັບການຮ້ອງຂໍອອກ. ສິ່ງນີ້ເຮັດໃຫ້ມັນສາມາດເບິ່ງເຫັນຂໍ້ມູນທີ່ລະອຽດອ່ອນທີ່ໄຫຼຜ່ານແອັບພລິເຄຊັນໄດ້ໂດຍກົງ.
ລຸ້ນທີ່ຖືກທຳລາຍສາມາດ:
- ສະກັດກັ້ນການຮ້ອງຂໍທີ່ສົ່ງອອກກ່ອນທີ່ພວກມັນຈະຖືກສົ່ງໄປ
- capture
Authorizationຫົວຂໍ້ ແລະ ໂທເຄັນ API - ເຂົ້າເຖິງຕົວແປສະພາບແວດລ້ອມຜ່ານທາງ
process.env - ສັງເກດການສື່ສານລະຫວ່າງການບໍລິການພາຍໃນ
ຕົວຢ່າງ, ຕົວສະກັດກັ້ນທີ່ເປັນອັນຕະລາຍສາມາດສະກັດຫົວຂໍ້ການພິສູດຢືນຢັນຕົວຕົນ ແລະສົ່ງຕໍ່ພວກມັນໄປຫາຈຸດສິ້ນສຸດພາຍນອກຢ່າງງຽບໆ.
ໃນເວລາດຽວກັນ, ການເຂົ້າເຖິງຕົວແປສະພາບແວດລ້ອມຊ່ວຍໃຫ້ຜູ້ໂຈມຕີສາມາດດຶງເອົາຂໍ້ມູນປະຈຳຕົວໄດ້ໂດຍບໍ່ຕ້ອງດັດແປງເຫດຜົນຂອງແອັບພລິເຄຊັນ.
ຈາກພາຍນອກ, ທຸກຢ່າງຍັງສືບຕໍ່ເຮັດວຽກຕາມທີ່ຄາດໄວ້. ການຮ້ອງຂໍສຳເລັດແລ້ວ, ການບໍລິການຕອບສະໜອງຕາມປົກກະຕິ, ແລະ pipelineບໍ່ສະແດງອາການຂອງຄວາມລົ້ມເຫຼວ. ໃນເວລາດຽວກັນ, ຂໍ້ມູນທີ່ລະອຽດອ່ອນອາດຈະຖືກເປີດເຜີຍຜ່ານເສັ້ນທາງການປະຕິບັດພື້ນຫຼັງ.
Axios Attack Flow: ຈາກແພັກເກດທີ່ຖືກໂຈມຕີໄປສູ່ການເປີດເຜີຍລັບ
1. ປະນີປະນອມ
ຜູ້ໂຈມຕີໄດ້ຮັບການຄວບຄຸມບັນຊີຜູ້ຮັກສາທີ່ເຊື່ອຖືໄດ້ ຫຼື ເສັ້ນທາງການປ່ອຍແພັກເກດພາຍໃນລະບົບນິເວດ axios.
2. ການແຈກຢາຍ
ເວີຊັນທີ່ເປັນອັນຕະລາຍຖືກເຜີຍແຜ່ໄປຍັງ npm ແລະດຶງເຂົ້າໄປໃນເຄື່ອງຂອງນັກພັດທະນາ, CI/CD pipelines, ແລະແອັບພລິເຄຊັນສ້າງຂຶ້ນຜ່ານການອັບເດດການເພິ່ງພາອາໄສປົກກະຕິ.
3. ການປະຕິບັດເວລາແລ່ນ
payload ຈະປະຕິບັດເມື່ອ axios ຖືກນຳເຂົ້າ ແລະ ນຳໃຊ້, ໂດຍສືບທອດສິດທິພິເສດໃນເວລາແລ່ນດຽວກັນກັບແອັບພລິເຄຊັນ.
4. ການເຂົ້າເຖິງລັບ
ການເພິ່ງພາອາໄສທີ່ຖືກທຳລາຍຈະໄດ້ຮັບການເບິ່ງເຫັນຫົວຂໍ້, ໂທເຄັນ, ຕົວແປສະພາບແວດລ້ອມ ແລະ ການສື່ສານ HTTP ພາຍໃນ.
5. ການກັ່ນກອງ
ຂໍ້ມູນທີ່ລະອຽດອ່ອນຈະຖືກສົ່ງໄປຫາໂຄງສ້າງພື້ນຖານທີ່ຄວບຄຸມໂດຍຜູ້ໂຈມຕີຢ່າງງຽບໆ ໃນຂະນະທີ່ຄຳຮ້ອງຂໍເດີມຍັງສືບຕໍ່ເຮັດວຽກຕາມປົກກະຕິ.
ຕົວຊີ້ວັດຂອງການປະນີປະນອມ (IoCs)
ເພື່ອສືບສວນການເປີດເຜີຍທີ່ອາດເກີດຂຶ້ນ, ທີມງານຄວນເລີ່ມຕົ້ນດ້ວຍການທົບທວນຕົວຊີ້ວັດທີ່ຮູ້ຈັກທີ່ກ່ຽວຂ້ອງກັບການປະນີປະນອມ axios. ຕາຕະລາງຂ້າງລຸ່ມນີ້ສະຫຼຸບສັນຍານທີ່ກ່ຽວຂ້ອງທີ່ສຸດໃນທົ່ວແພັກເກດ, ກິດຈະກຳເຄືອຂ່າຍ, ແລະ ສິ່ງປະດິດຂອງໂຮດ.
ວິທີການຕີຄວາມໝາຍ IoC ເຫຼົ່ານີ້
ໃນຂະນະທີ່ຕົວຊີ້ວັດເຫຼົ່ານີ້ມີປະໂຫຍດ, ແຕ່ພວກມັນບໍ່ຄວນຖືກປະຕິບັດເປັນກົນລະຍຸດການກວດສອບທີ່ສົມບູນ.
ໃນທາງປະຕິບັດ, ການໂຈມຕີແບບນີ້ບໍ່ຄ່ອຍຈະອີງໃສ່ສັນຍານຄົງທີ່ດຽວ. ໂດເມນມີການປ່ຽນແປງ, payloads ພັດທະນາ, ແລະ hashs ກາຍເປັນລ້າສະໄໝຢ່າງໄວວາ. ສິ່ງທີ່ຍັງຄົງສອດຄ່ອງກັນແມ່ນພຶດຕິກຳ.
ຕົວຢ່າງ, ການຮ້ອງຂໍອອກທີ່ບໍ່ຄາດຄິດໃນລະຫວ່າງການປະຕິບັດ HTTP ປົກກະຕິສາມາດຊີ້ບອກເຖິງການລັກລອບຂໍ້ມູນ. ໃນລັກສະນະດຽວກັນ, ການໃຊ້ຂໍ້ມູນປະຈຳຕົວທີ່ຖືກຕ້ອງໃນສະພາບການທີ່ຜິດປົກກະຕິມັກຈະເປັນສັນຍານວ່າຄວາມລັບໄດ້ຖືກເປີດເຜີຍແລ້ວ.
ໃນລະດັບໂຮດ, ການມີສະຄຣິບຊົ່ວຄາວ ຫຼື ໄບນາຣີອາດຈະຊີ້ບອກເຖິງກິດຈະກຳຫຼັງການຂູດຮີດ, ໂດຍສະເພາະເມື່ອລວມກັບຄວາມຜິດປົກກະຕິຂອງເຄືອຂ່າຍ.
ເວົ້າອີກຢ່າງໜຶ່ງ, IoCs ຊ່ວຍໃຫ້ທ່ານຢືນຢັນເຫດການ.
ເຖິງຢ່າງໃດກໍ່ຕາມ, ການເຂົ້າໃຈພຶດຕິກຳແມ່ນສິ່ງທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດກວດພົບມັນໄດ້ແຕ່ຫົວທີ.
| ປະເພດ | ຕົວຊີ້ວັດ | ລາຍລະອຽດ |
|---|---|---|
| Package | axios@1.14.1 | ຊາຊຳ: 2553649f2322049666871cea80a5d0d6adc700ca |
| Package | axios@0.30.4 | ຊາຊຳ: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71 |
| ເພິ່ງພາອາໄສ | plain-crypto-js@4.2.1 | ຊາຊຳ: 07d889e2dadce6f3910dcbc253317d28ca61c766 |
| ເຄືອຂ່າຍ | sfrclak[.]com | ໂດເມນຄຳສັ່ງ ແລະ ການຄວບຄຸມ |
| ເຄືອຂ່າຍ | 142.11.206[.]73 | IP ພື້ນຖານໂຄງລ່າງທີ່ກ່ຽວຂ້ອງ |
| ເຄືອຂ່າຍ | http://sfrclak[.]com:8000/6202033 | ຈຸດສິ້ນສຸດຂອງການກອງທີ່ຖືກສັງເກດເຫັນ |
| MacOS | /Library/Caches/com.apple.act.mond | SHA256: 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a |
| Windows | %PROGRAMDATA%\wt.exe | ສິ່ງປະດິດທີ່ຄົງຢູ່ທີ່ມີທ່າແຮງ |
| Windows | %TEMP%\6202033.vbs | ສິ່ງປະດິດການປະຕິບັດທີ່ອີງໃສ່ສະຄຣິບ |
| Windows | %TEMP%\6202033.ps1 | ເພຼາຍເວວຂອງ PowerShell. SHA256: 617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101 |
| Linux | /tmp/ld.py | SHA256: fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf |
ບັນທຶກການສືບສວນ: IoC ເຫຼົ່ານີ້ແມ່ນຈຸດເລີ່ມຕົ້ນທີ່ເປັນປະໂຫຍດສຳລັບການລ່າສັດໄພຂົ່ມຂູ່. ເຖິງຢ່າງໃດກໍ່ຕາມ, ຜູ້ໂຈມຕີສາມາດໝູນວຽນໂດເມນ, payloads ແລະສິ່ງປະດິດໄດ້ຢ່າງວ່ອງໄວ. ດ້ວຍເຫດຜົນດັ່ງກ່າວ, ທີມງານຄວນເຊື່ອມໂຍງຕົວຊີ້ວັດເຫຼົ່ານີ້ກັບສັນຍານພຶດຕິກຳເຊັ່ນ: ການຈະລາຈອນ HTTP ຂາອອກທີ່ບໍ່ຄາດຄິດ, ການເຂົ້າເຖິງທີ່ຜິດປົກກະຕິ process.env, ແລະ ການອັບເດດການເພິ່ງພາອາໄສທີ່ຜິດປົກກະຕິ.
ຕົວຢ່າງ: ວິທີການທີ່ການເພິ່ງພາອາໄສ npm ຂອງ Axios ທີ່ຖືກທຳລາຍສາມາດກັ່ນຕອງຂໍ້ມູນໄດ້
ເພື່ອເຂົ້າໃຈວ່າການໂຈມຕີ Axios npm ນີ້ເຮັດວຽກແນວໃດໃນການປະຕິບັດ, ໃຫ້ພິຈາລະນາຕົວຢ່າງທີ່ງ່າຍດາຍ.
Axios ອະນຸຍາດໃຫ້ນັກພັດທະນາກຳນົດຕົວຮັບຄຳຮ້ອງຂໍ. ຕົວຮັບເຫຼົ່ານີ້ຈະປະຕິບັດໂດຍອັດຕະໂນມັດກ່ອນແຕ່ລະຄຳຮ້ອງຂໍ HTTP.
axios ລຸ້ນທີ່ເປັນອັນຕະລາຍສາມາດໃຊ້ກົນໄກນີ້ໄດ້ໃນທາງທີ່ຜິດ:
ເປັນຫຍັງການໂຈມຕີ Axios npm ຈຶ່ງເປັນອັນຕະລາຍ
ເມື່ອເບິ່ງໃນເບື້ອງຕົ້ນ, ເບິ່ງຄືວ່າບໍ່ມີຫຍັງຜິດປົກກະຕິ. ການຮ້ອງຂໍໄດ້ຖືກປະຕິບັດສຳເລັດແລ້ວ, ແອັບພລິເຄຊັນເຮັດວຽກຕາມທີ່ຄາດໄວ້, ແລະ pipelines ສືບຕໍ່ຜ່ານໄປໂດຍບໍ່ມີຂໍ້ຜິດພາດ.
ເຖິງຢ່າງໃດກໍ່ຕາມ, ລາຍລະອຽດທີ່ສຳຄັນຈະເກີດຂຶ້ນກ່ອນທີ່ຄຳຮ້ອງຂໍຈະຖືກສົ່ງໄປ. ໃນລະຫວ່າງໄລຍະເວລາການປະຕິບັດນັ້ນ, ການເພິ່ງພາອາໄສທີ່ຖືກທຳລາຍສາມາດເຂົ້າເຖິງ ແລະ ເກັບກຳຂໍ້ມູນທີ່ລະອຽດອ່ອນໄດ້ຢ່າງງຽບໆ ເຊັ່ນ: ຫົວຂໍ້ການອະນຸຍາດ, ໂທເຄັນ API, ຂໍ້ມູນເມຕາຂອງຄຳຮ້ອງຂໍ ແລະ ຕົວແປສະພາບແວດລ້ອມ.
ເນື່ອງຈາກເຫດຜົນນີ້ເຮັດວຽກພາຍໃນຫ້ອງສະໝຸດທີ່ເຊື່ອຖືໄດ້ເຊິ່ງຕັ້ງຢູ່ໃນເສັ້ນທາງການຮ້ອງຂໍ HTTP ໂດຍກົງ, ມັນຈຶ່ງເຮັດວຽກຢ່າງມີປະສິດທິພາບດ້ວຍສິດທິພິເສດດຽວກັນກັບແອັບພລິເຄຊັນເອງ. ດັ່ງນັ້ນ, ມັນສາມາດເຂົ້າເຖິງຂໍ້ມູນທີ່ປົກກະຕິແລ້ວຈະຖືກປົກປ້ອງຈາກຜູ້ໂຈມຕີພາຍນອກ.
ສິ່ງທີ່ເຮັດໃຫ້ສິ່ງນີ້ເປັນອັນຕະລາຍໂດຍສະເພາະບໍ່ພຽງແຕ່ການເຂົ້າເຖິງຂໍ້ມູນເທົ່ານັ້ນ, ແຕ່ຍັງຂາດຜົນກະທົບທີ່ເຫັນໄດ້ຊັດເຈນ. ບໍ່ມີການລົບກວນໃນການເຮັດວຽກ, ບໍ່ມີການຮ້ອງຂໍທີ່ລົ້ມເຫຼວ, ແລະບໍ່ມີສັນຍານທັນທີວ່າມີບາງຢ່າງຜິດພາດ. ຈາກທັດສະນະການດຳເນີນງານ, ທຸກຢ່າງຍັງສືບຕໍ່ເຮັດວຽກຕາມທີ່ຄາດໄວ້.
ໃນຂະນະດຽວກັນ, ຂໍ້ມູນທີ່ລະອຽດອ່ອນອາດຈະອອກຈາກລະບົບແລ້ວຜ່ານການເຊື່ອມຕໍ່ອອກທີ່ປະສົມປະສານກັບການເຂົ້າຊົມແອັບພລິເຄຊັນປົກກະຕິ.
ເປັນຫຍັງນີ້ຈຶ່ງເປັນບັນຫາ DevOps ກ່ອນ
ສຳລັບທີມງານ DevOps, ການໂຈມຕີປະເພດນີ້ແມ່ນຍາກທີ່ຈະກວດພົບໂດຍສະເພາະ ເພາະມັນປະສົມປະສານເຂົ້າກັບຂະບວນການເຮັດວຽກທີ່ມີຢູ່ແລ້ວຢ່າງບໍ່ມີຂໍ້ບົກຜ່ອງ.
ການຕິດຕັ້ງ dependencies ໂດຍອັດຕະໂນມັດ, pipelines ດຳເນີນການຕາມປົກກະຕິ, ແລະບໍ່ມີຄວາມລົ້ມເຫຼວໃນທັນທີ.
ໃນເວລາດຽວກັນ, CI/CD ສະພາບແວດລ້ອມມັກຈະເປີດເຜີຍຂໍ້ມູນປະຈຳຕົວທີ່ມີມູນຄ່າສູງ, ລວມທັງ:
- ໂທເຄັນຜູ້ໃຫ້ບໍລິການຄລາວ
- ລະຫັດການນຳໃຊ້
- CI/CD ຄວາມລັບໃນການພິສູດຢືນຢັນຕົວຕົນ
ການເພິ່ງພາອາໄສທີ່ຖືກລະເມີດເຊິ່ງເຮັດວຽກຢູ່ໃນບໍລິບົດນີ້ສາມາດເຂົ້າເຖິງຂໍ້ມູນປະຈຳຕົວເຫຼົ່ານັ້ນໄດ້ໂດຍກົງ.
ສິ່ງນີ້ສ້າງສະຖານະການທີ່ທຸກຢ່າງເບິ່ງຄືວ່າປົກກະຕິ, ໃນຂະນະທີ່ຂໍ້ມູນທີ່ລະອຽດອ່ອນກຳລັງຖືກເຂົ້າເຖິງຢູ່ໃນພື້ນຫຼັງ.
ຄວາມສ່ຽງທີ່ແທ້ຈິງ: ການເປີດເຜີຍຄວາມລັບໃນຂອບເຂດທີ່ກວ້າງຂວາງ
ການປະນີປະນອມ npm ຂອງ axios ເນັ້ນໃຫ້ເຫັນເຖິງການປ່ຽນແປງທີ່ສຳຄັນໃນຍຸດທະສາດການໂຈມຕີທີ່ທັນສະໄໝ.
ເປົ້າໝາຍບໍ່ແມ່ນເພື່ອໃຊ້ປະໂຫຍດຈາກຊ່ອງໂຫວ່ອີກຕໍ່ໄປ, ແຕ່ເພື່ອເຂົ້າເຖິງຂໍ້ມູນປະຈຳຕົວທີ່ຖືກຕ້ອງ.
ເນື່ອງຈາກລະບົບທີ່ທັນສະໄໝອາໄສການພິສູດຢືນຢັນຕົວຕົນໂດຍອີງໃສ່ສະພາບແວດລ້ອມ, ການເພິ່ງພາອາໄສທີ່ເຮັດວຽກໃນເວລາແລ່ນສາມາດເຂົ້າເຖິງ:
- ກະແຈ API
- ໂທເຄັນການບໍລິການ
- ຂໍ້ມູນປະຈຳຕົວຄລາວ
ຂໍ້ມູນປະຈຳຕົວເຫຼົ່ານີ້ບໍ່ຈຳເປັນຕ້ອງຖືກທຳລາຍ.
ພວກເຂົາພຽງແຕ່ຕ້ອງການໃຊ້ເທົ່ານັ້ນ.
ສິ່ງນີ້ຊ່ວຍໃຫ້ຜູ້ໂຈມຕີສາມາດເຄື່ອນຍ້າຍໄປທາງຂ້າງ, ເຂົ້າເຖິງການບໍລິການ ແລະ ສະກັດຂໍ້ມູນໂດຍໃຊ້ການກວດສອບຄວາມຖືກຕ້ອງທີ່ຖືກຕ້ອງ.
ດັ່ງນັ້ນ, ຜົນກະທົບຈຶ່ງຂຶ້ນກັບຄວາມລັບທີ່ຖືກເປີດເຜີຍ, ບໍ່ແມ່ນວິທີການໂຈມຕີ.
ເປັນຫຍັງເຄື່ອງມືຄວາມປອດໄພແບບດັ້ງເດີມຈຶ່ງພາດສິ່ງນີ້
ວິທີການແບບດັ້ງເດີມມີຄວາມຫຍຸ້ງຍາກໃນການກວດຫາການໂຈມຕີເຫຼົ່ານີ້ ເພາະວ່າພວກມັນສຸມໃສ່ຊ່ອງໂຫວ່ທີ່ຮູ້ຈັກ ຫຼື ລາຍເຊັນຄົງທີ່. ຢ່າງໃດກໍຕາມ, ດັ່ງທີ່ໄດ້ເນັ້ນໃຫ້ເຫັນໃນ ການວິເຄາະຂອງ OpenAI ຂອງການປະນີປະນອມຂອງເຄື່ອງມືນັກພັດທະນາ axios, ຄວາມສ່ຽງທີ່ແທ້ຈິງຈະເກີດຂຶ້ນໃນເວລາແລ່ນ, ບ່ອນທີ່ການເພິ່ງພາອາໄສທີ່ເຊື່ອຖືໄດ້ພົວພັນກັບຂໍ້ມູນທີ່ລະອຽດອ່ອນ.
ເຖິງຢ່າງໃດກໍ່ຕາມ, ການເພິ່ງພາອາໄສທີ່ຖືກທຳລາຍອາດຈະບໍ່ມີຕົວຊີ້ບອກທີ່ຊັດເຈນໃດໆ.
ອາດຈະມີ:
- ບໍ່ມີ CVE
- ບໍ່ມີລາຍເຊັນທີ່ເປັນອັນຕະລາຍ
- ບໍ່ມີໄວຍາກອນຜິດປົກກະຕິ
ໃນເວລາດຽວກັນ, ການວິເຄາະແບບຄົງທີ່ບໍ່ໄດ້ປະເມີນພຶດຕິກຳໃນເວລາແລ່ນ. ມັນບໍ່ສາມາດກຳນົດວ່າການເພິ່ງພາອາໄສພົວພັນກັບຂໍ້ມູນທີ່ລະອຽດອ່ອນແນວໃດເມື່ອຖືກປະຕິບັດແລ້ວ.
ສິ່ງນີ້ສ້າງຊ່ອງຫວ່າງທີ່ລະຫັດເບິ່ງຄືວ່າປອດໄພໃນລະຫວ່າງການວິເຄາະແຕ່ກາຍເປັນມີຄວາມສ່ຽງໃນລະຫວ່າງການປະຕິບັດ.
ວິທີການກວດຫາ ແລະ ປ້ອງກັນການໂຈມຕີແບບ npm ຂອງ Axios
ການປ້ອງກັນການໂຈມຕີ Axios npm ປະເພດນີ້ຮຽກຮ້ອງໃຫ້ມີການປ່ຽນຈາກການກວດສອບແບບຄົງທີ່ໄປສູ່ການຮັບຮູ້ເວລາແລ່ນ.
ທີມງານຕ້ອງການການເບິ່ງເຫັນວ່າ dependency ປະຕິບັດແນວໃດ, ບໍ່ພຽງແຕ່ສິ່ງທີ່ພວກມັນມີຢູ່ເທົ່ານັ້ນ.
ນີ້ປະກອບມີ:
- ການຕິດຕາມການເຂົ້າເຖິງຂໍ້ມູນທີ່ລະອຽດອ່ອນໃນເວລາແລ່ນ
- ການກວດຫາຄວາມລັບກ່ອນທີ່ພວກມັນຈະໄປຮອດບ່ອນເກັບມ້ຽນ
- ການສະແກນ pipelineແລະ ສິ່ງປະດິດສຳລັບຂໍ້ມູນປະຈຳຕົວທີ່ຖືກເປີດເຜີຍ
- ການສັງເກດກິດຈະກຳເຄືອຂ່າຍອອກເພື່ອຫາຄວາມຜິດປົກກະຕິ
ຢ່າງໃດກໍຕາມ, ການກວດພົບຢ່າງດຽວບໍ່ພຽງພໍ.
ຈາກການກວດພົບຫາການປ້ອງກັນ: ສິ່ງທີ່ຊ່ວຍຫຼຸດຜ່ອນຄວາມສ່ຽງໄດ້ແທ້
ຫຼັງຈາກເຫດການແບບນີ້, ທີມງານມັກຈະປະເຊີນກັບຂໍ້ມູນປະຈຳຕົວທີ່ອາດຈະຖືກເປີດເຜີຍຈຳນວນຫຼວງຫຼາຍ.
ສິ່ງທ້າທາຍບໍ່ແມ່ນການຊອກຫາພວກມັນ. ແຕ່ມັນແມ່ນການລະບຸວ່າອັນໃດສຳຄັນ.
ຄຳຖາມຫຼັກກາຍເປັນ:
ຄວາມລັບໃດແດ່ທີ່ຍັງຖືກຕ້ອງ ແລະ ສາມາດນຳໃຊ້ໄດ້?
ຖ້າບໍ່ມີການຢືນຢັນ, ທີມງານຈະໃຊ້ເວລາກັບຂໍ້ມູນປະຈຳຕົວທີ່ບໍ່ມີການເຄື່ອນໄຫວ ໃນຂະນະທີ່ຄວາມສ່ຽງທີ່ແທ້ຈິງຍັງຄົງເປີດຢູ່.
ການຕອບສະໜອງທີ່ມີປະສິດທິພາບຮຽກຮ້ອງໃຫ້ມີ:
- ການກວດຈັບຄວາມລັບທີ່ຖືກເປີດເຜີຍ
- ກຳລັງຢືນຢັນວ່າພວກເຂົາຍັງໃຫ້ສິດການເຂົ້າເຖິງຢູ່ຫຼືບໍ່
- ຍົກເລີກ ຫຼື ໝູນວຽນພວກມັນຢ່າງໄວວາ
ສິ່ງນີ້ຊ່ວຍຫຼຸດຜ່ອນເວລາການເປີດເຜີຍ ແລະ ຈຳກັດໄລຍະເວລາຂອງຜູ້ໂຈມຕີ.
ວິທີທີ່ Xygeni ຊ່ວຍຫຼຸດຜ່ອນຄວາມສ່ຽງຕໍ່ລະບົບຕ່ອງໂສ້ການສະໜອງ
ຊີເກນີ ແກ້ໄຂບັນຫານີ້ໂດຍການລວມເອົາການກວດຈັບ, ການກວດສອບ ແລະ ການແກ້ໄຂເຂົ້າກັນເປັນຂະບວນການເຮັດວຽກດຽວ.
ມັນລະບຸຄວາມລັບທີ່ຖືກເປີດເຜີຍຢ່າງຕໍ່ເນື່ອງໃນທົ່ວລະຫັດ, pipelines, ແລະສິ່ງປະດິດຕ່າງໆ. ໃນເວລາດຽວກັນ, ມັນກວດສອບວ່າຂໍ້ມູນປະຈຳຕົວເຫຼົ່ານັ້ນຍັງມີການເຄື່ອນໄຫວຢູ່ໃນສະພາບແວດລ້ອມຫຼືບໍ່.
ສິ່ງນີ້ຊ່ວຍໃຫ້ທີມງານສາມາດສຸມໃສ່ສິ່ງທີ່ຜູ້ໂຈມຕີສາມາດໃຊ້ໄດ້ແທ້ໆ.
ເມື່ອຄວາມລັບທີ່ໃຊ້ງານຢູ່ຖືກລະບຸແລ້ວ, ຂັ້ນຕອນການແກ້ໄຂອັດຕະໂນມັດຈະຊ່ວຍຫຼຸດຜ່ອນເວລາການເປີດເຜີຍຜ່ານການຍົກເລີກ ຫຼື ການໝູນວຽນທີ່ຄວບຄຸມໄດ້.
ດ້ວຍເຫດນີ້, ການຕອບສະໜອງຈຶ່ງໄວຂຶ້ນ, ມີຄວາມຊັດເຈນຫຼາຍຂຶ້ນcisອີ, ແລະ ມີການລົບກວນໜ້ອຍລົງ.
ສະຫຼຸບ
ການປະນີປະນອມ npm ຂອງ axios ສະທ້ອນໃຫ້ເຫັນວ່າການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງກຳລັງພັດທະນາແນວໃດ.
ຜູ້ໂຈມຕີບໍ່ຈຳເປັນຕ້ອງທຳລາຍລະບົບອີກຕໍ່ໄປ. ພວກເຂົາອາໄສ dependencies ທີ່ເຊື່ອຖືໄດ້ເພື່ອເຂົ້າເຖິງຂໍ້ມູນທີ່ລະອຽດອ່ອນໃນລະຫວ່າງການປະຕິບັດ.
ສຳລັບທີມງານ DevOps, ນີ້ໝາຍເຖິງການເຂົ້າໃຈພຶດຕິກຳໃນເວລາແລ່ນ. ສຳລັບຜູ້ນຳດ້ານຄວາມປອດໄພ, ມັນໝາຍເຖິງການຫຼຸດຜ່ອນການເປີດເຜີຍຢ່າງວ່ອງໄວ ແລະ ມີປະສິດທິພາບ.
ເນື່ອງຈາກວ່າໃນສະພາບແວດລ້ອມທີ່ທັນສະໄໝ, ຄວາມສ່ຽງທີ່ໃຫຍ່ທີ່ສຸດບໍ່ແມ່ນສິ່ງທີ່ຖືກປະຕິບັດ.
ມັນແມ່ນສິ່ງທີ່ສາມາດເຂົ້າເຖິງໄດ້ເມື່ອມັນດໍາເນີນການ.
