ສະຖິຕິຜູ້ເຂົ້າເບີ່ງເວບໄຊທ໌

› ອອນລາຍ :1
› ມື້ນີ້ :2
› ມື້ວານນີ້ :55
› ອາທິດນີ້ :57
› ເດືອນນີ້ :418

ຈຳນວນຜູ້ເຂົ້າເບີ່ງ : 755218
ເວບໄຊທ໌ເປີດມາໄດ້ 2441 ວັນ
309 ຄົນ / ວັນ

ຮ່ວມມື ASEAN-Japan


ລາວເຊີດ Partners

ເລືອກພາສາ (Language)

ຊ່ອງທາງຕິດຕາມ ລາວເຊີດ

  

Poster ອາຊຽນ-ຍີ່ປຸ່ນ

ປີ 2018

ປີ 2017

ປີ 2016

ເບີ່ງທັງໝົດ

ພຶດຕິກໍາທີ່ເປັນອາຊະຍາກໍາທາງລະບົບຄອມພີວເຕີ ທີ່ໄດ້ລະບຸໄວ້ຢູ່ໃນ ກົດໝາຍ: ວ່າດວ້ຍ ການຕ້ານ ແລະ ສະກັດກັ້ນອາຊະຍາກໍາທາງລະບົບຄອມພີວເຕີ ລວມມີພຶດຕິກໍາດັ່ງນີ້: 1. ການເປີດເຜີຍມາດຕະການປ້ອງກັນການເຂົ້າເຖິງລະບົບຄອມພິວເຕີ; 2. ການເຂົ້າເຖິງລະບົບຄອມພິວເຕີ ໂດຍນບໍ່ໄດ້ຮັບອະນຸຍາດ; 3. ການຕັດຕໍ່ເນື້ອໃນ, ຮູບ, ພາບເຄື່ອນໄຫວ, ສຽງ ແລະ ວີດີໂອ ໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ; 4. ການລັດເອົາຂໍ້ມູນໃນລະບົບຄອມພິວເຕີ ໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ; 5. ການສ້າງຄວາມເສັຍຫາຍຜ່ານສື່ສັງຄົມອອນລາຍ; 6. ການເຜີຍແຜ່ສິ່ງລາມົກຜ່ານລະບົບຄອມພິວເຕີ; 7. ການລົບກວນລະບົບຄອມພິວເຕີ; 8. ການປອມແປງຂໍ້ມູນຄອມພິວເຕີ; 9. ການທຳລາຍຂໍ້ມູນ-ຄອມພິວເຕີ; 10. ການດຳເນີນກິດຈະການ ກ່ຽວກັບເຄື່ອງມືອາຊະຍາກຳທາງລະບົບຄອມພິວເຕີ.

Secure Web ServerShare to Facebook ພິມ

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