ຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບເກີດຂຶ້ນເມື່ອແອັບພລິເຄຊັນ, API ຫຼື CI/CD pipeline ໃຊ້ຫົວຂໍ້ User-Agent ເພື່ອສ້າງການພິສູດຢືນຢັນຕົວຕົນ ຫຼື ການອະນຸມັດcision, ເຖິງແມ່ນວ່າຫົວຂໍ້ນັ້ນເປັນສະຕຣິງທີ່ລູກຄ້າສະໜອງໃຫ້ ເຊິ່ງຄຳຮ້ອງຂໍໃດໆກໍ່ສາມາດຂຽນຄືນໃໝ່ໄດ້ຢ່າງເສລີ.
ຄວາມສ່ຽງທີ່ເຊື່ອງໄວ້ຢູ່ເບື້ອງຫຼັງຄວາມໄວ້ວາງໃຈຂອງຕົວແທນຜູ້ໃຊ້
ແອັບເວັບຫຼາຍໆອັນ, APIs, ແລະ CI/CD ລະບົບຍັງຄົງໄວ້ວາງໃຈຫົວຂໍ້ User-Agent ເພື່ອລະບຸວ່າໃຜກຳລັງເຮັດການຮ້ອງຂໍ, ເຊິ່ງເປັນສົມມຸດຕິຖານທີ່ຍັງເຫຼືອຈາກຍຸກຕົ້ນໆຂອງເວັບ. ແຕ່ໃນ ໂລກ DevSecOps, ສົມມຸດຕິຖານນັ້ນເປັນອັນຕະລາຍ. ຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບຈະປາກົດຂຶ້ນທຸກຄັ້ງທີ່ລະຫັດ, pipelines, ຫຼື APIs ໃຊ້ສະຕຣິງ User-Agent ເພື່ອນຳໃຊ້ເຫດຜົນ ຫຼື ບັງຄັບໃຊ້ນະໂຍບາຍຄວາມປອດໄພ. ຕົວຢ່າງ:
- API ການສ້າງອາດຈະອະນຸຍາດໃຫ້ມີການຮ້ອງຂໍຈາກ "ຕົວແທນທີ່ເຊື່ອຖືໄດ້" ເທົ່ານັ້ນ.
- ບ່ອນເກັບມ້ຽນສິ່ງປະດິດອາດຈະເພີ່ມຕົວແທນຜູ້ໃຊ້ສະເພາະເຂົ້າໃນລາຍຊື່ອະນຸຍາດ.
- ຕົວກອງຄວາມປອດໄພອາດຈະບລັອກ ຫຼື ຈຳກັດອັດຕາການຮ້ອງຂໍໂດຍອີງໃສ່ຫົວຂໍ້.
ແຕ່ຫົວຂໍ້ User-Agent ເປັນພຽງສະຕຣິງ, ເຊິ່ງຜູ້ໂຈມຕີສາມາດດັດແປງໄດ້.
⚠️ ຕົວຢ່າງທີ່ບໍ່ປອດໄພ, ສຳລັບຈຸດປະສົງດ້ານການສຶກສາເທົ່ານັ້ນ. ຫ້າມໃຊ້ໃນການຜະລິດ.
ຖ້າ backend ຂອງທ່ານ ຫຼື pipeline ເຫດຜົນສົມມຸດວ່າສະຕຣິງ User-Agent ລະບຸແຫຼ່ງທີ່ເຊື່ອຖືໄດ້, ທ່ານໄດ້ສ້າງຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບທີ່ສາມາດນໍາໄປສູ່ການປະນີປະນອມລະບົບຕ່ອງໂສ້ການສະໜອງແລ້ວ.
ວິທີການທີ່ການປອມແປງຕົວແທນຜູ້ໃຊ້ເຮັດວຽກໃນການປະຕິບັດ
ການປອມແປງຕົວແທນຜູ້ໃຊ້ສາມາດເປັນແບບງ່າຍໆຄືກັບສ່ວນຂະຫຍາຍຂອງໂປຣແກຣມທ່ອງເວັບ, ລູກຄ້າ HTTP ທີ່ຖືກດັດແປງ, ຫຼືບັອດອັດຕະໂນມັດທີ່ຖືກຕັ້ງຄ່າໃຫ້ລອກລຽນແບບການຈະລາຈອນການສ້າງທີ່ຖືກຕ້ອງ.
ຜູ້ໂຈມຕີໃຊ້ການປອມແປງຕົວແທນຜູ້ໃຊ້ເພື່ອ:
- ຂ້າມຕົວກອງການເຂົ້າເຖິງໃນ API ທີ່ໄວ້ວາງໃຈຫົວຂໍ້ສະເພາະ
- ປອມແປງລະບົບການສ້າງ (ເຊັ່ນ: Jenkins, GitHub Actions, ຫຼື GitLab Runners)
- ຂໍ້ຈຳກັດອັດຕາການຫຼົບຫຼີກ ຫຼື ເຄື່ອງມືວິເຄາະຄວາມປອດໄພ
- ການກະທຳຂອງ backend ທີ່ກະຕຸ້ນໃຫ້ສະເພາະຕົວແທນ "ທີ່ໄດ້ຮັບອະນຸຍາດ".
// Attacker sets the User-Agent to impersonate a trusted CI system
curl -A "Jenkins-Agent/2.4" https://internal-api.example.com/build/trigger// Instead of trusting the header, validate a signed request token
if not verify_signature(request.headers["X-Signature"], shared_secret):
reject(request)ການປອມແປງຕົວແທນຜູ້ໃຊ້ແມ່ນບໍ່ສຳຄັນ; ການຢືນຢັນຕົວຕົນທີ່ແທ້ຈິງບໍ່ແມ່ນ.
ຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບທີ່ແທ້ຈິງໃນ CI/CD ແລະ ລະບົບຕ່ອງໂສ້ການສະໜອງ
ຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບຈະກາຍເປັນສິ່ງສຳຄັນຫຼາຍເມື່ອມັນສົ່ງຜົນກະທົບຕໍ່ໂຄງສ້າງພື້ນຖານການສ້າງ ຫຼື ການຈັດສົ່ງສິ່ງປະດິດ pipelines. ໃນ CI/CD ສະພາບແວດລ້ອມ, ການຮ້ອງຂໍມັກຈະມາຈາກຕົວແທນອັດຕະໂນມັດ, ແລະຜູ້ໂຈມຕີໃຊ້ປະໂຫຍດຈາກຂອບເຂດຄວາມໄວ້ວາງໃຈນັ້ນ. ຕົວຢ່າງຕົວຈິງລວມມີ:
- ການຮ້ອງຂໍການສ້າງປອມໄປຫາທະບຽນສິ່ງປະດິດ
- ການລ່ວງລະເມີດກະຈົກການເພິ່ງພາອາໄສ
- Pipeline ການປອມແປງ
// Registry verifies a signed provenance attestation instead of trusting a header
if not verify_attestation(request.artifact, build_provenance):
reject_artifact_upload(request)ຄຳຮ້ອງຂໍທີ່ຖືກປອມແປງພຽງຄັ້ງດຽວສາມາດສັກເອົາການເພິ່ງພາອາໄສທີ່ເປັນອັນຕະລາຍເຂົ້າໃນການຜະລິດໂດຍກົງໄດ້ pipelines, ຕົວຢ່າງທີ່ດີຂອງຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບທີ່ນໍາໄປສູ່ການລະເມີດລະບົບຕ່ອງໂສ້ການສະໜອງ.
ເປັນຫຍັງການກວດສອບຫົວຂໍ້ພື້ນຖານຈຶ່ງລົ້ມເຫລວໃນຖານະເປັນການຄວບຄຸມຄວາມປອດໄພ
ບາງຄັ້ງນັກພັດທະນາອາໄສຕົວກອງ regex ທີ່ອີງໃສ່ຫົວຂໍ້ ຫຼື ລາຍຊື່ອະນຸຍາດຄົງທີ່ເພື່ອກວດສອບຄວາມຖືກຕ້ອງຂອງຄຳຮ້ອງຂໍຂອງຕົວແທນ. ແຕ່ຫນ້າເສຍດາຍ, ສິ່ງນີ້ບໍ່ໄດ້ໃຫ້ການປົກປ້ອງໃດໆຈາກການປອມແປງຕົວແທນຜູ້ໃຊ້. ການກວດສອບແບບຄົງທີ່ເຊັ່ນ:
⚠️ ການກວດສອບຄວາມຖືກຕ້ອງໂດຍອີງໃສ່ Regex ບໍ່ແມ່ນການກວດສອບຄວາມຖືກຕ້ອງ. ຜູ້ໂຈມຕີໃດໆກໍ່ສາມາດລອກແບບຮູບແບບທີ່ຄາດໄວ້ດ້ວຍສະຕຣິງ User-Agent ປອມແປງໄດ້.
ສາມາດຂ້າມໄດ້ງ່າຍໆດ້ວຍ:
ເຫດຜົນແບບນີ້ນຳໄປສູ່ຄວາມໄວ້ວາງໃຈທີ່ບໍ່ຖືກຕ້ອງ ແລະ ຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບສູງ ເພາະວ່າບໍ່ມີຫຍັງພິສູດໄດ້ວ່າຜູ້ສົ່ງແມ່ນຄົນທີ່ມັນອ້າງວ່າເປັນ.
ການເສີມສ້າງການກວດສອບຄວາມຖືກຕ້ອງດ້ວຍຄຳຮ້ອງຂໍທີ່ລົງນາມ ແລະ ຄວາມສົມບູນຂອງສິ່ງປະດິດ - ຫຼີກລ່ຽງຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບ
ແທນທີ່ຈະໄວ້ວາງໃຈຄ່າ User-Agent, ນັກພັດທະນາຄວນກວດສອບແຫຼ່ງທີ່ມາຂອງທຸກໆຄຳຮ້ອງຂໍຜ່ານການກວດສອບລະຫັດລັບ ແລະ ການກວດສອບສະພາບການ. ຍຸດທະສາດຫຼັກເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບລວມມີ:
- TLS ເຊິ່ງກັນແລະກັນ (mTLS)
- ຂໍ້ມູນເມຕາ ຫຼື ຄຳຮ້ອງຂໍທີ່ເຊັນແລ້ວ (AWS SigV4, HMAC, JWT)
- ການເຊັນ ແລະ ການຢັ້ງຢືນສິ່ງປະດິດ
- ໂທເຄັນ API ທີ່ມີຂອບເຂດ
- ການຢັ້ງຢືນນອກແຖບຄວາມຖີ່
ຂັ້ນຕອນເຫຼົ່ານີ້ຮັບປະກັນວ່າເຖິງແມ່ນວ່າຕົວແທນຜູ້ໃຊ້ຈະລອກລຽນແບບຫົວຂໍ້ທີ່ເຊື່ອຖືໄດ້, ລະບົບຈະປະຕິເສດການຈະລາຈອນທີ່ບໍ່ໄດ້ຮັບການພິສູດຢືນຢັນ ຫຼື ບໍ່ໄດ້ເຊັນ.
ການລວມການກວດຈັບ ແລະ ການປ້ອງກັນເຂົ້າໃນ DevSecOps Pipelines
ການກວດຈັບການປອມແປງຕົວແທນຜູ້ໃຊ້ຄວນເປັນສ່ວນໜຶ່ງຂອງທ່ານ CI/CD telemetry ແລະການກວດສອບຄວາມຖືກຕ້ອງຢ່າງຕໍ່ເນື່ອງ.
ທີມງານ DevSecOps ສາມາດຝັງການຄວບຄຸມໄດ້ເຊັ່ນ:
- ການກວດສອບຄຳຮ້ອງຂໍອັດຕະໂນມັດ
- ສຳພັນກັນທາງໄກ
- ການກວດຫາຜິດລັກ
- ການບັງຄັບໃຊ້ນະໂຍບາຍຕາມສະພາບການ
// CI step fails the build if request signatures aren't verified
- name: Verify request provenance
run: xygeni verify-attestation --fail-on unsignedການລວມການກວດຈັບ ແລະ ການບັງຄັບໃຊ້ນະໂຍບາຍເຂົ້າກັນຮັບປະກັນວ່າຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບຈະບໍ່ສົ່ງຜົນກະທົບຕໍ່ທ່ານຢ່າງງຽບໆ pipelines ຫຼື ການແຈກຢາຍສິ່ງປະດິດ.
ຢ່າໄວ້ວາງໃຈຫົວຂໍ້, ກວດສອບແຫຼ່ງຂໍ້ມູນ
ທຸກ ຕົວແທນຜູ້ໃຊ້ ຫົວຂໍ້ສາມາດຕົວະໄດ້. ຕົວປອມແປງຕົວແທນຜູ້ໃຊ້ທຸກຄົນສາມາດປອມແປງຄວາມຖືກຕ້ອງໄດ້. ແລະຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງຕົວແທນໂປຣແກຣມທ່ອງເວັບທຸກຢ່າງແມ່ນມາຈາກການໄວ້ວາງໃຈບາງສິ່ງບາງຢ່າງທີ່ບໍ່ໄດ້ຮັບການຢັ້ງຢືນ. ການແກ້ໄຂບໍ່ແມ່ນກ່ຽວກັບການລຶບຫົວຂໍ້; ມັນກ່ຽວກັບການບໍ່ໄວ້ວາງໃຈມັນສຳລັບການກວດສອບຄວາມຖືກຕ້ອງ ຫຼື ການບັງຄັບໃຊ້ນະໂຍບາຍ. ແທນທີ່ຈະ, ໃຫ້ປະຕິບັດຄຳຮ້ອງຂໍທີ່ລົງນາມ, ບັງຄັບໃຊ້ການກວດສອບຕົວຕົນ, ແລະ ຕິດຕາມກວດກາຂອງທ່ານ CI/CD ການຈະລາຈອນ ສຳລັບຮູບແບບການຫຼອກລວງ.
ຊີເຈນີ Build Security ກວດສອບຄວາມສົມບູນຂອງການສ້າງຜ່ານການເຊັນສິ່ງປະດິດແບບບໍ່ໃຊ້ກະແຈ ແລະ SLSA provenance, ສະນັ້ນຄຳຮ້ອງຂໍ ຫຼື ສິ່ງປະດິດຈຶ່ງເຊື່ອຖືໄດ້ເພາະວ່າມັນໄດ້ຮັບການຢັ້ງຢືນແບບເຂົ້າລະຫັດ, ບໍ່ແມ່ນຍ້ອນຫົວຂໍ້ທີ່ມັນສົ່ງມາ. ການກວດຫາຄວາມຜິດປົກກະຕິຂອງ Xygeni ຊັ້ນຕິດຕາມກວດກາພຶດຕິກຳຢູ່ເທິງສຸດ, ລາຍງານກິດຈະກຳທີ່ຜິດປົກກະຕິໃນທົ່ວຂອງທ່ານ CI/CD ພື້ນຖານໂຄງລ່າງ, ຄືກັບວຽກ ຫຼື ຕົວແທນທີ່ປະຕິບັດຢູ່ນອກຮູບແບບປົກກະຕິຂອງມັນ, ໃນເວລາຈິງ.
ຢ່າອີງໃສ່ການສົມມຸດຕິຖານ, ໃຫ້ກວດສອບທຸກໆແຫຼ່ງຂໍ້ມູນ. ເລີ່ມຕົ້ນໂດຍບໍ່ເສຍຄ່າ. ບໍ່ມີບັດເຄຣດິດທີ່ຈໍາເປັນ.
FAQ
ເປັນຫຍັງການໄວ້ວາງໃຈຫົວຂໍ້ User-Agent ຈຶ່ງມີຄວາມສ່ຽງດ້ານຄວາມປອດໄພ?
ເນື່ອງຈາກມັນເປັນສະຕຣິງທຳມະດາທີ່ລູກຄ້າສົ່ງ, ແລະລູກຄ້າ HTTP, ສ່ວນຂະຫຍາຍຂອງໂປຣແກຣມທ່ອງເວັບ, ຫຼືສະຄຣິບໃດໆກໍ່ສາມາດຕັ້ງຄ່າມັນເປັນຄ່າໃດກໍໄດ້ທີ່ມັນຕ້ອງການ. ມັນບໍ່ໄດ້ພິສູດຫຍັງກ່ຽວກັບຕົວຕົນທີ່ແທ້ຈິງຂອງຜູ້ສົ່ງ.
ການກັ່ນຕອງ regex ຫຼື ລາຍຊື່ອະນຸຍາດສາມາດຢຸດການປອມແປງ User-Agent ໄດ້ບໍ?
ບໍ່. ລາຍຊື່ອະນຸຍາດຈະກວດສອບວ່າສະຕຣິງກົງກັບຮູບແບບທີ່ຄາດໄວ້ເທົ່ານັ້ນ, ແລະຜູ້ໂຈມຕີສາມາດຄັດລອກຮູບແບບທີ່ແນ່ນອນນັ້ນໃສ່ໃນຄຳຮ້ອງຂໍຂອງຕົນເອງໄດ້.
ສິ່ງທີ່ຄວນທົດແທນການກວດສອບຄວາມຖືກຕ້ອງໂດຍອີງໃສ່ User-Agent ໃນ CI/CD?
ການຢັ້ງຢືນລະຫັດລັບຂອງແຫຼ່ງຂໍ້ມູນ: TLS ເຊິ່ງກັນແລະກັນ, ການຮ້ອງຂໍທີ່ລົງນາມ (HMAC, JWT, AWS SigV4), ແລະ ສິ່ງປະດິດການກໍ່ສ້າງທີ່ລົງນາມພ້ອມກັບການຢັ້ງຢືນແຫຼ່ງທີ່ມາເຊັ່ນ SLSA ຫຼື in-toto.
