ການສີດແມ່ແບບຝັ່ງເຊີບເວີ (SSTI) ເປັນຊ່ອງໂຫວ່ທີ່ການປ້ອນຂໍ້ມູນຂອງຜູ້ໃຊ້ຖືກປະເມີນໂດຍເຄື່ອງຈັກແມ່ແບບແທນທີ່ຈະຖືກສະແດງເປັນຂໍ້ຄວາມທຳມະດາ, ເຮັດໃຫ້ຜູ້ໂຈມຕີສາມາດແລ່ນລະຫັດຕ່າງໆໃນເຊີບເວີໄດ້.
ວິທີການສີດແມ່ແບບຝັ່ງເຊີບເວີເຮັດວຽກຢູ່ເບື້ອງຫຼັງ
ການສີດແມ່ແບບຝັ່ງເຊີບເວີເກີດຂຶ້ນເມື່ອຂໍ້ມູນຂອງຜູ້ໃຊ້ຖືກຝັງໂດຍກົງໃນເຄື່ອງຈັກແມ່ແບບ ແລະ ປະເມີນຜົນໂດຍບໍ່ມີການຂ້າເຊື້ອ ຫຼື ການແຍກອອກທີ່ເໝາະສົມ. ສິ່ງນີ້ສ້າງຊ່ອງໂຫວ່ SSTI ທີ່ຊ່ວຍໃຫ້ຜູ້ໂຈມຕີສາມາດສີດ payload SSTI ທີ່ສ້າງຂຶ້ນເປັນພິເສດ (ຕົວຢ່າງ, {{7*7}} ໃນ Jinja2), ເຊິ່ງເຄື່ອງຈັກຈະປະເມີນຜົນ, ເຮັດໃຫ້ທຸກຢ່າງຕັ້ງແຕ່ການເປີດເຜີຍຂໍ້ມູນຈົນເຖິງການປະຕິບັດລະຫັດແບບບໍ່ເປັນທາງການໃນສະພາບການຂອງເຊີບເວີ. ເນື່ອງຈາກເຄື່ອງຈັກແມ່ແບບທີ່ແຕກຕ່າງກັນເປີດເຜີຍວັດຖຸ ແລະ API ທີ່ແຕກຕ່າງກັນ, payload ຂອງ SSTI ແຕກຕ່າງກັນໄປຕາມແພລດຟອມ ແຕ່ມີຄວາມອັນຕະລາຍຄືກັນ: ພວກມັນປ່ອຍໃຫ້ການປ້ອນຂໍ້ມູນທີ່ບໍ່ໜ້າເຊື່ອຖືຫຼົບໜີຈາກກະແສການສະແດງຜົນທີ່ຄາດໄວ້ ແລະ ປະຕິບັດໃນເວລາແລ່ນຂອງແອັບພລິເຄຊັນ, ເຊິ່ງມັກຈະນຳໄປສູ່ການປະຕິບັດລະຫັດໄລຍະໄກຢ່າງເຕັມທີ່ ຫຼື ການເຄື່ອນໄຫວຂ້າງຄຽງຖ້າບໍ່ໄດ້ກວດສອບ.
ຕົວຢ່າງທີ່ມີຄວາມສ່ຽງໜ້ອຍທີ່ສຸດໃນ Jinja2
ຖ້າຜູ້ໃຊ້ສົ່ງ ?ຊື່={{7*7}}, ແອັບຈະປະເມີນມັນ, ສົ່ງຄືນ ສະບາຍດີ 49ນັ້ນແມ່ນຊ່ອງໂຫວ່ SSTI ຕາມແບບຮຽນ.
ຕົວຢ່າງທີ່ມີຄວາມສ່ຽງໜ້ອຍທີ່ສຸດໃນ Twig
ຜູ້ໂຈມຕີສາມາດສັກ SSTI payloads ໄດ້ເຊັ່ນ: {{7*7}} ເພື່ອພິສູດການປະຕິບັດລະຫັດ. ອັນຕະລາຍ: ການສີດງ່າຍໆສາມາດເຮັດໃຫ້ເກີດການອ່ານໄຟລ໌, ການປະຕິບັດຄໍາສັ່ງລະບົບປະຕິບັດການ, ຫຼືການຫັນໄປສູ່ພື້ນຖານໂຄງລ່າງທີ່ເລິກເຊິ່ງກວ່າເກົ່າ.
ການນຳໃຊ້ຊ່ອງໂຫວ່ໃນໂລກຕົວຈິງ: ການຈ່າຍເງິນ SSTI ທີ່ກະຕຸ້ນການປະຕິບັດລະຫັດຈາກໄລຍະໄກ
ເມື່ອມີຊ່ອງໂຫວ່ SSTI ແລ້ວ, ຜູ້ໂຈມຕີຈະພະຍາຍາມຍ້າຍຈາກການຄິດໄລ່ແນວຄວາມຄິດໄປສູ່ການຄິດໄລ່ແບບເຕັມຮູບແບບ RCEເຄື່ອງຈັກແມ່ແບບທີ່ແຕກຕ່າງກັນຈັດການກັບ payloads ແຕກຕ່າງກັນ.
ສິນຄ້າ Jinja2
- {{7*7}} → ການປະຕິບັດຄະນິດສາດ
- {{config.items()}} → ຮົ່ວໄຫຼການຕັ້ງຄ່າເຊີບເວີ.
- {{ “”.__class__.__mro__[2].__subclasses__() }} → ເສັ້ນທາງໄປຫາ RCE
ຄວາມໄວໃນການໂຫຼດ
- #ຊຸດ($x=”7″)${x} → ການຜ່າຕັດຂ້າມ
- #set($a=$class.inspect(“java.lang.Runtime”)) → ການເຂົ້າເຖິງເວລາແລ່ນໂດຍກົງ
ນ້ຳໜັກบรรทุกຂອງກິ່ງງ່າ
- {{7*7}} → ຄະນິດສາດ
- {{app.request.server.all}} → ຕົວແປສະພາບແວດລ້ອມ
- {{_self.env.registerUndefinedFilterCallback(‘system’)}} → ການປະຕິບັດລະຫັດ
payload ຂອງ SSTI ເຫຼົ່ານີ້ສະແດງໃຫ້ເຫັນວ່າຊ່ອງໂຫວ່ດຽວກັນໃນເຄື່ອງຈັກທີ່ແຕກຕ່າງກັນນໍາໄປສູ່ຄວາມແຕກຕ່າງແນວໃດ ເສັ້ນທາງທີ່ໃຊ້ປະໂຫຍດຈາກການໃຊ້ປະໂຫຍດ, ແຕ່ພວກມັນກໍ່ເປັນອັນຕະລາຍສະເໝີ.
ບ່ອນທີ່ການສີດແມ່ແບບຝັ່ງເຊີບເວີຊ່ອນຢູ່ໃນ CI/CDແອັບພລິເຄຊັນທີ່ຂັບເຄື່ອນດ້ວຍ
ການສີດແມ່ແບບຝັ່ງເຊີບເວີບໍ່ພຽງແຕ່ເປັນຄວາມສ່ຽງຂອງແອັບເວັບເທົ່ານັ້ນ; ມັນສະແດງຢູ່ໃນ ທີ່ທັນສະໄຫມ CI/CD pipelines ເຊັ່ນດຽວກັນ. ສະຖານທີ່ລີ້ຊ່ອນທົ່ວໄປປະກອບມີ:
- ຕາຕະລາງຫມວກກັນກະທົບ ໃນ Kubernetes, ບ່ອນທີ່ຄ່າແມ່ແບບຖືກສະແດງຜົນແບບໄດນາມິກ
- ແມ່ແບບອີເມວ ທີ່ເຊື່ອມຕໍ່ອິນພຸດທີ່ຄວບຄຸມໂດຍຜູ້ໃຊ້
- Dashboards ບ່ອນທີ່ສະຕຣິງການສອບຖາມ ຫຼື ຂໍ້ມູນການຕັ້ງຄ່າຖືກສັກເຂົ້າໄປໃນແມ່ແບບ
- ສະຄຣິບ DevOps ທີ່ສ້າງ HTML/Markdown ໂດຍໃຊ້ເຄື່ອງຈັກສ້າງແບບຈຳລອງ.
ຕົວຢ່າງ:
Ifຂໍ້ຄວາມ .ຄ່ານິຍົມ ມາຈາກການປ້ອນຂໍ້ມູນທີ່ບໍ່ໜ້າເຊື່ອຖື, ມັນແນະນຳການສີດແມ່ແບບຝັ່ງເຊີບເວີໃນການນຳໃຊ້ຂອງທ່ານ pipeline ຕົວເອງ
ການປ້ອງກັນ SSTI ດ້ວຍຮູບແບບແມ່ແບບທີ່ປອດໄພກວ່າ ແລະ ການວິເຄາະແບບຄົງທີ່
ການຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງ SSTI ຮຽກຮ້ອງໃຫ້ມີຮູບແບບການເຂົ້າລະຫັດທີ່ດີກວ່າ ແລະ ການກວດພົບແຕ່ຫົວທີ.
ຮູບແບບທີ່ປອດໄພ
- ❌ ຫ້າມໃຊ້ ສະຕຣິງແມ່ແບບສະແດງຜົນ ຫລືທຽບເທົ່າ
- ✅ ໃຊ້ໄຟລ໌ແມ່ແບບທີ່ກຳນົດໄວ້ລ່ວງໜ້າ ແລະ ຜ່ານຕົວແປທີ່ຖືກກວດສອບແລ້ວ
- ✅ ເຄື່ອງຈັກແມ່ແບບ Sandbox ເມື່ອມີໃຫ້ໃຊ້
- ✅ກວດສອບ ແລະ ຫຼີກລ່ຽງການປ້ອນຂໍ້ມູນຂອງຜູ້ໃຊ້ກ່ອນການສະແດງຜົນ
ລາຍການກວດສອບຂະໜາດນ້ອຍສຳລັບນັກພັດທະນາ
- ຢ່າສະແດງຂໍ້ມູນດິບຂອງຜູ້ໃຊ້ໂດຍກົງ
- ໃຊ້ແມ່ແບບ sandboxed ເມື່ອຮອງຮັບ
- ເຮັດຄວາມສະອາດ ແລະ ກວດສອບຄວາມຖືກຕ້ອງຂອງຕົວແປແມ່ແບບທັງໝົດ
- ຫຼີກລ່ຽງຕົວປະເມີນແມ່ແບບທີ່ກຳນົດເອງ
- ສະແກນລະຫັດເພື່ອ ສະຕຣິງແມ່ແບບສະແດງຜົນ ຫຼືຮູບແບບການຕໍ່ກັນຂອງສະຕຣິງ
ການວິເຄາະຄົງທີ່ ແລະ ຂີ້ເຫຍື້ອສາມາດໝາຍເຖິງການກໍ່ສ້າງທີ່ມີຄວາມສ່ຽງກ່ອນທີ່ພວກມັນຈະຮອດການຜະລິດ.
ການຝັງການກວດສອບ SSTI ໃນ DevSecOps Pipelines
ການກວດສອບການສີດແມ່ແບບຝັ່ງເຊີບເວີແຕ່ຫົວທີມີລາຄາຖືກກວ່າ ແລະ ປອດໄພກວ່າການແກ້ໄຂມັນໃນພາຍຫຼັງ. ທີມງານ DevSecOps ຄວນຝັງການກວດສອບໄວ້ໃນ pipelines:
- Commit hooks: ປະຕິເສດ commits ທີ່ມີໜ້າທີ່ອັນຕະລາຍ (ສະຕຣິງແມ່ແບບສະແດງຜົນ)
- ເຄື່ອງວິເຄາະແບບຄົງທີ່: ສະແກນຫາຄວາມສ່ຽງຕໍ່ການສີດແມ່ແບບຝັ່ງເຊີບເວີໃນລະຫັດແມ່ແບບ
- ການກວດສອບການເພິ່ງພາອາໄສ: ໝາຍເຖິງເຄື່ອງຈັກແມ່ແບບທີ່ລ້າສະໄໝທີ່ມີຊ່ອງໂຫວ່ SSTI ທີ່ຮູ້ຈັກ
- Pipeline ປະຕູຮົ້ວ: ບລັອກຈະລວມເຂົ້າກັນຈົນກວ່າການກວດສອບ SSTI ຈະຜ່ານ
ໂດຍການເຮັດໃຫ້ການກວດຈັບ payload SSTI ເປັນສ່ວນໜຶ່ງຂອງ CI/CD, ທ່ານປ້ອງກັນບໍ່ໃຫ້ລະຫັດທີ່ໃຊ້ປະໂຫຍດຈາກການຂົນສົ່ງໃດໆ.
ຢ່າປ່ອຍໃຫ້ການສີດແມ່ແບບຝັ່ງເຊີບເວີເຂົ້າໄປໃນ Stack ຂອງທ່ານ
ການສີດແມ່ແບບຝັ່ງເຊີບເວີດຽວສາມາດຍົກລະດັບຈາກເຄັດລັບຄະນິດສາດ ({{7*7}}) ໄປສູ່ການປະຕິບັດລະຫັດຈາກໄລຍະໄກຢ່າງເຕັມຮູບແບບ. ຊ່ອງໂຫວ່ SSTI ບໍ່ພຽງແຕ່ປະກົດຢູ່ໃນແອັບເວັບເທົ່ານັ້ນ ແຕ່ຍັງຢູ່ໃນ CI/CD pipelines, ຕາຕະລາງ Helm, ແລະແມ່ແບບອີເມວ.
ການຮັບເອົາທີ່ ສຳ ຄັນ
- ຢ່າສະແດງຂໍ້ມູນດິບຂອງຜູ້ໃຊ້ໃສ່ໃນແມ່ແບບ
- ກວດສອບຄວາມຖືກຕ້ອງ ແລະ ເຮັດຄວາມສະອາດຕົວແປໄດນາມິກທັງໝົດ
- ເຄື່ອງຈັກທີ່ແຕກຕ່າງກັນ (Jinja2, Velocity, Twig) ມີພາລະການໂຫຼດ SSTI ທີ່ແຕກຕ່າງກັນ, ແຕ່ທັງໝົດສາມາດນຳໃຊ້ເປັນອາວຸດໄດ້
- ໃຊ້ການວິເຄາະແບບຄົງທີ່ ແລະ ປະຕູປ້ອງກັນຄວາມລົ້ມເຫຼວໃນ pipelines
- ກວດສອບແມ່ແບບໃນຊຸດຂອງທ່ານເປັນປະຈຳ
ຊີເກນີ ສະແກນຖານຂໍ້ມູນລະຫັດຂອງທ່ານສຳລັບຂໍ້ບົກຜ່ອງໃນການສີດ ແລະ ຮູບແບບການຂຽນລະຫັດທີ່ບໍ່ປອດໄພອື່ນໆຕາມທີ່ພວກມັນປາກົດ, ຈັບໂຄງສ້າງທີ່ມີຄວາມສ່ຽງເຊັ່ນ: ການສະແດງແມ່ແບບທີ່ບໍ່ໄດ້ເຮັດຄວາມສະອາດກ່ອນທີ່ພວກມັນຈະຮອດການຜະລິດ, ດ້ວຍອັດຕາການ false-positive ຕໍ່າສຸດໃນ OWASP Benchmark. Xygeni's CI/CD ແລະ IaC security ການສະແກນຂະຫຍາຍການຄຸ້ມຄອງດຽວກັນນັ້ນໄປສູ່ pipeline ການຕັ້ງຄ່າ, ຕາຕະລາງ Helm, ແລະ ສະຄຣິບສ້າງ, ລາຍງານການຕັ້ງຄ່າຜິດພາດ ແລະ ຄຳສັ່ງທີ່ເປັນອັນຕະລາຍກ່ອນທີ່ພວກມັນຈະສົ່ງໄປ. ເມື່ອ Xygeni ພົບຊ່ອງໂຫວ່, AI AutoFix ຈະສ້າງການແກ້ໄຂທີ່ຮັບຮູ້ສະພາບການ ແລະ ພ້ອມສຳລັບນັກພັດທະນາໂດຍກົງໃນ pull request, ສະນັ້ນການແກ້ໄຂຈຶ່ງບໍ່ໄດ້ລໍຖ້າການແລ່ນຄັ້ງຕໍ່ໄປ.
ໃນ DevSecOps, ການຈັບແມ່ແບບສີດຢູ່ທີ່ pipeline ຂັ້ນຕອນ, ບໍ່ແມ່ນຫຼັງຈາກການນຳໃຊ້, ແມ່ນສິ່ງທີ່ປ້ອງກັນບໍ່ໃຫ້ payload ດຽວກາຍເປັນການປະນີປະນອມຢ່າງເຕັມທີ່.
ເລີ່ມຕົ້ນໂດຍບໍ່ເສຍຄ່າ. ບໍ່ຈຳເປັນຕ້ອງໃຊ້ບັດເຄຣດິດ, ສະແກນ repo ທຳອິດຂອງທ່ານໃນນາທີ.
FAQ
ການສີດແມ່ແບບຝັ່ງເຊີບເວີແມ່ນຫຍັງ?
SSTI ເກີດຂຶ້ນເມື່ອຂໍ້ມູນຂອງຜູ້ໃຊ້ຖືກສົ່ງເຂົ້າໄປໃນເຄື່ອງຈັກແມ່ແບບ ແລະ ປະເມີນເປັນລະຫັດແທນທີ່ຈະສະແດງເປັນຂໍ້ຄວາມ, ເຊິ່ງຊ່ວຍໃຫ້ຜູ້ໂຈມຕີສາມາດປະຕິບັດຄຳສັ່ງໃນສະພາບການຂອງເຊີບເວີໄດ້.
SSTI ຄືກັນກັບ XSS ບໍ?
ບໍ່ແມ່ນ. XSS ໃສ່ສະຄຣິບທີ່ເຮັດວຽກຢູ່ໃນບຣາວເຊີຂອງຜູ້ຖືກເຄາະຮ້າຍ; SSTI ໃສ່ລະຫັດທີ່ເຄື່ອງຈັກແມ່ແບບປະເມີນຜົນຢູ່ໃນເຊີບເວີເອງ, ຊຶ່ງເປັນເຫດຜົນທີ່ SSTI ສາມາດນຳໄປສູ່ການປະຕິບັດລະຫັດຈາກໄລຍະໄກໂດຍກົງ.
ເຄື່ອງຈັກແມ່ແບບໃດທີ່ມີຄວາມສ່ຽງຕໍ່ SSTI?
ເຄື່ອງຈັກໃດກໍ່ຕາມທີ່ປະເມີນຜົນການສະແດງອອກອາດຈະມີຄວາມສ່ຽງຖ້າຂໍ້ມູນຂອງຜູ້ໃຊ້ເຂົ້າເຖິງມັນໂດຍບໍ່ໄດ້ເຮັດຄວາມສະອາດ, ລວມທັງ Jinja2, Twig, ແລະ Velocity, ເຖິງແມ່ນວ່າແຕ່ລະອັນຈະສະແດງວັດຖຸທີ່ແຕກຕ່າງກັນ ແລະ ດັ່ງນັ້ນເສັ້ນທາງການຂຸດຄົ້ນທີ່ແຕກຕ່າງກັນ.
ວິທີປ້ອງກັນ SSTI ໃນ CI/CD pipelines?
ສະແກນຫາຮູບແບບອັນຕະລາຍເຊັ່ນ render_template_string at commit ເວລາ, ເຄື່ອງຈັກແມ່ແບບ sandbox ບ່ອນທີ່ຮອງຮັບ, ແລະ gate ລວມເຂົ້າໃນຜົນການວິເຄາະຄົງທີ່ກ່ອນທີ່ລະຫັດຈະຮອດການຜະລິດ.
