ວິທີການໃຊ້ປະໂຫຍດງ່າຍໆເພື່ອຊອກຫາຊ່ອງໂຫວ່ໃນລະຫັດໂປຼແກຼມ

Graudit ສະຫນັບສະຫນູນພາສາການຂຽນໂປລແກລມຫຼາຍແລະຊ່ວຍໃຫ້ທ່ານສາມາດປະສົມປະສານການທົດສອບຄວາມປອດໄພຂອງ codebase ໂດຍກົງເຂົ້າໃນຂະບວນການພັດທະນາ.

ແຫຼ່ງຂໍ້ມູນ: Unsplash (Markus Spiske)

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

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

ມີວິທີການທີ່ແຕກຕ່າງກັນໃນການແກ້ໄຂບັນຫາຄວາມປອດໄພ, ເຊັ່ນ: ການທົດສອບຄວາມປອດໄພຂອງແອັບພລິເຄຊັນຄົງທີ່ (SAST), ການທົດສອບຄວາມປອດໄພຂອງແອັບພລິເຄຊັນແບບເຄື່ອນໄຫວ (DAST), ການທົດສອບຄວາມປອດໄພຂອງແອັບພລິເຄຊັນແບບໂຕ້ຕອບ (IAST), ການວິເຄາະອົງປະກອບຂອງຊອບແວ, ແລະອື່ນໆ.

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

ຂ້ອຍຈະສຸມໃສ່ການວິເຄາະລະຫັດສະຖິດແລະໃຊ້ເຄື່ອງມືແຫຼ່ງເປີດທີ່ງ່າຍດາຍເພື່ອສະແດງໃຫ້ເຫັນທຸກສິ່ງທຸກຢ່າງໃນການປະຕິບັດ.

ເປັນຫຍັງຂ້ອຍຈຶ່ງເລືອກເຄື່ອງມືແຫຼ່ງເປີດສໍາລັບການວິເຄາະຄວາມປອດໄພລະຫັດສະຖິດ

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

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

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

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

ການນໍາໃຊ້ Graudit ສໍາລັບການວິເຄາະຄວາມປອດໄພລະຫັດ

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

ໃນທີ່ນີ້ພວກເຮົາຈະໃຊ້ Gradit, ຜົນປະໂຫຍດເສັ້ນຄໍາສັ່ງທີ່ງ່າຍດາຍທີ່ຈະຊ່ວຍໃຫ້ພວກເຮົາຊອກຫາຈຸດອ່ອນໃນ codebase ຂອງພວກເຮົາ. ມັນສະຫນັບສະຫນູນພາສາທີ່ແຕກຕ່າງກັນ, ແຕ່ຊຸດຂອງພວກເຂົາຍັງມີຈໍາກັດ. Graudit ຖືກພັດທະນາໂດຍອີງໃສ່ຜົນປະໂຫຍດຂອງ grep, ເຊິ່ງໄດ້ຖືກປ່ອຍອອກມາເມື່ອພາຍໃຕ້ໃບອະນຸຍາດ GNU.

ມີເຄື່ອງມືທີ່ຄ້າຍຄືກັນສໍາລັບການວິເຄາະລະຫັດຄົງທີ່ - Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), flawfinder ແລະອື່ນໆ. ແຕ່ Graudit ແມ່ນມີຄວາມຍືດຫຍຸ່ນຫຼາຍແລະມີຄວາມຕ້ອງການດ້ານວິຊາການຫນ້ອຍ. ຢ່າງໃດກໍຕາມ, ທ່ານອາດຈະມີບັນຫາທີ່ Graudit ບໍ່ສາມາດແກ້ໄຂໄດ້. ຫຼັງຈາກນັ້ນ, ທ່ານສາມາດຊອກຫາທາງເລືອກອື່ນໄດ້ທີ່ນີ້ ໃນບັນຊີລາຍຊື່ນີ້.

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

$ git clone https://github.com/wireghoul/graudit

ຕອນນີ້ໃຫ້ສ້າງການເຊື່ອມຕໍ່ສັນຍາລັກສໍາລັບ Graudit ເພື່ອໃຊ້ມັນໃນຮູບແບບຄໍາສັ່ງ

$ cd ~/bin && mkdir graudit
$ ln --symbolic ~/graudit/graudit ~/bin/graudit

ມາເພີ່ມນາມແຝງໃສ່ .bashrc (ຫຼືໄຟລ໌ການຕັ້ງຄ່າໃດກໍ່ຕາມທີ່ທ່ານກໍາລັງໃຊ້):

#------ .bashrc ------
alias graudit="~/bin/graudit"

ປິດເປີດໃໝ່:

$ source ~/.bashrc # OR
$ exex $SHELL

ມາກວດເບິ່ງວ່າການຕິດຕັ້ງສຳເລັດຫຼືບໍ່:

$ graudit -h

ຖ້າທ່ານເຫັນບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນ, ຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງແມ່ນດີ.

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

$ graudit -d ~/gradit/signatures/js.db

ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ທົດສອບສອງໄຟລ໌ js ຈາກໂຄງການຂອງຂ້ອຍ, ແລະ Graudit ສະແດງຂໍ້ມູນກ່ຽວກັບຄວາມອ່ອນແອໃນລະຫັດຂອງຂ້ອຍກັບ console:

ທ່ານສາມາດລອງທົດສອບໂຄງການຂອງທ່ານໃນແບບດຽວກັນ. ທ່ານສາມາດເບິ່ງບັນຊີລາຍຊື່ຂອງຖານຂໍ້ມູນສໍາລັບພາສາການຂຽນໂປຼແກຼມທີ່ແຕກຕ່າງກັນ ທີ່ນີ້.

ຂໍ້ດີແລະຂໍ້ເສຍຂອງ Graudit

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

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

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

ເລີ່ມ...

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

ກ່ຽວກັບສິດທິຂອງການໂຄສະນາ

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

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