Як выкарыстоўваць простую ўтыліту для пошуку ўразлівасцяў у праграмным кодзе

Graudit падтрымлівае мноства моў праграмавання і дазваляе інтэграваць тэсціраванне бяспекі кодавай базы непасрэдна ў працэс распрацоўкі.

Крыніца: Unsplash (Markus Spiske)

Тэставанне - важная частка жыццёвага цыклу распрацоўкі праграмнага забеспячэння. Існуе вельмі шмат відаў тэсціравання, кожны з іх вырашае сваю задачу. Сёння я хачу пагаварыць аб пошуку праблем бяспекі ў кодзе.

Відавочна, што ў сучасных рэаліях распрацоўкі праграмнага забеспячэння важна гарантаваць бяспеку працэсаў. У свой час быў нават уведзены спецыяльны тэрмін DevSecOps. Пад гэтым тэрмінам разумеюць шэраг працэдур, накіраваных на выяўленне і ўхіленне ўразлівасцяў у дадатку. Існуюць спецыялізаваныя open source рашэнні для праверкі ўразлівасцяў у адпаведнасці са стандартамі OWASP, якія апісваюць розныя тыпы і паводзіны ўразлівасцяў у зыходным кодзе.

Існуюць розныя падыходы да вырашэння праблем бяспекі, напрыклад, статычнае тэсціраванне бяспекі прыкладанняў (SAST), дынамічнае тэсціраванне бяспекі прыкладанняў (DAST), інтэрактыўнае тэсціраванне бяспекі прыкладанняў (IAST), аналіз кампанентаў праграмнага забеспячэння (Software Composition Analysis) і гэтак далей.

Статычнае тэсціраванне бяспекі прыкладанняў выяўляе памылкі ва ўжо напісаным кодзе. Гэты падыход не патрабуе запуску дадатку, таму ён называецца статычным аналізам.

Я спынюся на статычным аналізе кода і скарыстаюся простай open source інструментам, каб прадэманстраваць усё на практыцы.

Чаму я абраў open source інструмент для статычнага аналізу бяспекі кода

На тое ёсць шэраг прычын: па-першае, гэта бясплатна, бо вы выкарыстоўваеце інструмент, распрацаваны супольнасцю аднадумцаў, якія жадаюць дапамагчы іншым распрацоўнікам. Калі ў вас невялікая каманда або стартап, у вас ёсць выдатная магчымасць зэканоміць, выкарыстоўваючы праграмнае забеспячэнне з адчыненым зыходным кодам для праверкі бяспекі сваёй кодавай базы. Па-другое, гэта пазбаўляе вас ад неабходнасці наймаць асобную каманду DevSecOps, што яшчэ больш змяншае вашы выдаткі.

Добрыя open source прылады заўсёды ствараюць з улікам падвышаных патрабаванняў да гнуткасці. Таму іх можна выкарыстоўваць практычна ў любым асяроддзі, ахопліваючы шырокае кола задач. Распрацоўнікам нашмат прасцей пасябраваць такія прылады з сістэмай, якую яны ўжо пабудавалі, працуючы над сваімі праектамі.

Але могуць узнікнуць сітуацыі, калі вам спатрэбіцца функцыя, якой няма ў абранай вамі прыладзе. У гэтым выпадку ў вас ёсць магчымасць форкнуць яго код і распрацаваць на яго аснове свой уласны інструмент з неабходнай вам функцыянальнасцю.

Паколькі ў большасці выпадкаў на распрацоўку праграмнага забеспячэння з адчыненым зыходным кодам актыўна ўплывае супольнасць, рашэнне аб занясенні змен прымаюць досыць хутка і па справе: распрацоўнікі open source праекту абапіраюцца на водгукі і прапановы карыстачоў, на іх паведамленні аб знойдзеных памылках і іншых праблемах.

Выкарыстанне Graudit для аналізу бяспекі кода

Для статычнага аналізу кода можна выкарыстоўваць розныя прылады з адчыненым зыходным кодам, не існуе ўніверсальнай прылады для ўсіх моў праграмавання. Распрацоўнікі некаторых з іх прытрымліваюцца рэкамендацый OWASP і імкнуцца ахапіць як мага больш моў.

Тут мы будзем выкарыстоўваць Graudit, простую ўтыліту для каманднага радка, якая дазволіць нам знайсці ўразлівасці ў нашай кодавай базе. Ён падтрымлівае розныя мовы, але ўсё ж такі іх набор абмежаваны. Graudit распрацаваны на аснове службовай утыліты grep, якая ў свой час выйшла пад ліцэнзіяй GNU.

Існуюць падобныя прылады для статычнага аналізу кода – Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), flawfinder і гэтак далей. Але Graudit вельмі гнуткі і мае мінімальныя тэхнічныя патрабаванні. Тым не менш, у вас могуць з'явіцца задачы, якія Graudit вырашыць не ў стане. Тады можна пашукаць іншыя варыянты вось у гэтым спісе.

Мы можам інтэграваць гэты інструмент у канкрэтны праект, або зрабіць яго даступным для абранага карыстальніка, альбо выкарыстоўваць яго адначасова ва ўсіх нашых праектах. У гэтым таксама праяўляецца гнуткасць Graudit. Такім чынам, давайце спачатку клануем РЭПО:

$ 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/signatures:

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

Такім чынам, я пратэставаў два js-файлы з майго праекту, і Graudit вывеў у кансоль інфармацыю аб уразлівасцях у маім кодзе:

Можаце паспрабаваць такім жа чынам пратэставаць вашыя праекты. Спіс баз даных для розных моў праграмавання можна паглядзець тут.

Перавагі і недахопы Graudit

Graudit падтрымлівае шмат моваў праграмавання. Таму ён падыходзіць для шырокага кола карыстальнікаў. Ён можа годна канкурыраваць з любымі бясплатнымі або платнымі аналагамі. І вельмі важна, што ў праект па-ранейшаму ўносяць дапрацоўкі, а супольнасць не толькі дапамагае распрацоўшчыкам, але і іншым карыстальнікам, якія спрабуюць разабрацца з інструментам.

Гэта зручная прылада, але пакуль ён не заўсёды можа сапраўды паказаць, у чым менавіта складаецца праблема, злучаная з падазроным участкам кода. Распрацоўнікі працягваюць дапрацоўваць Graudit.

Але ў любым выпадку карысна зважаць на патэнцыйныя праблемы бяспекі ў кодзе, выкарыстаючы падобныя прылады.

Пачынаецца…

У гэтым артыкуле я разгледзеў толькі адзін са шматлікіх спосабаў пошуку ўразлівасцяў — статычнае тэставанне бяспекі прыкладанняў. Правесці статычны аналіз кода лёгка, але гэта толькі пачатак. Каб больш даведацца аб бяспецы вашай кодавай базы, трэба інтэграваць у жыццёвы цыкл распрацоўкі ПЗ іншыя віды тэсціравання.

На правах рэкламы

Надзейны VPS і правільны выбар тарыфнага плана дазволяць менш адцягвацца ад распрацоўкі на непрыемныя праблемы - усё будзе працаваць без збояў і з вельмі высокім uptime!

Крыніца: habr.com