ຕົວທ່ອງເວັບເປັນ Backdoor: Client-Side LLM ການສະກັດເອົາຄວາມລັບ Demystified
ດົນເກີນໄປ, ພວກເຮົາໄດ້ປະຕິບັດ "ຄຳເຕືອນຄວາມປອດໄພ AI" ເປັນໄພຂົ່ມຂູ່ທາງໄກ ຫຼື ຄວາມຢາກຮູ້ທາງວິຊາການ. ພວກເຮົາໄດ້ຍິນກ່ຽວກັບການສີດທັນທີ, ການ jailbreak, ແລະການຮົ່ວໄຫລຂອງຂໍ້ມູນໃນສຽງທີ່ງຽບສະຫງົບ, ມັກຈະຕິດຕາມດ້ວຍ shrug ແລະ "ພວກເຮົາຈະເຂົ້າຫາມັນ." ຢ່າງໃດກໍຕາມ, ການສາທິດແບບໂຕ້ຕອບທີ່ຜ່ານມາໄດ້ທໍາລາຍພາບລວງຕາທີ່ສະດວກສະບາຍນັ້ນ. ນີ້ບໍ່ແມ່ນຄວາມອ່ອນແອທາງທິດສະດີອີກຕໍ່ໄປ; ມັນເປັນການຂຸດຄົ້ນສົດ, ອີງໃສ່ຕົວທ່ອງເວັບ, ດ້ານລູກຄ້າສໍາລັບການສະກັດຂໍ້ມູນທີ່ລະອຽດອ່ອນຈາກຕົວແບບພາສາຂະຫນາດໃຫຍ່ (LLMs) [2]. ຖ້າທ່ານກໍາລັງໃຊ້ແອັບພລິເຄຊັນທີ່ໃຊ້ LLM, ໂດຍສະເພາະສິ່ງໃດກໍ່ຕາມທີ່ປະເຊີນກັບເວັບ, "ບັນຫາໃນອະນາຄົດ" ຂອງເຈົ້າໄດ້ກາຍເປັນຄວາມຮັບຜິດຊອບໃນປະຈຸບັນ, ສາທາລະນະຫຼາຍ, ແລະອາດຈະເປັນຄວາມຮັບຜິດຊອບທີ່ຫນ້າອັບອາຍຫຼາຍ.
ນີ້ບໍ່ແມ່ນຫົວຂໍ້ທົ່ວໄປ "AI ແມ່ນຄວາມສ່ຽງ" ອື່ນ. ນີ້ແມ່ນການສະແດງອອກສະເພາະ, ເຫັນໄດ້ຊັດເຈນວ່ານັກສະແດງທີ່ເປັນອັນຕະລາຍ, ໂດຍໃຊ້ພຽງແຕ່ຕົວທ່ອງເວັບຂອງພວກເຂົາ, ສາມາດບີບບັງຄັບ LLM ຂອງທ່ານເພື່ອເປີດເຜີຍຂໍ້ມູນທີ່ລະອຽດອ່ອນ. ພິຈາລະນາວ່າສໍາລັບປັດຈຸບັນ. ມັນບໍ່ກ່ຽວກັບການໂຈມຕີຂ້າງເຊີບເວີທີ່ສັບສົນ ຫຼືການກວດກາແບບຢ່າງເລິກເຊິ່ງ. ມັນກ່ຽວກັບຊັ້ນການໂຕ້ຕອບ - ປະຕູທາງຫນ້າຂອງແອັບພລິເຄຊັນຂອງທ່ານ - ຖືກຂູດຮີດດ້ວຍຕົວລະຄອນທີ່ສ້າງຂຶ້ນຢ່າງລະມັດລະວັງ. ມັນແມ່ນການທຽບເທົ່າດິຈິຕອນຂອງຄົນທີ່ສ້າງປະໂຫຍກທີ່ຖືກຕ້ອງໃຫ້ກັບ chatbot ທີ່ປອດໄພທີ່ສົມມຸດຕິຖານຂອງເຈົ້າ, ແລະມັນມອບຂໍ້ມູນທີ່ສໍາຄັນ, ເລື້ອຍໆເທື່ອລະຫນ້ອຍ.
ພາບລວງຕາຂອງຄວາມປອດໄພແບບຈໍາລອງ
ວິສາຫະກິດຈໍານວນຫຼາຍໄດ້ລົງທຶນຢ່າງຫຼວງຫຼາຍໃນ LLMs "ທີ່ປອດໄພ", ບໍ່ວ່າຈະເປັນການປັບຕົວແບບທີ່ເປັນເຈົ້າຂອງຫຼືອີງໃສ່ APIs ລະດັບວິສາຫະກິດກັບ guardrails supposed. ສົມມຸດຕິຖານ implicit ແມ່ນວ່າຖ້າຫາກວ່າຕົວແບບຕົວມັນເອງແມ່ນເຂັ້ມແຂງ, ຄໍາຮ້ອງສະຫມັກທີ່ສ້າງຂຶ້ນເທິງຂອງມັນຈະສືບທອດຄວາມປອດໄພນັ້ນ. ການປະທ້ວງເມື່ອບໍ່ດົນມານີ້ ສະແດງໃຫ້ເຫັນວ່າ ນີ້ເປັນຄວາມຄິດຜິດທີ່ເປັນອັນຕະລາຍ. ຊ່ອງໂຫວ່ບໍ່ໄດ້ຢູ່ໃນຄວາມສະຫຼາດຫຼັກຂອງຕົວແບບ ຫຼືຂໍ້ມູນການຝຶກອົບຮົມຂອງມັນ; ມັນຢູ່ໃນ * ການໂຕ້ຕອບ * ທີ່ພວກເຮົາສ້າງປະມານມັນ [1]. ມັນເປັນບັນຫາຄລາສສິກ "vault ທີ່ເຂັ້ມແຂງ, ປະຕູຫນ້າ flimsy". ທ່ານອາດຈະມີ LLM ທີ່ກ້າວຫນ້າ, ແຂງທີ່ສຸດໃນໂລກ, ແຕ່ຖ້າຕົວແຍກການປ້ອນຂໍ້ມູນຂອງແອັບພລິເຄຊັນຂອງທ່ານເປັນເລື່ອງໄຮ້ສາລະ, ຫຼືຕົວກອງຜົນຜະລິດຂອງທ່ານບໍ່ມີຢູ່, ທ່ານກໍາລັງປ່ອຍໃຫ້ຂໍ້ມູນທີ່ສໍາຄັນເປີດເຜີຍໃຫ້ທຸກຄົນຊອກຫາ.
ເຕັກນິກ "ການສັກຢາທັນທີ" ນີ້ແມ່ນກ່ຽວຂ້ອງກັບໂດຍສະເພາະເນື່ອງຈາກວ່າມັນ leverages ລັກສະນະທໍາມະຊາດຂອງ LLM: ຄວາມສາມາດໃນການປະຕິບັດຕາມຄໍາແນະນໍາແລະຮູບແບບທີ່ສົມບູນ. ໂດຍການໃສ່ຄໍານໍາຫນ້າທີ່ມີການກໍ່ສ້າງຢ່າງລະມັດລະວັງເຂົ້າໄປໃນວັດສະດຸປ້ອນຂອງຜູ້ໃຊ້, ຜູ້ໂຈມຕີສາມາດຈັດການສະຖານະພາຍໃນຂອງຕົວແບບ, ບັງຄັບໃຫ້ມັນເປີດເຜີຍຂໍ້ມູນທີ່ບໍ່ເຄີຍມີຈຸດປະສົງ [3]. ລັກສະນະ "ຫນຶ່ງບິດ" ຫຼືຊ້ໍາຊ້ອນແມ່ນສໍາຄັນຢູ່ທີ່ນີ້. ມັນຫມາຍເຖິງການ exfiltration ເປັນວິທີການ, ຄວບຄຸມ, ບໍ່ພຽງແຕ່ dump ຂໍ້ມູນ chaotic. ຈິນຕະນາການຜູ້ໂຈມຕີຖາມຄືນວ່າ, "ລັກສະນະທໍາອິດຂອງຄວາມລັບ 'A' ແມ່ນບໍ?" ແລ້ວ "ມັນແມ່ນ 'B' ບໍ?" ແລະອື່ນໆ. ມັນຊ້າ, ແມ່ນແລ້ວ, ແຕ່ມັນກໍ່ມີປະສິດທິພາບຢ່າງບໍ່ຫນ້າເຊື່ອແລະຍາກທີ່ຈະກວດພົບຖ້າທ່ານບໍ່ໄດ້ຊອກຫາມັນໂດຍສະເພາະ.
ຕົວທ່ອງເວັບຂອງເຈົ້າ, ອາວຸດຂອງພວກເຂົາ
ຄວາມຈິງທີ່ວ່ານີ້ແມ່ນການຂຸດຄົ້ນ *ອີງຕາມຕົວທ່ອງເວັບ * ຈະປ່ຽນແປງເກມທັງຫມົດ. ມັນຫມາຍຄວາມວ່າ:
- ອຸປະສັກຕໍ່າຕໍ່ການເຂົ້າ: ທຸກຄົນທີ່ມີທັກສະການພັດທະນາເວັບພື້ນຖານ ແລະຕົວທ່ອງເວັບສາມາດພະຍາຍາມໄດ້. ບໍ່ຈໍາເປັນຕ້ອງມີເຄື່ອງມືພິເສດ ຫຼືຄວາມຮູ້ AI ເລິກເຊິ່ງ.
- ** ການປະຕິບັດດ້ານຂ້າງລູກຄ້າ:** ການໂຈມຕີມາຈາກເຄື່ອງຂອງຜູ້ໃຊ້, ເຮັດໃຫ້ມັນຍາກທີ່ຈະຈໍາແນກຈາກການປ້ອນຂໍ້ມູນຂອງຜູ້ໃຊ້ທີ່ຖືກຕ້ອງຢູ່ໃນຂອບເຄືອຂ່າຍ.
- ** ໄພຂົ່ມຂູ່ທັນທີທັນໃດ:** ຖ້າແອັບພລິເຄຊັນ LLM ຂອງເຈົ້າສົດແລະເຂົ້າເຖິງໄດ້ໂດຍຜ່ານການໂຕ້ຕອບຂອງເວັບໄຊຕ໌, ມັນແມ່ນ * ແລ້ວ* ມີຄວາມສ່ຽງຕໍ່ vector ນີ້. ນີ້ບໍ່ແມ່ນການແກ້ໄຂໃນອະນາຄົດ; ມັນເປັນພາວະສຸກເສີນໃນປັດຈຸບັນ.
ພິຈາລະນາຜົນກະທົບ: ຂໍ້ມູນຫຍໍ້ຂອງລະຫັດທີ່ເປັນເຈົ້າຂອງ, ເອກະສານພາຍໃນ, ຂໍ້ມູນລູກຄ້າ, ລະຫັດ API, ຫຼືແມ້ກະທັ້ງການຫມູນໃຊ້ເລັກນ້ອຍຂອງພຶດຕິກໍາຂອງ LLM ຂອງທ່ານເພື່ອເຜີຍແຜ່ຂໍ້ມູນທີ່ບໍ່ຖືກຕ້ອງຫຼືສ້າງເນື້ອຫາທີ່ເປັນອັນຕະລາຍ. ທັງຫມົດນີ້ສາມາດຖືກສະກັດຫຼືມີອິດທິພົນ, ເລັກນ້ອຍໂດຍການເຈັບປວດ, ຜ່ານກ່ອງຂໍ້ຄວາມງ່າຍໆ.
ຄວາມຮັບຜິດຊອບແມ່ນຂອງເຈົ້າ
ນີ້ບໍ່ແມ່ນບັນຫາສໍາລັບຜູ້ໃຫ້ບໍລິການແບບຈໍາລອງເຊັ່ນ OpenAI ຫຼື Google ທີ່ຈະແກ້ໄຂໃນການປັບປຸງຮຸ່ນຕໍ່ໄປຂອງພວກເຂົາ. ນີ້ແມ່ນບັນຫາ ຄວາມປອດໄພຂອງແອັບພລິເຄຊັນ, ແລະຄວາມຮັບຜິດຊອບໃນການຫຼຸດຜ່ອນແມ່ນຕົກຢູ່ໃນບ່າຂອງນັກພັດທະນາ, ທີມຮັກສາຄວາມປອດໄພ ແລະ CTO ທີ່ນຳໃຊ້ລະບົບເຫຼົ່ານີ້. LLM ຂອງທ່ານແມ່ນເຄື່ອງຈັກທີ່ມີປະສິດທິພາບ, ແຕ່ສຸດທ້າຍແມ່ນໂງ່. ມັນຈະເຮັດຕາມທີ່ມັນບອກ, ເຖິງແມ່ນວ່າຄໍາແນະນໍາເຫຼົ່ານັ້ນຈະຖືກເຊື່ອງໄວ້ພາຍໃນການປ້ອນຂໍ້ມູນຂອງຜູ້ໃຊ້ທີ່ບໍ່ມີປະໂຫຍດ.
ດັ່ງນັ້ນ, ເຈົ້າເຮັດອັນໃດ * ດຽວນີ້ *?
ມາດຕະການຕອບໂຕ້ທັນທີ:
- Aggressive Input Sanitization: ອັນນີ້ເກີນກວ່າການປ້ອງກັນການສີດ SQL ຫຼື XSS. ທ່ານຈໍາເປັນຕ້ອງໄດ້ກວດກາ * ທຸກຕົວອັກສອນ * ທີ່ເຂົ້າມາ LLM ຂອງທ່ານ. ຊອກຫາຮູບແບບທີ່ຊີ້ໃຫ້ເຫັນເຖິງການສີດທັນທີ, ລໍາດັບລັກສະນະຜິດປົກກະຕິ, ຫຼືຄວາມພະຍາຍາມທີ່ຈະແຍກອອກຈາກກະແສການສົນທະນາທີ່ຄາດໄວ້ [4]. ນີ້ບໍ່ແມ່ນກ່ຽວກັບການສະກັດ "ຄໍາທີ່ບໍ່ດີ"; ມັນກ່ຽວກັບການກໍານົດການກະຕຸ້ນຂອງສັດຕູ. ນອກເຫນືອຈາກການວິເຄາະ regex ພື້ນຖານແລະ heuristic, ປະຕິບັດການວິເຄາະ semantic ເພື່ອກວດພົບຄວາມຕັ້ງໃຈທີ່ເປັນອັນຕະລາຍ. ໃຊ້ tokenization ແລະການວິເຄາະຝັງເພື່ອກໍານົດຮູບແບບການປ້ອນຂໍ້ມູນຜິດປົກກະຕິ. ພິຈາລະນາໃຊ້ LLM ທີສອງ, ຂະຫນາດນ້ອຍກວ່າຫຼືລະບົບທີ່ອີງໃສ່ກົດລະບຽບທີ່ໄດ້ຮັບການຝຶກອົບຮົມໂດຍສະເພາະເພື່ອກວດພົບຄວາມພະຍາຍາມສີດທັນທີ. ຊອກຫາຮູບແບບເຊັ່ນ: ຄໍາແນະນໍາການຫຼິ້ນບົດບາດ, ການຮ້ອງຂໍການສະກັດເອົາຂໍ້ມູນຢ່າງຈະແຈ້ງ, ຫຼືຄວາມພະຍາຍາມທີ່ຈະຂ້າມຄໍາແນະນໍາທີ່ຜ່ານມາ.
- ການກັ່ນຕອງ ແລະການກວດສອບຜົນຜະລິດທີ່ແຂງແຮງ: ຢ່າໄວ້ໃຈກັບຜົນຜະລິດຂອງ LLM ໂດຍ implicitly. ກ່ອນທີ່ຂໍ້ຄວາມທີ່ສ້າງຂຶ້ນໂດຍ LLM ຈະຖືກສະແດງໃຫ້ກັບຜູ້ໃຊ້ ຫຼືໃຊ້ໂດຍລະບົບອື່ນ, ມັນ ຕ້ອງ ຜ່ານຂັ້ນຕອນການກວດສອບຢ່າງເຂັ້ມງວດ. ມັນມີຄໍາທີ່ລະອຽດອ່ອນບໍ? ມັນກົງກັບຮູບແບບທີ່ຄາດໄວ້ບໍ? ມັນພະຍາຍາມປະຕິບັດລະຫັດຫຼືເປີດເຜີຍການເຕືອນລະບົບພາຍໃນບໍ? ຖ້າ LLM ຂອງທ່ານຄວນຈະສະຫຼຸບເອກະສານ, ແຕ່ມັນເລີ່ມລາຍຊື່ເສັ້ນທາງໄຟລ໌, ທ່ານມີບັນຫາ.
- Layered Prompt Engineering: ໃນຂະນະທີ່ບໍ່ແມ່ນການແກ້ໄຂທີ່ສົມບູນ, ການເຕືອນລະບົບທີ່ຖືກອອກແບບຢ່າງດີ ແລະຕົວຢ່າງການຍິງໜ້ອຍໜຶ່ງສາມາດຊ່ວຍເສີມສ້າງພຶດຕິກຳທີ່ຕ້ອງການ ແລະເຮັດໃຫ້ມັນຍາກຂຶ້ນສຳລັບຜູ້ໂຈມຕີທີ່ຈະລັກລອບຕົວແບບ. ຢ່າງໃດກໍ່ຕາມ, ເຂົ້າໃຈວ່າວິສະວະກໍາທັນທີຢ່າງດຽວແມ່ນບໍ່ພຽງພໍ; ມັນເປັນການປ້ອງກັນໃນຄວາມເລິກ, ບໍ່ແມ່ນໄສ້ຕົ້ນຕໍ.
- ສິດທິພິເສດຕໍ່າສຸດສໍາລັບການໂຕ້ຕອບຂອງ LLM: LLM ຂອງທ່ານຕ້ອງການເຂົ້າເຖິງຂໍ້ມູນທຸກອັນທີ່ມັນອາດຈະຖືກກະຕຸ້ນໃຫ້ເປີດເຜີຍບໍ? ປະຕິບັດການຄວບຄຸມການເຂົ້າເຖິງຢ່າງເຂັ້ມງວດ. ຖ້າ LLM ພຽງແຕ່ຄວນຕອບຄໍາຖາມກ່ຽວກັບເອກະສານສາທາລະນະ, ໃຫ້ແນ່ໃຈວ່າມັນບໍ່ມີການເຂົ້າເຖິງຖານຂໍ້ມູນພາຍໃນຫຼື APIs ທີ່ລະອຽດອ່ອນ.
- ການຕິດຕາມ ແລະກວດຫາຄວາມຜິດກະຕິ: ເຈົ້າຕ້ອງຊອກຫາພຶດຕິກຳ LLM ທີ່ຜິດປົກກະຕິ. Spikes ໃນປະເພດສະເພາະຂອງການສອບຖາມ, ຜົນໄດ້ຮັບທີ່ deviate ຈາກຮູບແບບປົກກະຕິ, ຫຼືການພະຍາຍາມຊ້ໍາຊ້ອນເພື່ອສະກັດຂໍ້ມູນຄວນຈະກະຕຸ້ນເຕືອນທັນທີທັນໃດ.
ນີ້ບໍ່ແມ່ນກ່ຽວກັບ "ຄວາມປອດໄພ AI" ຢ່າງກວ້າງຂວາງອີກຕໍ່ໄປ. ນີ້ແມ່ນກ່ຽວກັບການຮັບປະກັນຊັ້ນການໂຕ້ຕອບຂອງຄໍາຮ້ອງສະຫມັກ LLM ຂອງທ່ານຕໍ່ກັບ vector ການໂຈມຕີສະເພາະ, ສະແດງໃຫ້ເຫັນ, ແລະທັນທີທັນໃດ. ພວກເຮົາໄດ້ສ້າງລະບົບທີ່ມີປະສິດທິພາບທີ່ບໍ່ຫນ້າເຊື່ອ, ມັກຈະມີມາດຕະການຄວາມປອດໄພທີ່ບໍ່ພຽງພໍໃນການໂຕ້ຕອບ. ການສາທິດເມື່ອບໍ່ດົນມານີ້ໄດ້ສະແດງໃຫ້ພວກເຮົາເຫັນຢ່າງແນ່ນອນວ່າມັນງ່າຍພຽງໃດທີ່ຈະຂຸດຄົ້ນຊ່ອງຫວ່າງເຫຼົ່ານີ້. ເວລາສໍາລັບການສົນທະນາທິດສະດີແມ່ນຜ່ານມາ. ຈໍາເປັນຕ້ອງດໍາເນີນການທັນທີເພື່ອຮັບປະກັນຄໍາຮ້ອງສະຫມັກ LLM.
ແຫຼ່ງຂໍ້ມູນ
[1] OWASP Top 10 ສໍາລັບຄໍາຮ້ອງສະຫມັກແບບຈໍາລອງພາສາຂະຫນາດໃຫຍ່ — https://owasp.org/www-project-top-10-for-large-language-model-applications/ [2] Lakera Gandalf: ສິ່ງທ້າທາຍການສັກຢາແບບໂຕ້ຕອບ— https://gandalf.lakera.ai/ [3] ການໂຈມຕີການສັກຢາວ່ອງໄວ | Web Security Academy — https://portswigger.net/web-security/llm-attacks/prompt-injection [4] ການສັກຢາດ່ວນແມ່ນຫຍັງ ແລະວິທີປ້ອງກັນມັນແນວໃດ? — https://www.tenable.com/blog/what-is-prompt-injection-and-how-to-prevent-it