Міф #1: DAST не знаходить вразливостей
Найперші інструменти DAST (в початок 2000-х років) були створені як допомога для мануального тестування на статичних сторінках, а не як самостійні рішення, тому вони були розроблені з завищеними показниками, щоб дати досліднику приблизне уявлення про те, що саме потрібно дослідити.Такі інструменти теж потребували ручних налаштувань від експерта, щоб доопрацювати та уточнити.
Деякі з цих ранніх інструментів тестування «black-box» стали комерціалізованими та закріпили хибне уявлення про обмеження DAST, особливо в той час, коли вебсайти й додатки стали більш динамічними, а застарілі інструменти ледве функціонували.
Acunetix і Netsparker (тепер Invicti) були одними з перших спеціалізованих сканерів вебвразливостей, що працювали повністю автоматично і надавали надійні та придатні для використання результати, а Invicti, спираючись на цю спадщину, запропонував розширені можливості сканування, автоматизовану автентифікацію, перевірку на основі доказів, виявлення і тестування API (інтерфейсів прикладного програмування) тощо. Сучасні інструменти DAST можуть досліджувати всю поверхню вебатак, а потім перевіряти її на наявність вразливостей, які можна використати, а також виявляти застарілі та вразливі компоненти в додатках і технологічному стеку (stack). Важливо, що вони сканують і тестують сторінки, використовуючи повністю вбудований движок браузера, тому якщо користувач може відкрити сторінку, DAST може сканувати її – одночасно скануючи речі, до яких користувач зазвичай не має доступу, наприклад, API інтерфейси.
Міф #2: DAST дає лише можливі та хибнопозитивні результати
Розроблені для перевірки відносно простих статичних вебсторінок і позначення всього, що може потребувати ручного дослідження, ці ранні інструменти ніколи не призначалися для автоматизації без попереднього просіювання результатів експертом. Можна сказати, що застарілий DAST був навмисно створений для того, щоб давати здебільшого хибнопозитивні результати, але оскільки лише за кілька років вебдодатки стали складнішими та численнішими, отримання точних та автоматизованих результатів стало обов’язковим.
Ця передумова лягла в основу proof-based scanning – ідеї про те, що спосіб отримати безсумнівно точні звіти про вразливості полягає в тому, що сканер DAST фактично використовує вразливість в системі безпеки та повертає докази вразливої поведінки додатків. Цей підхід лежить в основі всіх методів та інструментів тестування Invicti, від DAST та IAST до SCA та безпеки API під час виконання, але для того, щоб зробити це безпечно, ефективно та повторювано, знадобилося понад десять років безперервних розробок та вдосконалень. Хоча це можливо лише для перевірок безпеки, які виконують тестове корисне навантаження і можуть викликати реакцію цільової програми, такі ж вимоги до точності застосовуються до всіх інших автоматизованих тестів, що виконуються інструментами Invicti, що робить звіти про вразливості безпосередньо придатними для використання в завданнях на виправлення – і в конвеєрі розробки.
Міф #3: DAST не можна використовувати в конвеєрі розробки
У водоспадному процесі розробки програмного забезпечення традиційно все тестування, від функціональності до тестування безпеки, проводилося на етапі контролю якості після завершення розробки. З появою DevOps більшість тестувань було значною мірою автоматизовано та інтегровано в конвеєр, але ранні сканери DAST не були створені для автоматизації чи швидкості. Ці інструменти все ще доводилося запускати вручну, а їх результати аналізували експерти з безпеки, часто повертаючись до розробників з незрозумілими питаннями та на пізній стадії, що вимагало дорогого і неприємного відстеження по всьому автоматизованому конвеєру.
Наразі організації можуть використовувати та використовують DAST у своїх DevOps-пайплайнах поряд з SAST та іншими інструментами тестування безпеки. Це правда, що для сканування DAST потрібен запущений додаток, але це не завжди має бути повна збірка або повне сканування. За допомогою таких інструментів, як Invicti, будь-який прототип, який можна запустити, вже можна перевірити, а якщо оновлюється лише одна сторінка у великому додатку, можна запустити інкрементне сканування лише оновленої частини. Зараз також поширені контейнерні розгортання, де вимога «runnable app» задовольняється ефективно та автоматично. Завдяки надійним результатам і продуктивності сканування, яка на порядок вище, ніж у застарілих інструментів, хороший DAST незамінний в будь-якому життєвому циклі розробки програмного забезпечення (SDLC) для побудови DevSecOps.
Міф #4: Маючи SAST фірма в безпеці
В основному на ринку кібербезпеки все ще домінують відомі постачальники мережевої безпеки та SAST, тому багато організацій вважають, що DAST – це не дуже важливо.
Насправді багато з цих постачальників недооцінили важливість безпеки вебдодатків ще на початку 2010-х років, коли світ почав переходити на вебпрограмне забезпечення та хмарні технології, тому зараз вони намагаються наздогнати DAST. Однією з помилкових думок, підкріпленою вимогами комплаєнсу, які конкретно вказують на аналіз вихідного коду, є те, що інструмент SAST – це все, що потрібно для створення та випуску безпечного програмного забезпечення.
Використання статичного аналізу при розробці, є найкращою практикою, але цього недостатньо для того, щоб забезпечити повне покриття тестування безпеки по всій поверхні вебатак. Це виникає через два різних розуміння «покриття». Тестування в процесі розробки – це покриття коду, тобто те, яка частина вихідного коду додатка була протестована, і це те, на що посилається SAST-покриття. Але справний вебдодаток має набагато більшу поверхню для атак, ніж просто сторонній код, протестований за допомогою SAST, тому DAST-покриття стосується тестування якомога більшої частини цієї поверхні, охоплюючи проблеми виконання, неправильні конфігурації, динамічних залежностей, фреймворків, API та багато іншого як у сторонньому, так і у власному коді. SAST перевіряє, чи безпечний вихідний код. DAST перевіряє, чи безпечний весь додаток. Отже, потрібні і DAST, і SAST, в ідеалі – на одній платформі.
Міф #5: Мережевий сканер також проводить пентестування, тому не потрібен DAST
Якщо ввести «онлайн сканер безпеки» в Інтернеті, пошук надасть безліч варіантів. Мережевий сканер і сканер вебвразливостей (DAST) – це різні інструменти для різних цілей.Якщо вебсервер налаштований правильно і безпечно, мережевий сканер зазначить, що сайтом можна користуватись. Разом з тим, це не каже нічого про те, чи вразлива сторінка клієнтського порталу до SQL-ін’єкцій або міжсайтового скриптингу (XSS), чи один з бізнес-додатків має SSRF-вразливість в кінцевій точці /api-v2/users/.
З іншого боку, тестування на проникнення виявляє ті ж типи проблем, що і DAST, але в іншому масштабі та часовому проміжку. Більшість пентестерів починають роботу з запуску якісного інструменту DAST, а потім проводять детальне дослідження в пошуках вразливостей, які можна використати та про які потрібно повідомити.
За допомогою хорошого інструменту DAST можна постійно проводити автоматизоване динамічне тестування безпеки в конвеєрі та у виробництві, а експертів залучати лише після того, як перевіряться всі результати DAST. Таким чином, отримується безперервне покриття тестування і кращу цінність від пентестування, оскільки експерти можуть працювати над складнішими вразливостями.
Якщо все зробити правильно, DAST може слугувати фундаментальною частиною всієї програми безпеки додатків, покриваючи реалістичну поверхню атаки, а також заповнюючи прогалини, залишені SAST і тестуванням на проникнення. І на відміну від SAST, який використовується лише в розробці, він може виконувати подвійну функцію в AppSec та InfoSec, слугуючи показником реального стану безпеки, особливо з такими функціями, як Predictive Risk Scoring від Invicti.
