ບາບທີ່ຕາຍແລ້ວຂອງຄວາມປອດໄພຂອງເວັບໄຊທ໌: ສິ່ງທີ່ພວກເຮົາໄດ້ຮຽນຮູ້ຈາກສະຖິຕິເຄື່ອງສະແກນຄວາມອ່ອນແອສໍາລັບປີ

ປະມານຫນຶ່ງປີກ່ອນຫນ້ານີ້, ພວກເຮົາຢູ່ທີ່ DataLine ເປີດຕົວ ການບໍລິການ ເພື່ອຊອກຫາ ແລະວິເຄາະຊ່ອງໂຫວ່ໃນແອັບພລິເຄຊັນ IT. ການບໍລິການແມ່ນອີງໃສ່ການແກ້ໄຂຄລາວຂອງ Qualys, ກ່ຽວກັບການດໍາເນີນການ ພວກເຮົາບອກແລ້ວ. ໃນໄລຍະຫນຶ່ງປີຂອງການເຮັດວຽກກັບການແກ້ໄຂ, ພວກເຮົາໄດ້ດໍາເນີນການ 291 scans ສໍາລັບສະຖານທີ່ທີ່ແຕກຕ່າງກັນແລະສະສົມສະຖິຕິກ່ຽວກັບຈຸດອ່ອນທົ່ວໄປໃນຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌. 

ໃນບົດຄວາມຂ້າງລຸ່ມນີ້ຂ້າພະເຈົ້າຈະສະແດງໃຫ້ທ່ານຮູ້ວ່າຂຸມໃນຄວາມປອດໄພຂອງເວັບໄຊທ໌ໄດ້ຖືກເຊື່ອງໄວ້ຢູ່ຫລັງລະດັບຄວາມວິຈານທີ່ແຕກຕ່າງກັນ. ຂໍໃຫ້ເບິ່ງວ່າມີຊ່ອງຫວ່າງໃດແດ່ທີ່ເຄື່ອງສະແກນພົບເລື້ອຍໆ, ເປັນຫຍັງພວກມັນອາດຈະເກີດຂຶ້ນ, ແລະວິທີປ້ອງກັນຕົນເອງ. 

Qualys ແບ່ງຊ່ອງໂຫວ່ຂອງແອັບພລິເຄຊັນເວັບທັງໝົດອອກເປັນສາມລະດັບຄວາມສຳຄັນຄື: ຕ່ຳ, ປານກາງ ແລະສູງ. ຖ້າທ່ານເບິ່ງການແຜ່ກະຈາຍໂດຍ "ຄວາມຮຸນແຮງ", ມັນເບິ່ງຄືວ່າທຸກສິ່ງທຸກຢ່າງບໍ່ຮ້າຍແຮງ. ມີຊ່ອງໂຫວ່ໜ້ອຍທີ່ມີລະດັບວິພາກວິຈານສູງ, ສ່ວນຫຼາຍແລ້ວທັງໝົດແມ່ນບໍ່ສຳຄັນ: 

ແຕ່ uncritical ບໍ່ໄດ້ຫມາຍຄວາມວ່າເປັນອັນຕະລາຍ. ພວກເຂົາຍັງສາມາດເຮັດໃຫ້ເກີດຄວາມເສຍຫາຍຮ້າຍແຮງ. 

ຊ່ອງໂຫວ່ “ບໍ່ສຳຄັນ” ອັນດັບຕົ້ນໆ

1. ຄວາມອ່ອນແອຂອງເນື້ອຫາແບບປະສົມ.

   ມາດຕະຖານສໍາລັບຄວາມປອດໄພຂອງເວັບໄຊທ໌ແມ່ນການໂອນຂໍ້ມູນລະຫວ່າງລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍຜ່ານໂປໂຕຄອນ HTTPS, ເຊິ່ງສະຫນັບສະຫນູນການເຂົ້າລະຫັດແລະປົກປ້ອງຂໍ້ມູນຈາກການຂັດຂວາງ. 

   ບາງສະຖານທີ່ໃຊ້ ເນື້ອ​ໃນ​ປະ​ສົມ​: ບາງຂໍ້ມູນຖືກໂອນຜ່ານໂປຣໂຕຄໍ HTTP ທີ່ບໍ່ປອດໄພ. ນີ້ແມ່ນວິທີທີ່ມັນຖືກຖ່າຍທອດຫຼາຍທີ່ສຸດ ເນື້ອໃນຕົວຕັ້ງຕົວຕີ – ຂໍ້​ມູນ​ທີ່​ມີ​ຜົນ​ກະ​ທົບ​ພຽງ​ແຕ່​ການ​ສະ​ແດງ​ຂອງ​ເວັບ​ໄຊ​ໄດ້​: ຮູບ​ພາບ​, ຮູບ​ແບບ css​. ແຕ່ບາງຄັ້ງນີ້ແມ່ນວິທີການຖ່າຍທອດ ເນື້ອໃນການເຄື່ອນໄຫວ: scripts ທີ່ຄວບຄຸມພຶດຕິກໍາຂອງເວັບໄຊທ໌. ໃນກໍລະນີນີ້, ການນໍາໃຊ້ຊອບແວພິເສດ, ທ່ານສາມາດວິເຄາະຂໍ້ມູນທີ່ມີເນື້ອຫາທີ່ມີການເຄື່ອນໄຫວມາຈາກເຄື່ອງແມ່ຂ່າຍ, ດັດແປງການຕອບສະຫນອງຂອງທ່ານໃນການບິນແລະເຮັດໃຫ້ເຄື່ອງຈັກເຮັດວຽກໃນທາງທີ່ບໍ່ໄດ້ຕັ້ງໃຈໂດຍຜູ້ສ້າງຂອງມັນ. 

   ເວີຊັນໃໝ່ຂອງຕົວທ່ອງເວັບເຕືອນຜູ້ໃຊ້ວ່າເວັບໄຊທ໌ທີ່ມີເນື້ອຫາປະສົມບໍ່ປອດໄພແລະຂັດຂວາງເນື້ອຫາ. ຜູ້ພັດທະນາເວັບໄຊທ໌ຍັງໄດ້ຮັບການເຕືອນຂອງຕົວທ່ອງເວັບໃນ console. ຕົວຢ່າງ, ນີ້ແມ່ນວິທີທີ່ມັນເບິ່ງຢູ່ໃນ Firefox: 

   
   
   ສິ່ງທີ່ເປັນອັນຕະລາຍ: ຜູ້ໂຈມຕີໃຊ້ໂປໂຕຄອນທີ່ບໍ່ປອດໄພເພື່ອຂັດຂວາງຂໍ້ມູນຜູ້ໃຊ້, ແທນທີ່ສະຄິບແລະສົ່ງຄໍາຮ້ອງຂໍໄປຫາເວັບໄຊທ໌ໃນນາມຂອງລາວ. ເຖິງແມ່ນວ່າຜູ້ເຂົ້າຊົມເວັບໄຊທ໌ບໍ່ໄດ້ໃສ່ຂໍ້ມູນ, ນີ້ບໍ່ໄດ້ປົກປ້ອງລາວຈາກ ຟິດຊິງ – ໄດ້​ຮັບ​ຂໍ້​ມູນ​ທີ່​ເປັນ​ຄວາມ​ລັບ​ໂດຍ​ໃຊ້​ວິ​ທີ​ການ​ສໍ້​ໂກງ​. ຕົວຢ່າງ, ການນໍາໃຊ້ສະຄິບ, ທ່ານສາມາດປ່ຽນເສັ້ນທາງຜູ້ໃຊ້ໄປຫາເວັບໄຊທ໌ທີ່ບໍ່ປອດໄພທີ່ປອມຕົວເປັນຫນຶ່ງທີ່ຄຸ້ນເຄີຍກັບຜູ້ໃຊ້. ໃນບາງກໍລະນີ, ເວັບໄຊທ໌ທີ່ເປັນອັນຕະລາຍເບິ່ງດີກ່ວາຕົ້ນສະບັບ, ແລະຜູ້ໃຊ້ສາມາດຕື່ມຂໍ້ມູນໃສ່ແບບຟອມດ້ວຍຕົນເອງແລະສົ່ງຂໍ້ມູນລັບ. 

   ສິ່ງທີ່ນັກພັດທະນາເວັບຄວນຈື່: ເຖິງແມ່ນວ່າຜູ້ເບິ່ງແຍງເວັບໄຊທ໌ໄດ້ຕິດຕັ້ງແລະກໍາຫນົດຄ່າໃບຢັ້ງຢືນ SSL/TLS, ຊ່ອງໂຫວ່ອາດຈະເກີດຂື້ນຍ້ອນຄວາມຜິດພາດຂອງມະນຸດ. ຕົວຢ່າງ, ຖ້າຢູ່ໃນຫນ້າຫນຶ່ງທີ່ທ່ານໃສ່ບໍ່ແມ່ນການເຊື່ອມຕໍ່ພີ່ນ້ອງ, ແຕ່ການເຊື່ອມຕໍ່ຢ່າງແທ້ຈິງຈາກ http, ແລະນອກຈາກນັ້ນ, ທ່ານບໍ່ໄດ້ຕັ້ງຄ່າການປ່ຽນເສັ້ນທາງຈາກ http ໄປ https. 

   ທ່ານ​ສາ​ມາດ​ກວດ​ພົບ​ເນື້ອ​ໃນ​ປະ​ສົມ​ຢູ່​ໃນ​ເວັບ​ໄຊ​ໄດ້​ໂດຍ​ການ​ນໍາ​ໃຊ້​ຕົວ​ທ່ອງ​ເວັບ​: ຄົ້ນ​ຫາ​ທີ່​ມາ​ຂອງ​ລະ​ຫັດ​ຂອງ​ຫນ້າ​, ອ່ານ​ແຈ້ງ​ການ​ໃນ​ການ​ພັດ​ທະ​ນາ console​. ຢ່າງໃດກໍຕາມ, ນັກພັດທະນາຈະຕ້ອງ tinker ກັບລະຫັດເປັນເວລາດົນນານແລະ tediously. ທ່ານສາມາດເລັ່ງຂະບວນການດ້ວຍເຄື່ອງມືການວິເຄາະອັດຕະໂນມັດ, ຕົວຢ່າງ: ກວດສອບ SSL, ຊອບແວ Lighthouse ຟຣີຫຼືຊອບແວທີ່ຈ່າຍ Screaming Frog SEO Spider.

   ນອກຈາກນີ້, ຊ່ອງໂຫວ່ອາດຈະເກີດຂື້ນຍ້ອນບັນຫາກັບ legacy-code - ລະຫັດທີ່ຖືກສືບທອດ. ຕົວຢ່າງ, ຖ້າບາງຫນ້າຖືກສ້າງຂື້ນໂດຍໃຊ້ແມ່ແບບເກົ່າ, ເຊິ່ງບໍ່ໄດ້ຄໍານຶງເຖິງການປ່ຽນເວັບໄຊທ໌ໄປຫາ https.    

2. ຄຸກກີທີ່ບໍ່ມີທຸງ "HTTPOnly" ແລະ "ປອດໄພ".

   ຄຸນສົມບັດ "HTTPOnly" ປົກປ້ອງຄຸກກີຈາກການຖືກປະມວນຜົນໂດຍສະຄຣິບທີ່ຜູ້ໂຈມຕີໃຊ້ເພື່ອລັກຂໍ້ມູນຜູ້ໃຊ້. ທຸງ "ປອດໄພ" ບໍ່ອະນຸຍາດໃຫ້ສົ່ງ cookies ໃນຂໍ້ຄວາມທີ່ຊັດເຈນ. ການສື່ສານຈະຖືກອະນຸຍາດພຽງແຕ່ຖ້າໂປໂຕຄອນ HTTPS ທີ່ປອດໄພຖືກໃຊ້ເພື່ອສົ່ງ cookies. 

   ຄຸນລັກສະນະທັງສອງຖືກລະບຸໄວ້ໃນຄຸນສົມບັດຂອງຄຸກກີ:

   Set-Cookie: Secure; HttpOnly

   ສິ່ງທີ່ເປັນອັນຕະລາຍ: ຖ້າຜູ້ພັດທະນາເວັບໄຊທ໌ບໍ່ໄດ້ລະບຸຄຸນລັກສະນະເຫຼົ່ານີ້, ຜູ້ໂຈມຕີສາມາດຂັດຂວາງຂໍ້ມູນຂອງຜູ້ໃຊ້ຈາກຄຸກກີແລະຂຸດຄົ້ນມັນ. ຖ້າ cookies ຖືກນໍາໃຊ້ສໍາລັບການຢັ້ງຢືນແລະການອະນຸຍາດ, ລາວຈະສາມາດ hijack ເຊດຊັນຂອງຜູ້ໃຊ້ແລະດໍາເນີນການໃນເວັບໄຊທ໌ໃນນາມຂອງລາວ. 

   ສິ່ງທີ່ນັກພັດທະນາເວັບຄວນຈື່: ຕາມກົດລະບຽບ, ໃນກອບທີ່ນິຍົມຄຸນລັກສະນະເຫຼົ່ານີ້ຖືກຕັ້ງໂດຍອັດຕະໂນມັດ. ແຕ່ຍັງຄົງກວດເບິ່ງການຕັ້ງຄ່າເວັບເຊີຟເວີແລະກໍານົດທຸງ: Set-Cookie HttpOnly; ປອດໄພ.

   ໃນກໍລະນີນີ້, ຄຸນລັກສະນະ "HTTPOnly" ຈະເຮັດໃຫ້ cookies ເບິ່ງເຫັນ JavaScript ຂອງທ່ານເອງ.  

3. ຊ່ອງໂຫວ່ທີ່ອີງໃສ່ເສັ້ນທາງ.

   ເຄື່ອງສະແກນລາຍງານຄວາມອ່ອນແອດັ່ງກ່າວຖ້າມັນພົບເຫັນໄຟລ໌ທີ່ສາມາດເຂົ້າເຖິງສາທາລະນະຫຼືໄດເລກະທໍລີເວັບໄຊທ໌ທີ່ມີຂໍ້ມູນທີ່ມີຄວາມລັບ. ຕົວຢ່າງ, ມັນກວດພົບໄຟລ໌ການຕັ້ງຄ່າລະບົບແຕ່ລະຄົນ ຫຼືເຂົ້າເຖິງລະບົບໄຟລ໌ທັງໝົດ. ສະຖານະການນີ້ເປັນໄປໄດ້ຖ້າສິດການເຂົ້າເຖິງຖືກຕັ້ງບໍ່ຖືກຕ້ອງຢູ່ໃນເວັບໄຊທ໌.

   ສິ່ງທີ່ເປັນອັນຕະລາຍ: ຖ້າລະບົບໄຟລ໌ "ຕິດອອກ", ຜູ້ໂຈມຕີສາມາດເຂົ້າໄປໃນການໂຕ້ຕອບຂອງລະບົບປະຕິບັດການແລະພະຍາຍາມຊອກຫາໂຟນເດີທີ່ມີລະຫັດຜ່ານຖ້າພວກມັນຖືກເກັບໄວ້ໃນຂໍ້ຄວາມທີ່ຊັດເຈນ (ຢ່າເຮັດແນວນັ້ນ!). ຫຼືທ່ານສາມາດລັກລະຫັດຜ່ານ hashes ແລະ brute ບັງຄັບລະຫັດຜ່ານ, ແລະຍັງພະຍາຍາມທີ່ຈະຍົກສູງສິດທິໃນລະບົບແລະຍ້າຍເລິກເຂົ້າໄປໃນໂຄງສ້າງພື້ນຖານ.  

   ສິ່ງທີ່ນັກພັດທະນາເວັບຄວນຈື່: ຢ່າລືມກ່ຽວກັບສິດທິໃນການເຂົ້າເຖິງແລະກໍາຫນົດຄ່າແພລະຕະຟອມ, ເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌, ຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ເພື່ອວ່າມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະ "ຫນີ" ໄດເລກະທໍລີເວັບ.

4. ແບບຟອມສໍາລັບການປ້ອນຂໍ້ມູນທີ່ລະອຽດອ່ອນດ້ວຍການຕື່ມຂໍ້ມູນອັດຕະໂນມັດເປີດ.

   ຖ້າຜູ້ໃຊ້ມັກຈະຕື່ມແບບຟອມຢູ່ໃນເວັບໄຊທ໌, ຕົວທ່ອງເວັບຂອງພວກເຂົາເກັບຮັກສາຂໍ້ມູນນີ້ໂດຍໃຊ້ຄຸນສົມບັດການຕື່ມຂໍ້ມູນອັດຕະໂນມັດ. 

   ແບບຟອມຢູ່ໃນເວັບໄຊທ໌ອາດຈະປະກອບມີຊ່ອງຂໍ້ມູນທີ່ມີຂໍ້ມູນລະອຽດອ່ອນ, ເຊັ່ນ: ລະຫັດຜ່ານຫຼືເລກບັດເຄຣດິດ. ສໍາລັບຂົງເຂດດັ່ງກ່າວ, ມັນເປັນມູນຄ່າທີ່ຈະປິດການທໍາງານການຕື່ມຂໍ້ມູນອັດຕະໂນມັດຢູ່ໃນເວັບໄຊຂອງມັນເອງ. 

   ສິ່ງທີ່ເປັນອັນຕະລາຍ: ຖ້າຕົວທ່ອງເວັບຂອງຜູ້ໃຊ້ເກັບຂໍ້ມູນທີ່ລະອຽດອ່ອນ, ຜູ້ໂຈມຕີສາມາດຂັດຂວາງມັນໃນພາຍຫຼັງ, ຕົວຢ່າງໂດຍຜ່ານ phishing. ໂດຍເນື້ອແທ້ແລ້ວ, ຜູ້ພັດທະນາເວັບທີ່ລືມກ່ຽວກັບ nuance ນີ້ກໍາລັງຕັ້ງຜູ້ໃຊ້ຂອງຕົນ. 

   ສິ່ງທີ່ນັກພັດທະນາເວັບຄວນຈື່: ໃນກໍລະນີນີ້, ພວກເຮົາມີຂໍ້ຂັດແຍ່ງແບບຄລາສສິກ: ຄວາມສະດວກສະບາຍທຽບກັບຄວາມປອດໄພ. ຖ້າຜູ້ພັດທະນາເວັບຄິດກ່ຽວກັບປະສົບການຂອງຜູ້ໃຊ້, ລາວສາມາດເລືອກການຕື່ມຂໍ້ມູນອັດຕະໂນມັດໄດ້. ຕົວຢ່າງ, ຖ້າມັນສໍາຄັນທີ່ຈະປະຕິບັດຕາມ ຄຳ ແນະ ນຳ ໃນການເຂົ້າເຖິງເນື້ອຫາຂອງເວັບ - ຄໍາແນະນໍາສໍາລັບການເຂົ້າເຖິງເນື້ອຫາສໍາລັບຜູ້ໃຊ້ທີ່ມີຄວາມພິການ. 

   ສໍາລັບຕົວທ່ອງເວັບສ່ວນໃຫຍ່, ທ່ານສາມາດປິດການຕື່ມຂໍ້ມູນອັດຕະໂນມັດດ້ວຍຄຸນລັກສະນະ autocompete="off", ຕົວຢ່າງ:

    <body>
       <form action="/lo/form/submit" method="get" autocomplete="off">
         <div>
           <input type="text" placeholder="First Name">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Credit card number">
         </div>
         <input type="submit">
       </form>
     </body>

   ແຕ່ມັນຈະບໍ່ເຮັດວຽກສໍາລັບ Chrome. ນີ້ແມ່ນຫລີກລ້ຽງໂດຍໃຊ້ JavaScript, ຄວາມແຕກຕ່າງຂອງສູດສາມາດພົບໄດ້ ທີ່ນີ້. 

5. ສ່ວນຫົວ X-Frame-Options ບໍ່ໄດ້ຕັ້ງຢູ່ໃນລະຫັດເວັບໄຊ. 

   ສ່ວນຫົວນີ້ມີຜົນກະທົບກັບກອບ, iframe, ຝັງ, ຫຼືແທັກວັດຖຸ. ດ້ວຍການຊ່ວຍເຫຼືອຂອງມັນ, ທ່ານສາມາດຫ້າມການຝັງເວັບໄຊທ໌ຂອງທ່ານພາຍໃນກອບໄດ້ຢ່າງສົມບູນ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງລະບຸຄ່າ X-Frame-Options: ປະຕິເສດ. ຫຼືທ່ານສາມາດລະບຸ X-Frame-Options: sameorigin, ຫຼັງຈາກນັ້ນການຝັງຢູ່ໃນ iframe ຈະມີຢູ່ໃນໂດເມນຂອງທ່ານເທົ່ານັ້ນ.

   ສິ່ງທີ່ເປັນອັນຕະລາຍ: ບໍ່ມີສ່ວນຫົວດັ່ງກ່າວສາມາດຖືກໃຊ້ຢູ່ໃນເວັບໄຊທີ່ເປັນອັນຕະລາຍເພື່ອ clickjacking. ສໍາລັບການໂຈມຕີນີ້, ຜູ້ໂຈມຕີສ້າງກອບໂປ່ງໃສຢູ່ເທິງຂອງປຸ່ມຕ່າງໆແລະຫຼອກລວງຜູ້ໃຊ້. ຕົວຢ່າງ: scammers ກອບຫນ້າເຄືອຂ່າຍສັງຄົມຢູ່ໃນເວັບໄຊທ໌. ຜູ້ໃຊ້ຄິດວ່າລາວກໍາລັງກົດປຸ່ມຢູ່ໃນເວັບໄຊທ໌ນີ້. ແທນທີ່ຈະ, ການຄລິກຖືກຂັດຂວາງແລະຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້ຖືກສົ່ງໄປຫາເຄືອຂ່າຍສັງຄົມທີ່ມີກອງປະຊຸມທີ່ມີການເຄື່ອນໄຫວ. ນີ້ແມ່ນວິທີທີ່ຜູ້ໂຈມຕີສົ່ງ spam ໃນນາມຂອງຜູ້ໃຊ້ຫຼືໄດ້ຮັບຜູ້ຕິດຕາມແລະມັກ. 

   ຖ້າທ່ານບໍ່ປິດຄຸນສົມບັດນີ້, ຜູ້ໂຈມຕີສາມາດວາງປຸ່ມຄໍາຮ້ອງສະຫມັກຂອງທ່ານຢູ່ໃນເວັບໄຊທ໌ທີ່ເປັນອັນຕະລາຍ. ລາວອາດຈະມີຄວາມສົນໃຈໃນໂຄງການສົ່ງຕໍ່ຫຼືຜູ້ໃຊ້ຂອງທ່ານ.  

   ສິ່ງທີ່ນັກພັດທະນາເວັບຄວນຈື່: ຊ່ອງໂຫວ່ສາມາດເກີດຂຶ້ນໄດ້ຖ້າ X-Frame-Options ທີ່ມີຄ່າທີ່ຂັດແຍ້ງກັນຖືກຕັ້ງຢູ່ໃນເວັບເຊີບເວີ ຫຼື load balancer. ໃນກໍລະນີນີ້, ເຄື່ອງແມ່ຂ່າຍແລະຜູ້ດຸ່ນດ່ຽງພຽງແຕ່ຈະຂຽນສ່ວນຫົວຄືນໃຫມ່, ເພາະວ່າພວກເຂົາມີບູລິມະສິດສູງກວ່າເມື່ອທຽບກັບລະຫັດ backend.  

   ມູນຄ່າການປະຕິເສດແລະຕົ້ນສະບັບຂອງສ່ວນຫົວ X-Frame-Options ຈະແຊກແຊງການເຮັດວຽກຂອງຕົວເບິ່ງເວັບ Yandex. ເພື່ອອະນຸຍາດໃຫ້ໃຊ້ iframes ສໍາລັບຕົວເບິ່ງເວັບ, ທ່ານຈໍາເປັນຕ້ອງຂຽນກົດລະບຽບແຍກຕ່າງຫາກໃນການຕັ້ງຄ່າ. ສໍາລັບຕົວຢ່າງ, ສໍາລັບ nginx ທ່ານສາມາດ configure ມັນເຊັ່ນນີ້:

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. PRSSI (Path-relative stylesheet import) ຊ່ອງໂຫວ່.  

   ນີ້ແມ່ນຈຸດອ່ອນໃນການຈັດຮູບແບບຂອງເວັບໄຊທ໌. ມັນເກີດຂື້ນຖ້າລິ້ງທີ່ກ່ຽວຂ້ອງເຊັ່ນ: href="/lo/somefolder/styles.css/" ຖືກໃຊ້ເພື່ອເຂົ້າເຖິງໄຟລ໌ສະໄຕລ໌. ຜູ້ໂຈມຕີຈະໃຊ້ປະໂຫຍດຈາກສິ່ງນີ້ຖ້າພວກເຂົາຊອກຫາວິທີທີ່ຈະໂອນຜູ້ໃຊ້ໄປຫາຫນ້າທີ່ເປັນອັນຕະລາຍ. ຫນ້າຈະໃສ່ການເຊື່ອມຕໍ່ພີ່ນ້ອງເຂົ້າໄປໃນ url ຂອງມັນແລະຈໍາລອງການເອີ້ນແບບ. ທ່ານຈະໄດ້ຮັບຄໍາຮ້ອງຂໍເຊັ່ນ badsite.ru/…/somefolder/styles.css/, ເຊິ່ງສາມາດດໍາເນີນການທີ່ເປັນອັນຕະລາຍພາຍໃຕ້ການປອມແປງຂອງຮູບແບບ. 

   ສິ່ງທີ່ເປັນອັນຕະລາຍ: ຜູ້ສໍ້ໂກງສາມາດຂູດຮີດຊ່ອງໂຫວ່ນີ້ຖ້າພວກເຂົາພົບຂຸມຄວາມປອດໄພອື່ນ. ດັ່ງນັ້ນ, ມັນເປັນໄປໄດ້ທີ່ຈະລັກຂໍ້ມູນຜູ້ໃຊ້ຈາກ cookies ຫຼື tokens.

   ສິ່ງທີ່ນັກພັດທະນາເວັບຄວນຈື່: ຕັ້ງສ່ວນຫົວ X-Content-Type-Options ເປັນ: nosniff. ໃນກໍລະນີນີ້, ຕົວທ່ອງເວັບຈະກວດສອບປະເພດຂອງເນື້ອຫາສໍາລັບຄໍເຕົ້າໄຂ່ທີ່. ຖ້າປະເພດອື່ນນອກ ເໜືອ ຈາກຂໍ້ຄວາມ / css, ຕົວທ່ອງເວັບຈະບລັອກການຮ້ອງຂໍ.

ຄວາມອ່ອນແອທີ່ສໍາຄັນ

1. ໜ້າທີ່ມີຊ່ອງໃສ່ລະຫັດຜ່ານຖືກສົ່ງມາຈາກເຊີບເວີຜ່ານຊ່ອງທີ່ບໍ່ປອດໄພ (ແບບຟອມ HTML ທີ່ມີຊ່ອງໃສ່ລະຫັດຜ່ານແມ່ນໃຫ້ບໍລິການຜ່ານ HTTP).

   ການຕອບສະໜອງຈາກເຊີບເວີຜ່ານຊ່ອງທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດແມ່ນມີຄວາມສ່ຽງຕໍ່ກັບການໂຈມຕີ “ຜູ້ຊາຍຢູ່ກາງ”. ຜູ້ໂຈມຕີສາມາດຂັດຂວາງການຈາລະຈອນແລະແຍກຕົວມັນເອງລະຫວ່າງລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍຍ້ອນວ່າຫນ້າເຄື່ອນຍ້າຍຈາກເຄື່ອງແມ່ຂ່າຍໄປຫາລູກຄ້າ. 

   ສິ່ງທີ່ເປັນອັນຕະລາຍ: ຜູ້ສໍ້ໂກງຈະສາມາດປ່ຽນຫນ້າແລະສົ່ງແບບຟອມສໍາລັບຂໍ້ມູນລັບຂອງຜູ້ໃຊ້, ເຊິ່ງຈະໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງຜູ້ໂຈມຕີ. 

   ສິ່ງທີ່ນັກພັດທະນາເວັບຄວນຈື່: ບາງເວັບໄຊສົ່ງລະຫັດໃຫ້ຜູ້ໃຊ້ຄັ້ງດຽວທາງອີເມວ/ໂທລະສັບແທນລະຫັດຜ່ານ. ໃນກໍລະນີນີ້, ຄວາມອ່ອນແອແມ່ນບໍ່ສໍາຄັນ, ແຕ່ກົນໄກຈະເຮັດໃຫ້ຊີວິດຂອງຜູ້ໃຊ້ສັບສົນ.

2. ການສົ່ງແບບຟອມທີ່ມີການເຂົ້າສູ່ລະບົບແລະລະຫັດຜ່ານຜ່ານຊ່ອງທາງທີ່ບໍ່ປອດໄພ (ແບບຟອມເຂົ້າສູ່ລະບົບບໍ່ໄດ້ສົ່ງຜ່ານ HTTPS).

   ໃນກໍລະນີນີ້, ແບບຟອມທີ່ມີການເຂົ້າສູ່ລະບົບແລະລະຫັດຜ່ານຖືກສົ່ງຈາກຜູ້ໃຊ້ໄປຫາເຄື່ອງແມ່ຂ່າຍໂດຍຜ່ານຊ່ອງທາງທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດ.

   ສິ່ງທີ່ເປັນອັນຕະລາຍ: ບໍ່ເຫມືອນກັບກໍລະນີທີ່ຜ່ານມາ, ນີ້ແມ່ນຈຸດອ່ອນທີ່ສໍາຄັນແລ້ວ. ມັນງ່າຍກວ່າທີ່ຈະຂັດຂວາງຂໍ້ມູນທີ່ລະອຽດອ່ອນເພາະວ່າທ່ານບໍ່ຈໍາເປັນຕ້ອງຂຽນລະຫັດເພື່ອເຮັດມັນ. 

3. ການນໍາໃຊ້ຫ້ອງສະຫມຸດ JavaScript ທີ່ມີຈຸດອ່ອນທີ່ຮູ້ຈັກ.

   ໃນລະຫວ່າງການສະແກນ, ຫ້ອງສະຫມຸດທີ່ໃຊ້ຫຼາຍທີ່ສຸດແມ່ນ jQuery ທີ່ມີຈໍານວນສະບັບທີ່ກວ້າງຂວາງ. ແຕ່ລະສະບັບມີຢ່າງຫນ້ອຍຫນຶ່ງ, ຫຼືແມ້ກະທັ້ງຫຼາຍ, ຊ່ອງໂຫວ່ທີ່ຮູ້ຈັກ. ຜົນກະທົບສາມາດແຕກຕ່າງກັນຫຼາຍຂຶ້ນຢູ່ກັບລັກສະນະຂອງຄວາມອ່ອນແອ.

   ສິ່ງທີ່ເປັນອັນຕະລາຍ: ມີການຂູດຮີດສໍາລັບຊ່ອງໂຫວ່ທີ່ຮູ້ຈັກ, ຕົວຢ່າງ:

   
   
   ສິ່ງທີ່ນັກພັດທະນາເວັບຄວນຈື່: ກັບຄືນສູ່ວົງຈອນປົກກະຕິ: ຄົ້ນຫາຊ່ອງຫວ່າງທີ່ຮູ້ຈັກ - ແກ້ໄຂ - ກວດສອບ. ຖ້າທ່ານໃຊ້ຫ້ອງສະຫມຸດເກົ່າໂດຍເຈດຕະນາ, ຕົວຢ່າງເພື່ອສະຫນັບສະຫນູນຕົວທ່ອງເວັບທີ່ເກົ່າແກ່ຫຼືເພື່ອປະຫຍັດເງິນ, ຊອກຫາໂອກາດທີ່ຈະແກ້ໄຂຈຸດອ່ອນທີ່ຮູ້ຈັກ. 

4. ການສະຄຣິບຂ້າມເວັບໄຊ (XSS). 
   Cross-Site Scripting (XSS), ຫຼື cross-site scripting, ແມ່ນການໂຈມຕີໃນແອັບພລິເຄຊັນເວັບທີ່ສົ່ງຜົນໃຫ້ malware ເຂົ້າໄປໃນຖານຂໍ້ມູນ. ຖ້າ Qualys ພົບເຫັນຊ່ອງໂຫວ່ດັ່ງກ່າວ, ມັນຫມາຍຄວາມວ່າຜູ້ໂຈມຕີທີ່ມີທ່າແຮງສາມາດຫຼືໄດ້ນໍາສະເຫນີ js script ຂອງຕົນເອງເຂົ້າໄປໃນລະຫັດເວັບໄຊທ໌ເພື່ອປະຕິບັດການເປັນອັນຕະລາຍ.

   ເກັບຮັກສາ XSS ອັນຕະລາຍກວ່າ, ເພາະວ່າສະຄຣິບຖືກຝັງຢູ່ໃນເຊີບເວີແລະຖືກປະຕິບັດທຸກຄັ້ງທີ່ຫນ້າເວັບທີ່ຖືກໂຈມຕີຖືກເປີດຢູ່ໃນຕົວທ່ອງເວັບ.

   XSS ສະທ້ອນ ປະຕິບັດໄດ້ງ່າຍຂຶ້ນນັບຕັ້ງແຕ່ script malicious ສາມາດຖືກໃສ່ເຂົ້າໄປໃນຄໍາຮ້ອງຂໍ HTTP. ແອັບພລິເຄຊັນຈະໄດ້ຮັບການຮ້ອງຂໍ HTTP, ຈະບໍ່ກວດສອບຂໍ້ມູນ, ຈະຫຸ້ມຫໍ່ມັນ, ແລະສົ່ງມັນທັນທີ. ຖ້າຜູ້ໂຈມຕີຂັດຂວາງການຈະລາຈອນແລະໃສ່ສະຄິບເຊັ່ນ

   <script>/*+что+то+плохое+*/</script> 

   ຫຼັງຈາກນັ້ນ, ການຮ້ອງຂໍທີ່ເປັນອັນຕະລາຍຈະຖືກສົ່ງໃນນາມຂອງລູກຄ້າ.

   ຕົວຢ່າງທີ່ໂດດເດັ່ນຂອງ XSS: js sniffers ທີ່ຈໍາລອງຫນ້າສໍາລັບການປ້ອນ CVC, ວັນຫມົດອາຍຸຂອງບັດ, ແລະອື່ນໆ. 

   ສິ່ງທີ່ນັກພັດທະນາເວັບຄວນຈື່: ໃນສ່ວນຫົວເນື້ອໃນ-ຄວາມປອດໄພ-ນະໂຍບາຍ, ໃຊ້ຄຸນສົມບັດ script-src ເພື່ອບັງຄັບໃຫ້ບຣາວເຊີລູກຄ້າພຽງແຕ່ດາວໂຫຼດ ແລະປະຕິບັດລະຫັດຈາກແຫຼ່ງທີ່ເຊື່ອຖືໄດ້ເທົ່ານັ້ນ. ຕົວຢ່າງ, script-src 'self' whitelists all scripts from our site only. 
   ການປະຕິບັດທີ່ດີທີ່ສຸດແມ່ນລະຫັດ Inline: ພຽງແຕ່ອະນຸຍາດໃຫ້ javascript inline ໂດຍໃຊ້ຄ່າ inline ທີ່ບໍ່ປອດໄພ. ຄ່ານີ້ອະນຸຍາດໃຫ້ໃຊ້ inline js/css, ແຕ່ບໍ່ໄດ້ຫ້າມການລວມໄຟລ໌ js. ໃນການປະສົມປະສານກັບ script-src 'ຕົວມັນເອງ' ພວກເຮົາປິດການໃຊ້ງານ scripts ພາຍນອກຈາກການຖືກປະຕິບັດ.

   ໃຫ້ແນ່ໃຈວ່າບັນທຶກທຸກຢ່າງໂດຍໃຊ້ report-uri ແລະເບິ່ງຄວາມພະຍາຍາມທີ່ຈະປະຕິບັດມັນເຂົ້າໄປໃນເວັບໄຊທ໌.

5. ການສັກຢາ SQL.
   ຊ່ອງໂຫວ່ຊີ້ໃຫ້ເຫັນເຖິງຄວາມເປັນໄປໄດ້ຂອງການໃສ່ລະຫັດ SQL ເຂົ້າໄປໃນເວັບໄຊທ໌ທີ່ເຂົ້າເຖິງຖານຂໍ້ມູນຂອງເວັບໄຊທ໌ໂດຍກົງ. ການສີດ SQL ແມ່ນເປັນໄປໄດ້ຖ້າຂໍ້ມູນຈາກຜູ້ໃຊ້ບໍ່ໄດ້ຖືກກວດສອບ: ມັນບໍ່ໄດ້ຖືກກວດສອບຄວາມຖືກຕ້ອງແລະຖືກນໍາໃຊ້ທັນທີໃນການສອບຖາມ. ຕົວຢ່າງ, ນີ້ຈະເກີດຂື້ນຖ້າແບບຟອມຢູ່ໃນເວັບໄຊທ໌ບໍ່ໄດ້ກວດເບິ່ງວ່າວັດສະດຸປ້ອນເຂົ້າກົງກັບປະເພດຂໍ້ມູນ. 

   ສິ່ງທີ່ເປັນອັນຕະລາຍ: ຖ້າຜູ້ໂຈມຕີໃສ່ຄໍາຖາມ SQL ເຂົ້າໄປໃນແບບຟອມນີ້, ລາວສາມາດທໍາລາຍຖານຂໍ້ມູນຫຼືເປີດເຜີຍຂໍ້ມູນລັບ. 

   ສິ່ງທີ່ນັກພັດທະນາເວັບຄວນຈື່: ຢ່າເຊື່ອສິ່ງທີ່ມາຈາກຕົວທ່ອງເວັບ. ທ່ານຈໍາເປັນຕ້ອງປົກປ້ອງຕົວເອງທັງດ້ານລູກຄ້າແລະຝ່າຍເຊີຟເວີ. 

   ໃນດ້ານລູກຄ້າ, ຂຽນການກວດສອບພາກສະຫນາມໂດຍໃຊ້ JavaScript. 

   ຟັງຊັນທີ່ສ້າງຂຶ້ນໃນກອບທີ່ນິຍົມຍັງຊ່ວຍເອົາຕົວລະຄອນທີ່ຫນ້າສົງໄສຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ. ມັນຍັງແນະນໍາໃຫ້ໃຊ້ການສອບຖາມຖານຂໍ້ມູນ parameterized ໃນເຄື່ອງແມ່ຂ່າຍ.

   ກໍານົດບ່ອນທີ່ແນ່ນອນການໂຕ້ຕອບກັບຖານຂໍ້ມູນເກີດຂຶ້ນໃນຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌. 

   ການໂຕ້ຕອບເກີດຂຶ້ນເມື່ອພວກເຮົາໄດ້ຮັບຂໍ້ມູນໃດໆ: ການຮ້ອງຂໍທີ່ມີ id (ການປ່ຽນແປງຂອງ id), ການສ້າງຜູ້ໃຊ້ໃຫມ່, ຄໍາຄິດຄໍາເຫັນໃຫມ່ຫຼືລາຍການໃຫມ່ໃນຖານຂໍ້ມູນ. ນີ້ແມ່ນບ່ອນທີ່ການສັກຢາ SQL ສາມາດເກີດຂື້ນ. ເຖິງແມ່ນວ່າພວກເຮົາລຶບບັນທຶກຈາກຖານຂໍ້ມູນ, ການສີດ SQL ແມ່ນເປັນໄປໄດ້.

ຄໍາແນະນໍາທົ່ວໄປ

ຢ່າປະດິດລໍ້ - ໃຊ້ກອບທີ່ພິສູດແລ້ວ. ຕາມກົດລະບຽບ, ກອບທີ່ນິຍົມແມ່ນປອດໄພກວ່າ. ສໍາລັບ .NET - ASP.NET MVC ແລະ ASP.NET Core, ສໍາລັບ Python - Django ຫຼື Flask, ສໍາລັບ Ruby - Ruby on Rails, ສໍາລັບ PHP - Symfony, Laravel, Yii, ສໍາລັບ JavaScript - Node.JS-Express.js, ສໍາລັບ Java - ພາກຮຽນ spring MVC.

ປະຕິບັດຕາມການອັບເດດຂອງຜູ້ຂາຍແລະປັບປຸງເປັນປົກກະຕິ. ພວກເຂົາຈະຊອກຫາຈຸດອ່ອນ, ຫຼັງຈາກນັ້ນຂຽນການຂູດຮີດ, ເຮັດໃຫ້ມັນເປີດເຜີຍຕໍ່ສາທາລະນະ, ແລະທຸກສິ່ງທຸກຢ່າງຈະເກີດຂຶ້ນອີກເທື່ອຫນຶ່ງ. ສະໝັກຮັບການອັບເດດເປັນເວີຊັນທີ່ໝັ້ນຄົງຈາກຜູ້ຂາຍຊອບແວ.

ກວດເບິ່ງສິດການເຂົ້າເຖິງ. ໃນດ້ານເຊີຟເວີ, ສະເຫມີປະຕິບັດລະຫັດຂອງທ່ານຄືກັບວ່າມັນ, ຈາກຕົວອັກສອນທໍາອິດເຖິງຕົວອັກສອນສຸດທ້າຍ, ຖືກຂຽນໂດຍສັດຕູທີ່ກຽດຊັງທີ່ສຸດຂອງເຈົ້າ, ຜູ້ທີ່ຕ້ອງການທໍາລາຍເວັບໄຊທ໌ຂອງທ່ານ, ລະເມີດຄວາມສົມບູນຂອງຂໍ້ມູນຂອງທ່ານ. ຍິ່ງໄປກວ່ານັ້ນ, ບາງຄັ້ງນີ້ແມ່ນຄວາມຈິງ.

ໃຊ້ clones, ສະຖານທີ່ທົດສອບ, ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ໃຫ້ເຂົາເຈົ້າສໍາລັບການຜະລິດ. ນີ້ຈະຊ່ວຍໃຫ້, ທໍາອິດ, ເພື່ອຫຼີກເວັ້ນຄວາມຜິດພາດແລະຄວາມຜິດພາດໃນສະພາບແວດລ້ອມການຜະລິດ: ສະພາບແວດລ້ອມການຜະລິດນໍາເງິນ, ສະພາບແວດລ້ອມການຜະລິດທີ່ງ່າຍດາຍແມ່ນສໍາຄັນ. ເມື່ອເພີ່ມ, ແກ້ໄຂຫຼືປິດບັນຫາໃດກໍ່ຕາມ, ມັນກໍ່ຄຸ້ມຄ່າໃນການເຮັດວຽກໃນສະພາບແວດລ້ອມການທົດສອບ, ຫຼັງຈາກນັ້ນກວດເບິ່ງຫນ້າທີ່ແລະຈຸດອ່ອນທີ່ພົບເຫັນ, ແລະຫຼັງຈາກນັ້ນວາງແຜນທີ່ຈະເຮັດວຽກກັບສະພາບແວດລ້ອມການຜະລິດ. 

ປົກປ້ອງຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ຂອງທ່ານດ້ວຍ Firewall Web Application ແລະປະສົມປະສານບົດລາຍງານຈາກເຄື່ອງສະແກນຄວາມອ່ອນແອກັບມັນ. ຕົວຢ່າງ, DataLine ໃຊ້ Qualys ແລະ FortiWeb ເປັນຊຸດການບໍລິການ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com