Як використовувати просту утиліту для пошуку вразливостей у програмному коді

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