Oh no! Where's the JavaScript?
Your Web browser does not have JavaScript enabled or does not support JavaScript. Please enable JavaScript on your Web browser to properly view this Web site, or upgrade to a Web browser that does support JavaScript.

ລາວເຊີດລາວເຊີດລາວເຊີດ

ບົດຄວາມ

Secure Web Server

Secure Web Server

 I.      ສະພາບລວມ

ທຸກ​ມື້​ນີ້​ ເວບເຊີເວີ (Web server)  ​ເຄື່ອງໃດເຄື່ອງ​ໜຶ່ງ​ທີ່​ໃຫ້​ບໍລິການ​ເທິງ ອິນເຕີເນັດ ຈະ​ຖືກ​ໂຈມ​ຕີ​ຈາກ​ຜູ້​ປະສົງຮ້າຍ​​ຖື​ເປັນ​ເລື່ອງ​ປົກກະຕິ,ຈາກ​ຂໍ້​ມູນ​ຂອງເວບໄຊເກັບກຳສະຖິຕິການແຮັກ zone-h.org ພົບ​ວ່າ ສະເພາະ​ການ​ໂຈມ​ຕີ​ປະ​ເພດການປອມແປງໜ້າຕາຂອງເວັບ(Defacement) ທີ່​ມີ​ການ​ລາຍ​ງານ​ມາ​ທີ່ zone-h.org ໃນ​ປີ 2010 ແລະ 2011 ມີ​ເຖິງ​ເກືອບ 1.5 ລ້ານ​ຄັ້ງໃນ​ແຕ່​ລະ​ປີ ໂດຍ​ເພີ່ມ​ຂຶ້ນ​ຈາກ​ປີ​ 2009 ເກືອບ 3 ເທົ່າ  [1]ອາດຈະ​ບໍ່​ຫຼາຍເທົ່າໃດ​ເມື່ອ​ທຽບ​ກັບ​ຈຳນວນ Web site ທັງ​ໝົດ​ທີ່​ມີ​ຫຼາຍກວ່າ 500 ລ້ານ​ແຫ່ງ  [2] ໃນ​ປີ 2011. ແຕ່​ຕ້ອງ​ຢ່າ​ລືມ​ວ່າ zone-h ລາຍ​ງານ​ສະເພາະ​ການ​ໂຈມ​ຕີ​ປະ​ເພດ Defacement ທີ່​ມີ​ການ​ແຈ້ງ​ມາ​ໂດຍ​ກົງ​ເທົ່າ​ນັ້ນ ການ​ໂຈມ​ຕີ​ແບບ​ອື່ນ (ທີ່​ອາດ​ຮ້າຍແຮງ​ກວ່າ) ຫຼື​ ການ​ໂຈມ​ຕີ​ທີ່​ບໍ່​ຕ້ອງ​ການ​ໃຫ້ເປັນ​ທີ່​ຮັບ​ຮູ້​ຂອງ​ສາທາລະນະ​ຊົນ ຫຼື ​ບໍ່​ໄດ້​ມີ​ການ​ແຈ້ງ​ມາ​ໂດຍ​ກົງ ກໍ​ຈະ​ບໍ່​ໄດ້​ລວມ​ຢູ່ໃນ 1.5 ລ້ານ​ຄັ້ງ​ນີ້. ແຕ່​ບໍ່​ວ່າ​ຈະ​ຫຼາຍ ​ຫຼື ​ນ້ອຍຜູ້​ທີ່​ຢູ່ໃນ​ແວ​ດວົງ​ດ້ານ​ຄວາມປອດ​ໄພ ຫຼື ​ຜູ້​ທີ່​ມີ​ຫນ້າທີ່​ເບິ່ງແຍງ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ທັງ​ຫຼາຍກໍ​ຄົງ​ຮູ້​ດີວ່າ ປະຈຸບັນ​ການ​ໂຈມ​ຕີ​ເວບ​ໄຊ​ນັ້ນ ພົບ​ໄດ້​ເກືອບ​ຕະຫຼອດ​ເວລາ ພຽງ​ແຕ່​ເບິ່ງ​ຈາກ Log file ຂອງ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ເວບ ກໍ​ອາດຈະ​ພົບ​ຮ່ອງ​ຮອຍ​ ໃນ​ການ​ໂຈມ​ຕີ​ໄດ້​ຢ່າງ​ງາຍດາຍທັງ​ນີ້​ດ້ວຍ​ຄວາມ​ວ່ອງໄວ​ຂອງ​ການ​ເຜີຍແຜ່​ຂໍ້​ມູນ​ກ່ຽວກັບ​ຊ່ອງ​ໂຫວ່​ໃໝ່​ໆ ແລະ​ ຄວາມ​ສາມາດ​ຂອງ Google ໃນ​ການ​ຫາ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ເວັບໄຊ​ທີ່​ເປັນ​ເປົ້າ​ໝາຍ​ທີ່​ມີ​ຊ່ອງ​ໂຫວ່​ນັ້ນ ເຊັ່ນ: ບໍລິການ "Google Dork" ຫຼື "Google Hacking Database: GHDB" ເຮັດໃຫ້​ຜູ້​ເບິ່ງແຍງ​ລະບົບ​ຕ້ອງ​ພົບ​ກັບ​ຄວາມ​ຫຍຸ້ງຍາກ​ໃນ​ການຕິດ​ຕາມ​ຂ່າວ​ສານ​ເລື່ອງ​ຊ່ອງ​ໂຫວ່​  ແລະ​  ຫາ​ທາງ​ປ້ອງ​ກັນ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ເວບ​ໄຊທີ່​ຕົນ​ເບິ່ງແຍງ​ຢູ່​ຫຼາຍຄັ້ງ​

 II.    ຈຸດອ່ອນ

        ຈຸດ​ອ່ອນ​ ຂອງ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ເວບໄຊ ນັ້ນ​ບໍ່​ໄດ້​ຢູ່​ທີ່​ລະບົບ​ປະຕິບັດການ​ຂອງ​ເຄື່ອງ​ແມ່​ຂ່າຍ ​ຫຼື​ ຊ໋ອບແວສຳລັບ​ໃຫ້​ບໍລິການ​ເວບ (Web Server) ແຕ່​ຢູ່​ທີ່​ເວັບ​ແອບ​ພິ​ເຄ​ຊັ່ນ (Web Aplication) ເປັນ​ຫຼັກ ຫາກ​ເວບ​ໄຊ​ໃດ​ມີ​ຂໍ້​ມູນ​ສະເພາະ Static Web page ຫຼື Flat page  [3] ໂດຍ​ບໍ່​ມີ​ໄຟລສະ​ຄິບ PHP, ASP ຫຼື Dynamic content ໃດໆຢູ່ ​ເລີຍ​ກໍ​ອາດຈະ​ເຮັດໃຫ້ມີ​ຄວາມ​ສ່ຽງ​ຫຼາຍ​ທີ່​ຈະ​ຖືກ​ເຈາະ​ລະບົບ ​ຫຼື ຖືກ​ໂຈມ​ຕີ​ໄດ້​ສຳ​ເລັດຊຶ່ງ​ການ​ພັດທະນາ​ເວັບ​ໄຊ​ທີ່​ໃຊ້​ງານ​ສະເພາະ Static web page ຫຼື Flat page ແທບ​ຈະ​ເປັນ​ໄປ​ບໍ່​ໄດ້​ເລີຍ​ໃນ​ຍຸກ​ທີ່​ເວບ​ໄຊ​ປຽບ​ເໜືອນ​ຊ່ອງ​ທາງ​ຫຼັກ​ໃນ​ການເຮັດ​ທຸລະກິດ ຫຼື​ ແມ່ນແຕ່​ການ​ເຜີຍແຜ່​ຂໍ້​ມູນ​ໂດຍ​ທົ່ວ​ໄປ​ກໍ​ຍັງມີ​ການ​ນຳ Web application ປະ​ເພດ CMS ເຂົ້າ​ມາ​ໃຊ້​ເພື່ອ​ຄວາມສະດວກ​ໃນ​ການ​ຈັດ​ຮູບ​ແບບ​ເນື້ອ​ຫາ​ ແລະ​ ໃຫ້​ຄວາມສະດວກ​ແກ່​ຜູ້​ໃຊ້​ບໍລິການ ຖ້າຫາກ Web application ມີຄວາມ​ຊັບ​ຊ້ອນ​ເທົ່າ​ໃດ ກໍ​ຍິ່ງ​ມີ​ໂອ​ກາດ​ທີ່​ຈະ​ພົບ​ຊ່ອງ​ໂຫວ່​ຫຼາຍ​ຂຶ້ນ​ເທົ່າ​ນັ້ນ ແລະ ​ເມື່ອ Web application ມີ​ຊ່ອງ​ໂຫວ່ ກໍ​ເທົ່າ​ກັບ​ວ່າລະບົບ​ຕ່າງໆ​ທີ່​ເຮັດວຽກ​ຮ່ວມ​ກັບ​ເວບ​ໄຊ​ມີ​ຊ່ອງ​ໂຫວ່​ດ້ວຍ. ຊຶ່ງ​ອາດຈະ​ເຮັດໃຫ້​ເກີດ​ຈຸດ​ອ່ອນ​ກັບ​ລະບົບ​ປະຕິບັດການ​ ຫຼື​ ແມ່ນແຕ່​ເກີດ​ຈຸດ​ອ່ອນ​ກັບ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ເຄື່ອງ​ອື່ນໆ. ສ່ວນຫຼາຍຜູ້​ຊ່ຽວຊານ​ມັກ​ຈະ​ແນະ​ນຳ​ໃຫ້​ເລືອກ​ໃຊ້ Web application ທີ່​ເຊື່ອ​ຖື​ໄດ້ ແລະ​ ມີ​ການ Update ສະ​ໝ່ຳ​ສະເໝີ ໂດຍ​ສະເພາະ​ໃນ​ດ້ານ​ຄວາມປອດ​ໄພ ແຕ່​ຢ່າ​ລືມ​ວ່າ​ການ Update ເຫຼົ່າ​ນີ້ ມັກ​ຈະ​ເກີດ​ຂຶ້ນ​ຫລັງ​ຈາກ​ທີ່​ຜູ້​ພັດທະນາ​ໄດ້​ພົບ​ຈຸດ​ອ່ອນ​ທີ່​ເກີດ​ຈາກ​ການ​ໂຈມ​ຕີ​ໄດ້​ສຳ​ເລັດ​ຢູ່​ສະເໝີ ຫຼື ​ເຖິງແມ່ນ​ຈະ​ຍັງ​ບໍ່​ມີ​ການ​ພົບ​ຊ່ອງ​ໂຫວ່​ໃນ Web application ທີ່​ໃຊ້​ງານ​ຢູ່​ກໍ​ຕາມ ຜູ້​ເບິ່ງແຍງ​ລະບົບ​ກໍ​ຄວນ​ຮູ້ວ່າ ແມ່ນແຕ່​ການ Configuration ບາງ​ຮູບ​ແບບ​ເພື່ອ​ຕອບສະຫນອງ​ຄວາມ​ຕ້ອງ​ການ​ຂອງ User ກໍ​ອາດ​ເຮັດໃຫ້​ເກີດ​ຊ່ອງ​ໂຫວ່​ຂຶ້ນ​ມາ​ໄດ້​ເຊັ່ນ​ດຽວ​ກັນ, ດັ່ງ​ນັ້ນ​ເພື່ອ​ຮັກສາຄວາມ​ປອດ​ໄພ​ຂອງ​ເວບ​ໄຊ ທາງ​ທີມ​ງານ ລາວເຊີດໄດ້​ລວບລວມ ​ແລະ ​ນຳ​ສະເໜີ​ແນວ​ປະຕິບັດ​ໃນ​ການ​ເບິ່ງແຍງ​ເຄື່ອງ​ບໍລິການ​ເວັບ ໂດຍ​ອາໄສ​ຫຼັກ​ການ Security in-depth ກັບ​ພິຈາລະນາ​ເຖິງ​ອົງ​ປະກອບ​ແວດ​ລ້ອມ​ໃນ​ເຄື່ອງ​ບໍລິການ​ເວບ​ທັງ​ໝົດ ໂດຍ​ບໍ່​ເຈາະ​ຈົ່ງ​ລົງ​ໄປ​ໃນ​ຕົວ Web application ພຽງ​ຢ່າງ​ດຽວ ເພື່ອ​ລຸດ​ຜ່ອນໂອ​ກາດ​ຫຼື​ລຸດ​ຜ່ອນຄວາມ​ຮຸນແຮງ​ທີ່​ຈະ​ເກີດ​ຂຶ້ນ​ເມື່ອ​ຖືກ​ໂຈມ​ຕີ

 III.  ຂໍ້ຄວນລະວັງ

1. ລະ​ມັດ​ລະ​ວັງ​ Web server Process privilege ສ່ວນ​ຫຼາຍ Web application ຈະ​ເຮັດວຽກ​ພາຍໃຕ້​ສິດ (User ID) ຂອງ​ໂປຼ​ເຊດ Web server ໃຫ້​ລອງ​ຈິ​ນຕະນາ​ການ​ວ່າ ຫາກ Web application ຈະໂຈມຕີ​ລະບົບ​ຂອງ​ເຮົາ ດ້ວຍ​ສິດ​ທີ່​ທຽບ​ເທົ່າ Web server ຈະ​ເກີດ​ຜົນ​ຢ່າງໃດ​, ສ່ວນ​ຫຼາຍ​ລະບົບ​ປະຕິບັດການ​ລຸ້ນ​ໃໝ່​ໆຈະ​ບໍ່​ຄ່ອຍ​ໃຫ້ Web server ເຮັດວຽກ​ໃນ​ສິດ​ທິ​ຜູ້​ເບິ່ງແຍງ​ລະບົບ (root ຫຼື Administrator) ແລ້ວ ແຕ່​ອາດຈະ​ຕ້ອງ​ກວດ​ສອບ​ເບິ່ງ​ໃຫ້​ແນ່​ໃຈ​ອີກ​ເທື່ອ​ເປັນ​ລາຍ​ກໍລະນີ​ໄປ

2. ຈຳ​ກັດ​ສິດ​ໃນ​ການ​ຂຽນ​ໄຟລ​ຂອງ Web Application Web Application ອາດ​ຈຳ​ເປັນ​ຕ້ອງ​ຂຽນ​ໄຟລ​ລົງ​ໃນ File system ນຳ ເຊັ່ນ​ໃນ​ກໍລະນີ​ທີ່​ມີ​ການ Upload ຂໍ້​ມູນ ຫຼື​ ຂຽນ Temp ແຕ່ Web application ບໍ່​ຈຳ​ເປັນ​ຕ້ອງ​ຂຽນ​ຂໍ້​ມູນ​ລົງ​ໃນ​ທຸກ​ໆ Directory ດັ່ງ​ນັ້ນ​ຄວນ​ຈຳ​ກັດ​ສິດ​ຂອງ Web application ໃຫ້​ຂຽນ​ຂໍ້​ມູນ​ໄດ້​ໃນ​ທີ່​ໆ ຈຳ​ເປັນ​ຕ້ອງ​ຂຽນ​ເທົ່າ​ນັ້ນ

3. ແຍກ​ພື້ນ​ທີ່​ອັນຕະລາຍ ຫຼື Directory ທີ່ Web Application ໃຊ້​ເປັນ​ພື້ນ​ທີ່​ສຳລັບ​ໃຊ້​ງານ​ຊົ່ວ​ຄາວ ເຊັ່ນ​: ພື້ນ​ທີ່ Upload ຂໍ້​ມູນ​ຈາກ User ໃຫ້​ຖື​ວ່າ​ເປັນ​ພື້ນ​ທີ່​ອັນຕະລາຍ ເນື່ອງ​ຈາກ​ເຮົາ​ບໍ່​ສາມາດ​ຮັບ​ປະ​ກັນ​ໄດ້​ວ່າ​ຂໍ້​ມູນ​ທີ່ User ໃສ່​ເຂົ້າ​ມາ​ຈະ​ເປັນ Malicious code ຫຼື ​ບໍ່ດັ່ງ​ນັ້ນ​ການ​ປ້ອງ​ກັນ​ບໍ່​ໃຫ້ Execute ຫຼື Run ຂໍ້​ມູນ​ທີ່​ຢູ່ໃນ​ພື້ນ​ທີ່​ອັນຕະລາຍ​ນີ້​ຈຶ່ງ​ເປັນ​ສິ່ງ​ທີ່​ຕ້ອງ​ພິຈາລະນາ​ດຳ​ເນີນ​ການ

4. ພິ​ຈາ​ລະນາ​ໃຊ້​ງານ Chroot ຫຼື Jail (FreeBSD) ຖ້າ​ເປັນ​ໄປ​ໄດ້ ຄວນ Chroot ຫຼື Jail Web server  [4] ເພື່ອ​ປ້ອງ​ກັນ​ບໍ່​ໃຫ້ Web application ສາມາດ​ເຂົ້າ​ເຖິງ​ໄຟລ​ອື່ນໆ​ເທິງ​ລະບົບ​ປະຕິບັດການ​ໄດ້​ໂດຍ​ອິດສະຫລະ ການ​ໃຊ້ MAC (Mandatory Access Control) ຫຼື RBAC (Role-Based Access Control) ເຊັ່ນ SELinux  [5], AppArmor [6], Tomoyo [7] ຫຼື Grsecurity  [8] ກໍ​ເປັນ​ອີກ​ທາງ​ເລືອກ​ທີ່​ຜູ້​ເບິ່ງແຍງ​ລະບົບ​ໜ້າ​ຈະ​ພິຈາລະນາ​ເລືອກ​ໃຊ້​ໄດ້.

5. ຄວບ​ຄຸມ​ການ​ໃຊ້​ງານ Script ຄ້າຍ​ກັບ​ຂໍ້ 3 ແຕ່​ເປັນ​ຂໍ້​ກຳນົດ​ໃນ​ເຊີງ Web programming ຄື​: ການ​ກຳນົດ​ໃຫ້ Script ຫຼື Web application code ສາມາດ Run ຫຼື Execute ໃນ Directory ທີ່​ກຳນົດ​ໄວ້​ເທົ່າ​ນັ້ນ ເພື່ອ​ຫຼຸດຜ່ອນຄວາມ​ສ່ຽງ​ທີ່​ຈະ​ຖືກ​ໂຈມ​ຕີ​ໃນ​​ພື້ນ​ທີ່​ອັນຕະລາຍ​ເຊັ່ນ: ພື້ນ​ທີ່​ສຳລັບ​ເກັບ​ຮູບ​ພາບ, ທີ່​ມີ​ໂອ​ກາດ​ຖືກ​ອັບ​ໂຫຼດ​ໄຟລ Malicious code ຈາກ​ຜູ້​ບໍ່​ປະສົງ​ດີ ປະກອບ​ກັບ​ການ​ໃຊ້​ຊ່ອງ​ໂຫວ່​ໃນ​ການ​ເຂົ້າ​ໂຈມ​ຕີ​ແບບ Remote File Inclusion ທີ່​ສັ່ງ​ໃຫ້ Run ໄຟລເທິງ Directory ຕ່າງ ໆ​ໄດ້ ໂດຍ​ໃຊ້​ຫຼັກ​ການ Include file

6. ຈັບ​ຕາ​ເບິ່ງ Error message  404 /403 response ອາດ​ເປັນ​ເລື່ອງ​ປົກກະຕິ​ທີ່​ພົບ​ໄດ້​ທົ່ວ​ໄປ​ໃນ Log ຂອງ Web server ແຕ່​ຖ້າ​ພົບ​ໃນ​ຈຳນວນ​ຫຼາຍ ໃນ​ລະ​ຍະ​ເວລາ​ສັ້ນໆ ອາດ​ສະແດງ​ເຖິງ​ຄວາມ​ພະຍາຍາມ Scan ຫຼື Probe ຈາກ​ຜູ້​​ປະສົງ​ຮ້າຍ, ແຕ່​ໃນ​ປະຈຸບັນ​ທີ່​ມີ​ການ​ໃຊ້ Botnet ກັນ​ຢ່າງ​ກວ້າງ​ຂວາງ Request ເຫຼົ່າ​ນີ້ ອາດຈະ​ບໍ່​ໄດ້​ມາ​ຈາກ IP ດຽວ​ກັນ​ກໍ​ໄດ້ ຈຶ່ງ​ຈຳ​ເປັນ​ຕ້ອງ​ລະ​ມັດ​ລະ​ວັງ​ໃນ​ການ​ພິຈາລະນາ​ເປັນ​ພິເສດ

7. ຄວບ​ຄຸມ Web server ໃນ​ການ​ເອີ້ນຂໍ້​ມູນ​ພາຍນອກ Web server ບໍ່​ຄວນ​ມີ​ຄວາມ​ຈຳ​ເປັນ​ຕ້ອງ​ເອີ້ນຂໍ້​ມູນ​ຈາກ Internet ໂດຍ​ກົງ ຫາກ​ມີ​ຄວາມ​ຈຳ​ເປັນ​ຕ້ອງ​ດຶງ​ຂໍ້​ມູນ​ມາ Update ຄວນ​ໃຫ້​ເຮັດ​ຜ່ານ Proxy ແລະ​ມີ​ການ​ຄວບ​ຄຸມ URL ປາຍ​ທາງ​ຢ່າງ​ເຄັ່ງຄັດ ແລະ​ ຄວນ​ມີ​ການ Monitor ການ​ເອີ້ນຂໍ້​ມູນ​ທີ່​ນອກ​ເໜືອນ​ຈາກ​ທີ່​ກຳນົດ​ເພາະ​ອາດ​ສະແດງ​ໃຫ້​ເຫັນ​ວ່າ​ຜູ້​ບໍ່​ປະສົງ​ດີ ສາມາດ​ຄວບ​ຄຸມ Web server ເອົາ​ໄວ້​ໄດ້​ແລ້ວ.

8. Privilege ຂອງ Database user ກໍ​ສຳຄັນ Web application ແຕ່​ລະ​ອັນຄວນ​ໃຊ້ User ເທິງ Database ທີ່​ແຕກ​ຕ່າງ​ກັນ ເພື່ອ​ຄວາມສະດວກ​ໃນ​ການ Audit ແລະ ​ແຍກ​ສິດ​ໃນການ​ຂຽນ ຫຼື ອ່ານຂໍ້​ມູນ​ດ້ວຍ, ຖ້າ Web application ອັນໃດ​ບໍ່​ຕ້ອງການ Update ຂໍ້​ມູນ​ໃນ Database ຢ່າ​ໃຫ້ User ຂອງ Web appliaction ນັ້ນ​ມີ​ສິດ​ຂຽນ​ຂໍ້​ມູນ​ເດັດ​ຂາດ ແລະ ​ຄວນ​ຈຳ​ກັດ​ສິດ​ການ​ໃນ​ລະ​ດັບ Table ດ້ວຍ​ຖ້າ​ເປັນ​ໄປ​ໄດ້ ວິທີ​ການ​ນີ້​ຈະ​ຊ່ວຍ​ລຸດ​ຄວາມ​ຮຸນແຮງ​ຂອງ​ການ​ໂຈມ​ຕີ​ປະ​ເພດ SQLi (SQL Injection) ໄດ້

9. ພິຈາລະນາ Data type ຂອງ Web application parameter ການ​ພັດທະນາ Web application ທີ່​ດີ ຄວນ​ຈຳ​ກັດ​ແລະ​ກວດ​ສອບ​ຊະນິດ​ຂອງ​ຂໍ້​ມູນ​ທີ່​ຮັບ​ສົ່ງ​ກັບ User ທຸກ​ຄັ້ງ ເຊັ່ນ​: ຖ້າ​ຂໍ້​ມູນ​ທີ່​ຈະ​ຮັບ​ເຂົ້າ​ມາ​ເປັນ ID ຂອງ​ບົດ​ຄວາມ ກໍ​ບໍ່​ຄວນ​ໃຫ້​ມີ​ຂໍ້​ມູນ​ອື່ນ​ນອກ​ຈາກ Digit ເຂົ້າ​ມາ​ໃນ Parameter ນັ້ນ ຫຼື ​ຖ້າ​ເປັນ Alphanumeric ກໍ​ບໍ່​ຄວນ​ໃຫ້​ມີ​ສັນຍະລັກ​ເຂົ້າ​ມາ​ປະ​ປົນເປັນ​ຕົ້ນ

10. ຈັບ​ຕາ​ເບິ່ງ​ການ​ປ່ຽນ​ແປງ ເຄື່ອງ​ມື​ສຳລັບ​ກວດ​ສອບ​ການ​ປ່ຽນ​ແປງ​ຂອງ​ໄຟລຢ່າງ Tripwire ຫຼື AIDE ເປັນ​ເຄື່ອງ​ມື​ທີ່​ດີ​ທີ່​ຈະ​ໃຊ້​ບອກວ່າ​ມີ​ສິ່ງ​ບໍ່​ຊອບມາ​ພາ​ກົນ​ຂຶ້ນ​ໃນ Web server ເພາະ​ບາງເທື່ອ ຜູ້​​ປະສົງຮ້າຍ​ຈະ​ຖິ້ມ​ໂປຼແກມ​ປະ​ເພດ Backdoor ໄວ້​ເພື່ອ​ໃຫ້​ສະ​ດວກ​ໃນ​ການ​ຄວບ​ຄຸມ Web server ຫຼື​ ອາດ​ເປັນ​ການ​ຕິດ​ຕັ້ງ​ໂປຼ​ແກມ​ປະ​ເພດ Trojan ຫຼື Bot ກໍ​ໄດ້ ແຕ່​ຄວນ​ໃຊ້​ຢ່າງ​ລະ​ມັດ​ລະ​ວັງ ເພາະ​ການ​ປ່ຽນ​ແປງ​ຂອງ​ໄຟລໃນ​ລະບົບ​ບາງຢ່າງ ອາດ​ບໍ່​ໄດ້​ໝາຍ​ເຖິງ​ສິ່ງ​ຜິດ​ປົກກະຕິ​ກໍ​ໄດ້ ເຊັ່ນ: Log ຫຼື Temp ທີ່​ມີ​ການ​ປ່ຽນ​ແປງ​ຢູ່​ເປັນ​ປົກກະຕິ​ຢູ່​ແລ້ວ

11. ຖື​ວ່າ​ຂໍ້​ມູນ​ຈາກ Client ເປັນ Untrusted Script ຫຍັງ​ກໍ​ຕາມ​ທີ່​ເຮັດວຽກ​ໃນ​ຝັ່ງ Client ເຊັ່ນ: Javascript ຫຼື ​ແມ່ນແຕ່ Flash ຫຼື Java ທັງ​ຫຼາຍ​ເຫຼົ່າ​ນີ້​ອາດຈະ​ຖືກ Compromise ໄດ້​ບໍ່​ຍາກ ເພາະ​ສະ​ນັ້ນ Web application ທີ່​ດີ​ບໍ່​ຄວນ​ໃຊ້​ວິທີ​ການ​ກວດ​ສອບ​ການ​ສົ່ງ​ຂໍ້​ມູນ​ໂດຍ​ວິທີ​ການ​ເຫຼົ່າ​ນີ້​ເປັນ​ອັນ​ຂາດ ເຊັ່ນ: ການ​ໃຊ້ Javascript ກວດ​ສອບ​ຂໍ້​ມູນ​ທີ່ User ປ້ອນ​ເຂົ້າ​ມາ ເພາະ​ຜູ້​ປະສົງ​ຮ້າຍ​ສາມາດ Bypass ການ​ກວດ​ສອບ​ນີ້​ໄດ້​ຢ່າງ​ງ່າຍ​ດາຍ​ຈາກ​ໂປຼ​ແກມ​ທົ່ວ​ໄປ ເຊັ່ນ: NoScript  [9] ຫຼື ​ແມ່ນແຕ່​ສິ່ງ​ທີ່​ຮັບ​ມາ​ຈາກ Client ເຊັ່ນ​: ຄ່າ​ຈາກ​ຕົວ​ແປ​ຕ່າງໆ ກໍ​ຄວນ​ສົງ​ໄສ​ໄວ້​ກ່ອນ​ເພະວ່າ​ມີ​ໂອ​ກາດ​ເປັນ​ຂໍ້​ມູນ​ບໍ່​ພຶງ​ປະສົງ​ໄດ້

12. ຄວນ​ເລືອກ​ໃຊ້​ເຄື່ອງ​ມື​ທີ່​ຊຳ​ນານ ການ​ເລືອກ​ໃຊ້​ເຄື່ອງ​ມື​ຕ່າງໆ ເຊັ່ນ: Web server, Web application platform ຫຼື CMS ຄວນ​ເລືອກ​ທີ່​ຄວາມ​ຄຸ້ນ​ເຄີຍ​ຫຼາຍກວ່າ​ຄວາມ​ສວຍງາມ ​ຫຼື​ ທັນ​ສະໄໝ ເພາະ​ເວລາ​ມີ​ບັນຫາ​ຈະ​ສາມາດ​ເຂົ້າ​ກວດ​ສອບ​ ແລະ ​ແກ້​ໄຂ​ໄດ້​ງ່າຍ ແລະ​ ຢ່າ​ລືມ​ວ່າ​ເຄື່ອງ​ມື​ທີ່​ດີກວ່າ​ ຫຼື​ ໃໝ່​ກວ່າ ບໍ່​ໄດ້​ແປ​ວ່າ​ຈະ​ບໍ່​ມີ​ໂອ​ກາດ​ເກີດ​ບັນຫາ​ເລີຍ ຫຼື​ ໃນ​ອີກ​ມຸມ​ໜຶ່ງ​ການ​ໃຊ້​ງານ​ເຄື່ອງ​ມື​ທີ່​ພັດທະນາ​ຂຶ້ນ​ໃໝ່​ອາດ​​ເປັນ​ໜູ​ທົດລອງ​ສຳລັບ​ການ​ທົດສອບ​ຜະລິດຕະພັນ​ກໍ​ເປັນ​ໄດ້ ຊຶ່ງ​ຈະ​ກໍ່​ໃຫ້​ເກີດ​ບັນຫາ​ດ້ານ​ຄວາມປອດ​ໄພ​ຕາມ​ມາ

13. ພະຍາຍາມ​ເຮັດ​ຕາມ​ມາດຕະຖານ ການ​ເຂົ້າ​ລະ​ຫັດ​ແບບ​ຄິດ​ຄົ້ນ​ເອງ ການ​ຈັດການ Session ແບບ​ບໍ່​ມີ​ມາດຕະຖານ ຫຼື ​ແມ່ນແຕ່​ການ​ພັດທະນາ Web application ໃນ​ຮູບ​ແບບ​ແປກໆ ມັກ​ຈະ​ເກີດ​ບັນຫາ​ໄດ້​ງ່າຍ​ກວ່າ​ແບບ​ເດີມ​ທີ່​ນິຍົມ​ໃຊ້​ກັນ ຫຼາຍ​ຄົນ​ເຊື່ອ​ຢ່າງ​ຜິດໆ ວ່າ​ການ​ໃຊ້​ສິ່ງ​ທີ່​ຄົນ​ທົ່ວ​ໄປ​ໃຊ້​ກັນ ຫຼື​ ການ​ໃຊ້ Open source /Open Standard ທີ່​ເປີດ​ໂອ​ກາດ​ໃຫ້​ຄົນ​ເຫັນ Source code ຫຼື Algorithm ຢ່າງ​ເປີດ​ເຜີຍ​ນັ້ນ​ບໍ່​ມີ​ຄວາມປອດ​ໄພ ແຕ່​ກໍ​ຕ້ອງ​ຢ່າ​ລືມ​ວ່າ ໂປຼ​ແກມ​ເຂົ້າ​ລະ​ຫັດ​ທີ່​ຍອມ​ຮັບ​ກັນ​ວ່າ​ປອດ​ໄພ​ທີ່ສຸດ​ໃນ​ຂະນະ​ນີ້​ກໍ​ເປັນ Open standard ຢູ່ ເຊັ່ນ OpenSSL  [10]

14. ບໍ່​ຄວນ​ສະແດງ Error message ໃຫ້ User ເຫັນຂໍ້​ຜິດ​ພາດ​ຂອງ Web application (Error message) ທີ່​ສະແດງ​ໃຫ້​ຄົນ​ອື່ນ​ເຫັນ​ໂດຍ​ບໍ່​ຕັ້ງ​ໃຈ ຖື​ເປັນ​ເລື່ອງ​ທີ່​ຮັບ​ບໍ່​ໄດ້​ ແລະ​ ໜ້າ​ອັບ​ອາຍ​ສຳລັບ​ຄົນ​ພັດທະນາ Web application ເພາະ​ສະແດງ​ເຖິງ​ຄວາມ​ບໍ່​ເປັນ Professional ຊ້ຳ​ຮ້າຍ​ຍັງ​ກາຍ​ເປັນ​ຜູ້​ສະໜັບສະໜູນ​ຂໍ້​ມູນ​ໃນ​ການ​ເຂົ້າ​ໂຈມ​ຕີ​ເວັບ​ໄຊ​ຈາກ​ຂໍ້​ມູນ​ທີ່​ສະແດງ​ອອກ​ໄປ​ອີກ​ດ້ວຍ ເຊັ່ນ: ຂໍ້​ຜິດ​ພາດ​ສະແດງ​ທີ່​ຢູ່​ຂອງ​ໄຟລໃນ​ລະບົບ ຫຼື​ ຊື່​ຂອງ Database ເປັນ​ຕົ້ນ ເພາະ​ສະ​ນັ້ນ Web application ທີ່​ດີຕ້ອງ​ບໍ່​ສະແດງ Error message ອອກ​ມາ​ໃຫ້​ເຫັນ​ເມື່ອ​ເກີດ​ຄວາມ​ຜິດ​ພາດ ຊຶ່ງ​ການ​ຈັດການ Exception ທີ່​ດີ​ຖື​ເປັນ​ອີກ​ວິທີ​ໜຶ່ງ​ທີ່​ຈະ​ຫຼຸດ​ບັນຫາ​ຂໍ້​ນີ້

15. ຈັບ​ຕາ​ການ Re-attempt ໂດຍ​ປົກກະຕິ ຄົົນທີ່​ລືມ Password ຍ່ອມ​​ອົດ​ທົນ​ໃສ່ Password ທີ່​ຜິດ​ເປັນ​ສິບໆເທື່ອ​ຕໍ່​ເນື່ອງ ເຊັນດຽວ​ກັນຄົງ​ບໍ່​ມີ​ໃຜ​ສົ່ງ​ຄ່າ Parameter ຕົວ​ດຽວ​ໄປ​ເລື່ອຍ​ໆ ຢ່າງ​ຕໍ່​ເນື່ອງ​ເຊັນ​ກັນ ການ Re-attempt ໃນ​ລັກສະນະ​ນີ້ ອາດ​ເກີດ​ຈາກ​ເຄື່ອງ​ມື​ພິເສດ​ທີ່​ໃຊ້​ຫາ​ຊ່ອງ​ໂຫວ່​ຂອງ​ລະບົບ (Brute Force) ຫຼື​ ເຄື່ອງ​ມື​ເດົາ Password ຫຼາຍກວ່າ

16. Web application ຕົວ​ອື່ນ​ກໍ​ສຳຄັນ Web application ທີ່​ຂຽນ​ຂຶ້ນ​ຢ່າງ​ດີ ມີ​ຄວາມ​ປອດ​ໄພ​ສູງ ແຕ່​ເມື່ອ​ໄປ​ຢູ່​ຮ່ວມ​ກັບ Web application ທີ່​ມີ​ຊ່ອງ​ໂຫວ່ ເທິງ Web server ຕົວ​ດຽວ​ກັນ ຍ່ອມ​ມີ​ຄວາມ​ສ່ຽງ​ທີ່ເກິດຂື້ນ​ທຽບ​ເທົ່າ​ກັນ ເວັ້ນ​ແຕ່ Web server ຈະ​ມີ​ການ​ແຍກ Privilege ລະຫວ່າງ Web application ແຕ່​ລະ​ຕົວ​ໄດ້ ເຊັ່ນ ການ​ໃຊ້ suEXEC  [11]

ເອກະສານອ້າງອິງ 

[1] http://www.zone-h.org/stats/ymd
[2] http://news.netcraft.com/archives/2011/12/09/december-2011-web-server-survey.html
[3] http://en.wikipedia.org/wiki/Static_web_page
[4] http://en.wikipedia.org/wiki/Chroot
[5] http://selinuxproject.org/page/Main_Page
[6] http://wiki.apparmor.net/index.php/Main_Page
[7] http://tomoyo.sourceforge.jp
[8] http://grsecurity.net/index.php
[9] https://addons.mozilla.org/en-US/firefox/addon/noscript
[10] http://www.openssl.org
[11] http://httpd.apache.org/docs/2.0/suexec.html

Porher 14 October 2020 2505 reads Print