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 2472 reads
Print
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
