ການໂຈມຕີ SQL Injection ສ້າງຄວາມສ່ຽງສູງຕໍ່ການນໍາໃຊ້ເວັບທີ່ອີງໃສ່ ຖານຂໍ້ມູນ backend ເພື່ອສ້າງເນື້ອຫາແບບເຄື່ອນໄຫວ. ໃນການໂຈມຕີຊະນິດນີ້, ແຮກເກີມີການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກເວັບໃນຄວາມພະຍາຍາມທີ່ຈະສົ່ງຄໍາສັ່ງຂອງຕົນເອງເຂົ້າໄປໃນບັນດາຖານຂໍ້ມູນທີ່ອອກມາ. ສໍາລັບຕົວຢ່າງ, ເບິ່ງບົດຄວາມ SQL Injection Attacks ໃນຖານຂໍ້ມູນ. ໃນບົດຄວາມນີ້, ພວກເຮົາໄດ້ເບິ່ງວິທີຕ່າງໆທີ່ທ່ານສາມາດທົດສອບຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ຂອງທ່ານເພື່ອກໍານົດວ່າພວກເຂົາກໍາລັງມີຄວາມສ່ຽງຕໍ່ການໂຈມຕີ SQL Injection.
ການສະແກນ SQL Injection ອັດຕະໂນມັດ
ຫນຶ່ງໃນຄວາມເປັນໄປໄດ້ແມ່ນການນໍາໃຊ້ເຄື່ອງສະແກນໄວຣັສທີ່ສາມາດໃຊ້ງານໄດ້ໂດຍອັດຕະໂນມັດເຊັ່ນ: WebInspect's HP, AppScan ຂອງ IBM ຫຼື Cenzic's Hailstorm. ເຄື່ອງມືເຫລົ່ານີ້ສະເຫນີວິທີງ່າຍໆແລະອັດຕະໂນມັດໃນການວິເຄາະຄໍາຮ້ອງສະຫມັກເວັບໄຊທ໌ຂອງທ່ານສໍາລັບຄວາມສ່ຽງ SQL injection ທີ່ມີສັກຍະພາບ. ຢ່າງໃດກໍຕາມ, ພວກເຂົາກໍາລັງຂ້ອນຂ້າງແພງ, ແລ່ນຢູ່ເຖິງ $ 25,000 ຕໍ່ບ່ອນນັ່ງ.
Manual SQL Injection Tests
ນັກພັດທະນາແອັກໂກ້ທີ່ບໍ່ດີຈະເຮັດແນວໃດ? ທ່ານສາມາດດໍາເນີນການທົດສອບພື້ນຖານບາງຢ່າງເພື່ອປະເມີນຜົນຂອງການໃຊ້ງານເວັບໄຊທ໌ຂອງທ່ານສໍາລັບ SQL Injection vulnerabilities ໃຊ້ບໍ່ມີຫຍັງຫຼາຍກວ່າ browser web. ຫນ້າທໍາອິດ, ຄໍາເຕືອນ: ການທົດສອບທີ່ຂ້າພະເຈົ້າໄດ້ອະທິບາຍພຽງແຕ່ຊອກຫາຂໍ້ບົກພ່ອງພື້ນຖານຂອງ SQL Injection. ພວກເຂົາຈະບໍ່ຮູ້ເຕັກນິກຂັ້ນສູງແລະມີຄວາມຫຍຸ້ງຍາກໃນການນໍາໃຊ້. ຖ້າທ່ານສາມາດຈ່າຍໄດ້, ໄປກັບເຄື່ອງສະແກນອັດຕະໂນມັດ. ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານບໍ່ສາມາດຈັດການກັບລາຄານັ້ນໄດ້, ການທົດສອບດ້ວຍຕົນເອງແມ່ນຂັ້ນຕອນທໍາອິດທີ່ດີ.
ວິທີທີ່ງ່າຍທີ່ສຸດໃນການປະເມີນວ່າຄໍາຮ້ອງສະຫມັກແມ່ນມີຄວາມສ່ຽງແມ່ນການທົດລອງໃຊ້ການໂຈມຕີທີ່ບໍ່ເປັນອັນຕະລາຍທີ່ຈະບໍ່ທໍາລາຍບັນດາຖານຂໍ້ມູນຂອງທ່ານຖ້າພວກເຂົາປະສົບຜົນສໍາເລັດແຕ່ຈະໃຫ້ທ່ານມີຫຼັກຖານວ່າທ່ານຕ້ອງແກ້ໄຂບັນຫາ. ຕົວຢ່າງ, ສົມມຸດວ່າທ່ານມີຄໍາຮ້ອງສະຫມັກເວັບທີ່ງ່າຍດາຍທີ່ເບິ່ງເຖິງບຸກຄົນໃນຖານຂໍ້ມູນແລະໃຫ້ຂໍ້ມູນການຕິດຕໍ່ເປັນຜົນໄດ້ຮັບ. ຫນ້ານັ້ນອາດໃຊ້ຮູບແບບ URL ຕໍ່ໄປນີ້:
ພວກເຮົາສາມາດສົມມຸດວ່າຫນ້ານີ້ປະຕິບັດການຄົ້ນຫາຖານຂໍ້ມູນ, ໂດຍໃຊ້ຄໍາຖາມ ທີ່ຄ້າຍຄືກັນກັບດັ່ງຕໍ່ໄປນີ້:
SELECT phone FROM directory WHERE lastname = 'chapple' and firstname = 'mike'ໃຫ້ທົດລອງກັບເລື່ອງນີ້. ດ້ວຍຄວາມສົມມຸດຂອງພວກເຮົາຂ້າງເທິງ, ພວກເຮົາສາມາດເຮັດໃຫ້ການປ່ຽນແປງທີ່ງ່າຍດາຍຕໍ່ URL ທີ່ທົດສອບສໍາລັບການໂຈມຕີ SQL injection:
http://myfakewebsite.com/directory.asp?lastname=chapple&namename=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1ຖ້າຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ບໍ່ໄດ້ຮັບການປ້ອງກັນຢ່າງຖືກຕ້ອງຕໍ່ກັບການສີດ SQL, ມັນພຽງແຕ່ປ້ອນຊື່ທໍາອິດນີ້ເຂົ້າໃນຄໍາສັ່ງ SQL ທີ່ມັນດໍາເນີນການຕໍ່ກັບຖານຂໍ້ມູນທີ່ເຮັດໃຫ້:
SELECT phone FROM directory WHERE lastname = 'chapple' and firstname = 'mike' AND (select count (*) from fake)> 0 OR '1' = '1'ທ່ານຈະສັງເກດເຫັນວ່າ syntax ຂ້າງເທິງນີ້ແມ່ນແຕກຕ່າງກັນຫນ້ອຍກວ່າຢູ່ໃນ URL ຕົ້ນສະບັບ. ຂ້າພະເຈົ້າໄດ້ເອົາເສລີພາບຂອງການປ່ຽນແປງຕົວແປທີ່ຖືກເຂົ້າລະຫັດ URL ສໍາລັບການທຽບເທົ່າ ASCII ຂອງພວກເຂົາເພື່ອເຮັດໃຫ້ມັນງ່າຍຕໍ່ການປະຕິບັດຕາມຕົວຢ່າງ. ຕົວຢ່າງ:% 3d ແມ່ນການເຂົ້າລະຫັດ URL ສໍາລັບຕົວອັກສອນ '='. ຂ້າພະເຈົ້າຍັງໄດ້ເພີ່ມຈໍານວນສາຍສໍາລັບຈຸດປະສົງທີ່ຄ້າຍຄືກັນ.
ການປະເມີນຜົນໄດ້
ການທົດສອບຈະມາເມື່ອທ່ານພະຍາຍາມທີ່ຈະໂຫລດຫນ້າເວັບດ້ວຍ URL ທີ່ໄດ້ລະບຸໄວ້ຂ້າງເທິງ. ຖ້າຄໍາຮ້ອງສະຫມັກເວັບແມ່ນເຫມາະສົມ, ມັນຈະລອກເອົາວົງຢືມດຽວຈາກຂໍ້ມູນກ່ອນທີ່ຈະສົ່ງຂໍ້ມູນໄປຫາຖານຂໍ້ມູນ. ນີ້ຈະພຽງແຕ່ຜົນໃນການຄົ້ນຫາທີ່ແປກສໍາລັບຄົນທີ່ມີຊື່ທໍາອິດທີ່ປະກອບມີຊໍ່ SQL! ທ່ານຈະເຫັນຂໍ້ຄວາມສະແດງຂໍ້ຜິດພາດຈາກແອັບພລິເຄຊັນທີ່ຄ້າຍຄືກັບຫນຶ່ງຂ້າງລຸ່ມນີ້:
ຂໍ້ຜິດພາດ: ບໍ່ພົບຜູ້ໃຊ້ທີ່ມີຊື່ mike + AND + (ເລືອກ + ນັບ (*) + ຈາກ + ປອມ) +% 3e0 + OR + 1% 3d1 Chapple!ໃນທາງກົງກັນຂ້າມ, ຖ້າຄໍາຮ້ອງສະຫມັກແມ່ນມີຄວາມສ່ຽງຕໍ່ການສີດ SQL, ມັນຈະຜ່ານຄໍາສັ່ງໂດຍກົງກັບຖານຂໍ້ມູນ, ເຊິ່ງເປັນຜົນມາຈາກຫນຶ່ງໃນສອງອັນທີ່ເປັນໄປໄດ້. ຫນ້າທໍາອິດ, ຖ້າເຄື່ອງແມ່ຂ່າຍຂອງທ່ານມີຂໍ້ຄວາມຂໍ້ຜິດພາດທີ່ຖືກເປີດໃຊ້ (ທີ່ທ່ານບໍ່ຄວນ!), ທ່ານຈະເຫັນບາງສິ່ງບາງຢ່າງເຊັ່ນ:
Microsoft OLE DB Provider for ODBC Drivers error '80040e37' [Microsoft] [ODBC SQL Server Driver] [SQL Server] Invalid object name 'fake' / dirirectasp, line 13ໃນທາງກົງກັນຂ້າມ, ຖ້າເຄື່ອງແມ່ຂ່າຍເວັບຂອງທ່ານບໍ່ສະແດງຂໍ້ຄວາມສະແດງຂໍ້ຜິດພາດ, ທ່ານຈະໄດ້ຮັບຂໍ້ຜິດພາດທົ່ວໄປຫຼາຍເຊັ່ນ:
ເຄື່ອງແມ່ຂ່າຍພາຍໃນທີ່ຜິດພາດເຄື່ອງແມ່ຂ່າຍທີ່ພົບຂໍ້ຜິດພາດພາຍໃນຫຼືການກໍານົດເວລາບໍ່ຖືກຕ້ອງແລະບໍ່ສາມາດສໍາເລັດຄໍາຮ້ອງຂໍຂອງທ່ານໄດ້. ກະລຸນາຕິດຕໍ່ເຈົ້າຫນ້າທີ່ຂອງເຄື່ອງແມ່ຂ່າຍເພື່ອແຈ້ງໃຫ້ທາບເຖິງເວລາທີ່ເກີດຄວາມຜິດພາດແລະສິ່ງທີ່ທ່ານອາດຈະເຮັດໄດ້ທີ່ອາດເກີດຄວາມຜິດພາດ. ຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບຂໍ້ຜິດພາດນີ້ອາດມີຢູ່ໃນບັນທຶກຄວາມຜິດພາດຂອງເຄື່ອງແມ່ຂ່າຍ.ຖ້າທ່ານໄດ້ຮັບຫນຶ່ງໃນສອງຂໍ້ຜິດພາດຂ້າງເທິງນີ້, ຄໍາຮ້ອງສະຫມັກຂອງທ່ານມີຄວາມສ່ຽງຕໍ່ການໂຈມຕີ SQL injection! ບາງຂັ້ນຕອນທີ່ທ່ານສາມາດໃຊ້ເພື່ອປົກປ້ອງຄໍາຮ້ອງສະຫມັກຂອງທ່ານຕໍ່ກັບການໂຈມຕີ SQL Injection ປະກອບມີ:
- ດໍາເນີນການກວດສອບພາລາມິເຕີໃນທຸກຄໍາຮ້ອງສະຫມັກ. ຕົວຢ່າງ: ຖ້າທ່ານກໍາລັງຮ້ອງຂໍໃຫ້ຜູ້ໃດຜູ້ຫນຶ່ງເຂົ້າໄປໃນຈໍານວນລູກຄ້າ, ໃຫ້ແນ່ໃຈວ່າຂໍ້ມູນປະເພດແມ່ນຈໍານວນກ່ອນທີ່ຈະ ໃຊ້ຄໍາຖາມ .
- ຈໍາກັດການອະນຸຍາດຂອງບັນຊີທີ່ດໍາເນີນການ ສອບຖາມ SQL . ກົດລະບຽບຂອງສິດທິພິເສດຫນ້ອຍທີ່ຖືກນໍາໃຊ້. ຖ້າບັນຊີທີ່ໃຊ້ເພື່ອດໍາເນີນການສອບຖາມບໍ່ມີການອະນຸຍາດໃຫ້ດໍາເນີນການມັນຈະບໍ່ສໍາເລັດ!
- ໃຊ້ຂັ້ນຕອນທີ່ເກັບໄວ້ (ຫຼືເຕັກນິກທີ່ຄ້າຍຄືກັນ) ເພື່ອປ້ອງກັນບໍ່ໃຫ້ຜູ້ໃຊ້ສາມາດພົວພັນກັບລະຫັດ SQL ໄດ້ໂດຍກົງ.