Як провести тестування на безпеку: керівництво для Manual QA

Ця стаття націлена на підростаюче покоління QA і розробників, яким цікаво дізнатися щось про уразливості: з чого почати, якими інструментами можна користуватися початківцю в цій справі (практичні поради). У матеріалі буде викладено те, що я хотів би прочитати на початку своєї кар'єри Security QA.

Вступ

Коли я був Manual QA, мені завжди здавалося, що шукати уразливості дуже важко, що цим можуть займатися тільки ті люди, які вміють програмувати. Тому я вибрав спочатку шлях автоматизатора, так як часто QA розвиваються саме в цьому напрямку. Але після більш ніж півтора роки на посаді автомейшена мені стало нудно... так-Так, стало нудно, так як мені нецікаво було весь час писати код і не спілкуватися з командою девелоперів, продактами та іншими членами команди, як я робив це, коли був мануальщиком.

Недовго думаючи, в якому напрямку мені розвиватися... Точніше, на це вплинуло кілька атак ловців вразливостей на наш проект. Після атак вони надали нам репорти, і мені стало прикро: ми ж могли передбачити ці кейси своїми силами, начебто ж було не дуже важко знайти їх. Так от, після ознайомлення з репортами, наданими цими ловцями, і доповідей з безпеки я вирішив рухатися в цьому напрямку.

Трохи про себе:в тестуванні я вже більше 7 років, займаюся пошуком вразливостей більше 4 років. Веду тренінги з тестування безпеки . Крім основної роботи проводжу аудити по QA. Веду блог .

Почнемо з того, з якими труднощами я стикався, коли почав вивчати тестування на безпеку. Напевно, з такими ж зіштовхнетеся і ви:

Проблема з тим, де без реєстрації і СМС знайти і безкоштовно почитати потрібну літературу. Щоб ось просто було написано зрозумілою мовою без незрозумілих фраз, як люблять описувати, щоб все було структуровано і були приклади, де можна було б попрактикуватися з прочитаним. При гуглении я отримував величезний вкидання інфи без розбору, що ж треба для початку.
Проблема з браком часу. Погодьтеся, важко знайти час на те, щоб змусити себе вчити щось нове без потреби терміново застосовувати ці навички :-)

А ось і рішення:

З першою проблемою мені допомогли... навіть не повірите хто — ті ж самі ловці вразливостей, які атакували нас і писали нам репорти про наших вразливості. Читаючи ці репорти, я паралельно гугл і шукав у статтях інформацію про причини виникнення і критичності даних вразливостей. У підсумку я склав для себе чек-лист масовості (наскільки поширений цей вид уразливості серед продуктів) і критичності (наскільки небезпечно мати таку уразливість в залежності від того, скільки бід, які можуть призвести до втрати довіри до бренду, можна зробити з неї на проекті).
Також рішенням першої і другої проблем стали мої виступи перед публікою на тему уразливостей. За час підготовки до того, щоб вчити когось чогось, ви вивчіть матеріал настільки добре і настільки швидко, що самі здивуєтеся :-) У вас відразу з'являється:
- дедлайн, до якого ви повинні встигнути підготуватися і добре вивчити тему;
- стимул вчити нове, так як перед вами стоїть завдання виступити перед публікою, а зганьбитися не сильно хочеться, щоб не показати, що ви чогось не знаєте в цій області, але щось там мовите;
- час. Скажете звідки? Та ви просто під психологічним впливом, що потрібно підготуватися до виступу, менше не реагуєте (менше часу приділяєте перегляду видосов з котиками та іншими приколясами). Та й після роботи замість просиджування штанців перед сериальчиком ви готуєтеся до свого дебюту на сцені. Нормальний такий лайфхак? :-)
І найголовніше: після того, як ви ознайомилися з будь-якою теорією про уразливості, негайно йдіть застосовувати її на практиці, так як теорія в голові без практики має здатність зникати, не подаючи виду, швидко і безслідно. І це буде реально даремно витрачений час. Попрактикуватися можна у себе на проекті з дозволу керівництва — а я думаю, вона в будь-якому дозволить вам, так як добре, коли є людина, яка може перевірити хоч на якусь безпеку. Або можна прогуглити Broken Web Application і по першій посиланням завантажити собі додаток, запустити його на VirtualBox і застосовувати там свої напрацьовані навички.

У цьому додатку багато різних лабораторій з найпоширенішими уразливими, так що вам повинно вистачити, щоб гарненько набратися досвіду пенетрації.

А тепер давайте поговоримо про найбільш поширених вразливості, які можуть зустрітися вам на шляху, і про те, як їх шукати...

XSS

Це один з типів уразливості web application, який дає скрипту можливість відпрацьовувати на сторінку, написану на JS. Така вразливість дає можливість зловмисникові впровадити свій сценарій в роботу вашого додатку. За статистикою , 40% компаній, які пройшли через сканери, мають цю вразливість. У рейтингу OWASP Top 10 вона на 7-му місці. Причина появи цієї проблеми — це довіра з боку розробника, що користувач не буде вносити різноманітні шматки коду на сайт.

Що ж може зробити в своїх цілях ловець вразливостей?

Змінити налаштування (наприклад, замінити бекграунд сайту, всунути, припустимо, на задній фон скрін Joycasino, розміщувати рекламу через спливаючі попап).
Стирити куки користувача.
Фішинг (хакер може вставити підроблену форму для входу на сторінку, яку ви відвідуєте, використовуючи DOM, встановивши в атрибути action цієї форми надсилання даних на свої власні серваки).
Кейлогер (хакер може впровадити щось типу відстеження дій, виконуваних користувачем на клавіатурі, використовуючи addEventListener., а потім відправити всі ці натискання клавіш на свій серверок, записавши конфіденційну інформацію користувача. Наприклад, це можуть бути паролі, номери кредитних карт. Стрьомно, погодьтеся.

Буває три типи XSS:

Непостійні (відбиті) XSS.
Постійні (збережені) XSS.
XSS DOM-моделі.

Розглянемо кожну з них.

Непостійні (відбиті) XSS

Цей клас XSS є найпоширенішим на сайтах. Давайте змоделюємо вектор атаки за допомогою цього класу. Розглянемо це на прикладі спеціально підготовленої лабораторії за вразливостей DVWA. У нас є форма з инпутом, при цьому инпут, як ми бачимо з вихідного коду цієї форми, не фільтрується ніяким фильтратором. Тобто змінна $_GET['name']приймає без перебору все, що в неї впишуть. Відповідно, вписаний в цей инпут скрипт <script>alert(1);</script> викличе попап на цій сторінці зі значенням в ньому цифри 1, після того як ми відправимо на сервер запит з цим скриптом. У результаті те, що ми відправили через цей инпут на сервер, передається GET-параметр в урлі, так як ця форма спілкується з сервером GET.

На наступній картинці ми можемо побачити результат:

Як ми бачимо, в урлі наш JS-код, що викликає той самий попап, в який ми можемо вписати будь-яку інформацію на сторінці, де є така вразливість. Які методи застосування такої вразливості, запитаєте ви? Наведу нижче...

Припустимо, SEO-менеджер вивчив новий спосіб поширення реклами — через попап цієї уразливості. Він знаходить сайт, де ця вразливість спрацьовує, в нашому випадку це bank.ua . Він дописує в аргумент пошуку після назви скрипт ')%3Balert('XSS')%3Bvar b=(', при цьому браузером буде екрануватися попап, що відображає те, що в нього напише наш менеджер, так як дані не піддаються обробці. Потім хлопчина просто поширює весь цей урл через різні соціальні мережі. Якщо користувач, який отримає цей скрипт, уважний, він просто може видалити доданий в урл скрипт, і попап не вистрибне при відкритті сторінки банку, але якщо не помітив, то він, крім відкриття сторінки сайту, отримає висновок попапу, в якому буде інформація, яку написав туди наш менеджер.

Збережені (постійні) XSS

Цей вид XSS вже вважається більш руйнівним типом атаки, ніж попередній. Він можливий, коли ловцю вразливостей вдається закинути на сервак JS скрипт, який буде виконуватися в браузері кожен раз при заході на запитувану вами сторінку. Найпростішим прикладом цієї проблеми є форуми, на яких дозволено залишати коментарі в HTML-форматі без обмежень. Іншими словами, зберігається XSS виникає, коли розробники здійснюють некоректну фільтрацію при збереженні вхідних даних в БД на сервері, а потім виводять ці ж дані в браузер користувача.

Приклад на тому ж ресурсі DVWA:

В цей раз ми впроваджуємо JS-скрипт (<script>prompt(111)</script> в полі Message, яке, як ми бачимо в коді, теж не фільтрується нормальним чином від користувальницького введення. Після відправлення цього скрипта на сервер він покластися в базу на сервер і кожен раз буде викликатися при відвідуванні цієї сторінки. Ах так... в цьому випадку буде не просто попап з виведенням тексту «111», а буде задіяний ще й инпут, в якій можна щось вписувати. А якщо гарненько подумати над реалізацією цього скрипта, то можна так подхачить його, що ніби вистрибує форма авторизації, в яку користувач введе свої дані, а вони будуть відправлені на сервер зловмисника. Як вам такий результат цієї вразливості?

І цей попап буде відтворюватися до тих пір, поки хтось не почистить значення в базі даних на сервері, куди відправили зберігатися цей скрипт, або не пофиксит саму екранізацію XSS на веб-сторінці.

DOM-моделі XSS

А ось цей вид XSS найнебезпечніший з усіх. XSS в DOM-моделі з'являються на стороні клієнта під час обробки даних усередині самого JavaScript. Цей тип XSS отримав таку назву, тому що нам потрібна Document Object Model, щоб зробити його. Як ви зрозуміли, DOM — це скорочення. Через нього можна отримувати доступ до вмісту HTML і XML-документів, навіть змінювати зміст або структуру документа, або його оформлення.

Що можна зробити за допомогою цієї уразливості:

Змінити сторінку сайту (можна додавати/замінювати картинки, додавати шматки нового функціоналу і так далі).
Можна красти сесії, куки користувача (вкравши ці дані, зловмисник може скористатися ними в своїх цілях: наприклад, можна авторизуватися під цими даними і бути ніби тим користувачем).
Кейлогер (заюзав скрипт на сторінці з уразливістю, зловмисник отримуватиме всі дані, які вводить користувач на клавіатурі, перебуваючи на зараженій сторінці).
Мало того що можна зробити те, що описано вище, так ще можна й залізти в операційну систему за допомогою вразливості ms10_002_aurora, яка доступна для старих браузерів Safari і Internet Explorer 7. Ви скажете: «Так це ж древні браузери, хто ними буде користуватися?» Але ні, давайте згадаємо банківські контори, які уклали десятирічні контракти на використання цієї версії браузера, — ось тут такі користувачі і попадуться на цю вразливість.

Наведу приклад, як можна поцупити куки користувача, а потім застосувати їх у себе в браузері і стати цим користувачем, використовуючи при цьому інструмент BeEF:

Injection

А тепер перейдемо до першої уразливості з рейтингу OWASP Top 10 — до Injection. За статистикою , нею заражене 28% компаній... Я розглядаю її пізніше, так як ця вразливість з кожним роком стає все менш поширеною, але залишається найбільш критичною з усіх, тому що з її допомогою можна відвести всю вашу базу даних. Ця вразливість ділиться на такі вектори для атаки:

ін'єкції через SQL-запити, LDAP, XPath;
ін'єкції через команди OS command;
ін'єкції через синтаксичний аналіз XML.

З допомогою цих векторів атакуючий може отримати доступ як до одного облікового запису, так і до всієї бази даних клієнтів цього ресурсу. Для застосування атаки використовуються лише спеціальні символи і додаткові оператори залежно від типу бази SQL.

Давайте розглянемо один з векторів Injection — з використанням запиту сторінки авторизації. Якщо у вас в додатку така є, перевірте її, щоб з нею не було таких проблем, які я вам покажу. При вході в систему через цю сторінку ми будемо шукати запис користувача в нашій базі даних SQL на основі введеного імені і пароля користувача. Якщо ми отримаємо якийсь результат, то він авторизує цієї людини. Все досить просто, насправді існують такі сторінки входу, які працюють таким же чином, маючи таку вразливість.

Отже, тут ми бачимо форму, при заповненні якої введені дані будуть відправлені в SQL-запит, і він витягне нам відповідь з бази даних. Якщо такий юзер є в базі даних, то нас авторизує. Якщо ні, то нам скаже: сорян, зарегайся. Те, що ми будемо вводити в полі User, передається в змінну $username, а те, що введуть в поле Pass, передається в змінну $password нашого SQL-запиту. А тепер розглянемо те, що буде відбуватися при введенні значень цих полів.

Давайте введемо такі дані:

в полі User — значення Svyat, яке, як ми бачимо (відмічено червоною стрілкою), стане на місце змінної $username;
у полі Pass — значення 1234, яке, як ми бачимо (зазначено синьою стрілкою), стане на місце змінної $password.

Після запуску SQL-запиту буде виконаний пошук у базі даних, де буде знайдений цей користувач з усією його інформацією, відповідно, ми отримаємо позитивну відповідь на сторінці авторизації і успішно авторізуємось.

Давайте тепер розглянемо, що може зробити зловмисник в нашому випадку...

Тут зловмисник робить хід конем і цілиться в юзера admin. Давайте розберемо детальніше, що він ввів:

в полі User — значення admin, яке, як ми бачимо, стане на місце змінної $username;
у полі Pass — значення ' OR 100=100 --, яке, як ми бачимо, стане на місце змінної $password.

А тепер давайте розберемо, що відбувається з змінної $password, коли в неї потрапляють дані такого роду, і як сервер обробляє їх.

Символом лапки 'з заданого значення' OR 100=100 — ми закриваємо дефолтну лапки даної змінної, залишивши пароль незаповненим. Це видно на зображенні вище.
Потім переходимо до речі OR з нашого значення ' OR 100=100 -- — воно говорить про те, що ми викликаємо оператор OR, який буде виконувати свою функцію в SQL-запиті, так як попередній лапкою ми закрили нашу змінну.
А вираз 100=100 з нашого значення ' OR 100=100 -- каже сервера: навіть якщо пароль не підійшов, однаково прийми за true, ніби він підійшов для тебе, так як 100=100 true.
І наостанок символи -- з нашого значення ' OR 100=100 -- закомментируют дефолтну лапки. Тобто весь код, який знаходиться після символів --, стає неробочим. У кожної бази даних виклик операції, щоб закоментувати код, відбувається по-різному: буває #, буває — буває */.

Виходячи з викладеного вище, SQL-запит отримав додаткове умова, яку диктує сервера нові правила гри, які змушують його авторизувати нас як користувача системи, незважаючи на те що ми не ввели правильний пароль. А оскільки це ще і користувач-адмін, ми маємо всі привілеї управління додатком. На запит додано значення OR 100=100, яке завжди буде оцінюватися як true (так як 100 завжди дорівнює 100, щоб отримати true, необов'язково писати саме 100=100, можна взяти будь-яке значення, яке дорівнює таким же значенням). Тепер цей користувач буде авторизований адміністратор, навіть якщо він не знає пароля. Це не прикольно, погодьтеся. Але якщо є така вразливість, то це може дійти і до такого випадку, як на картинці нижче...

Якщо в полі Pass ввести значення '; DROP TABLE users --, а потім відправити на сервер, то можна взагалі втратити даних користувача в нашій базі, але знову ж таки це якщо ми не фільтруємо в нашому додатку те, що вводить користувач.

Якщо підсумувати, ця вразливість націлена на застосування додаткових команд і операторів у запитах на сервер. І якщо в ній, як у XSS, немає фільтрації на цю справу, то така діра буде присутній у вас в додатку.

Інструменти

Цю та інші уразливості з OWASP Top 10 можна шукати за допомогою автоматизованого інструменту. З ним може впоратися і Manual QA, досить знати, які є найбільш критичні уразливості, і вміти користуватися інструментами для їх пошуку.

До інструментарію Penetration Tester можна віднести такі:

Безкоштовні:

OWASP ZAP;
Nmap;
Metasploit;
SQLmap;
Wireshark;
Ettercap;
BeEF.

Платні:

Burp Suite;
Acunetix;
Charles;
Veracode.

Так як по кожному з них можна розповідати багато чого, я приділив увагу лише одному. Це буде безкоштовний інструмент OWASP ZAP, щоб ви могли поюзати його і зрозуміти всю суть пошуку вразливостей.

Що таке OWASP ZAP

Почнемо з того, що OWASP ZAP — це в першу чергу інструмент, який досить простий у використанні для тестування на проникнення у вашу програму, а також для пошуку уразливостей у веб-додатках. Програма призначена як для користувачів, які мають досвід роботи у сфері інформаційної безпеки, таких як розробники і мануальні QA, так і для початківців.

Режими OWASP ZAP

У ZAP є кілька режимів роботи, при яких він буде проводити сканування:

1) Безпечний режим— в цьому режимі не можна зробити щось потенційно небезпечне для застосування.

2) Захищений режим— в цьому режимі користувач (бот) може виконувати тільки шкідливі дії для URL-адрес, зазначеним в області браузера.

3) Стандартний режим— в цьому режимі користувач (бот) може робити все, що має значення для застосування.

4) Режим Attack— при знаходженні нових вузлів в області дії шпигуна вони активно скануються, як тільки виявляються.

Оповіщення

Після того як ви запустите сканер, всі знайдені помилки OWASP ZAP будуть відсортовані за ступенем серйозності вразливостей і будуть перебувати на вкладці «Оповіщення». Червоним прапорцем будуть відзначені серйозні, такі як XSS, SQL Injection і так далі, помаранчевим — менш серйозні уразливості типу CSRF і інші незначні.

Щоб більш детально подивитися знайдені сканером уразливості, достатньо кілька разів клацнути по якійсь з них.

При цьому відкриється попап, в якому буде розписано:

що це за уразливість і на що вона впливає;
її критичність;
скрипт, з яким вона відтворюється;
література про те, як можна полагодити її.

Авторизація

Якщо у вашому проекті присутній авторизація, то ті посилання, які доступні для авторизованого користувача, не будуть доступні для OWASP ZAP без виконаного налаштування юзера (бота), під яким наш сканер зможе зайти для виконання пошуку вразливостей на тих сторінках, які доступні для авторизованого користувача. Для того щоб швидко налаштувати цього юзера, клікаєм по іконці вбудованого браузера. При цьому відкриється сам браузер, в якому введено налаштування проксі для обміну даними (запиту і відповіді). Тобто OWASP ZAP стає посередником, запити, які ви посилаєте в браузері на сервер, спочатку йдуть на OWASP ZAP, а з нього — на сервер.

Так само відбувається і в зворотному порядку: відповідь від сервера буде теж спочатку йти на OWASP ZAP, а вже з нього — в браузер. Таким чином, ви зможете моніторити весь трафік. Потім виконайте авторизацію на сайті, який збираєтеся тестувати, через цей браузер.

Всі дані, які ви ввели, будуть перехоплені нашим додатком OWASP ZAP. Це ми зможемо побачити в додатку ZAP, з лівого боку. Там з'явиться татко з назвою нашого хоста (сайту), який ми прогнали через браузер з проксі.

Коли ми расхлопнем цю папку, ми побачимо ієрархію нашої програми. Тут ми і побачимо наш запит POST, з яким авторизувались. І якщо ми будемо бачити, що, крім потрібного нам хоста, завантажилися ще й інші ресурси, які інтегровані в наш веб-додаток, типу різних соцмереж, щоб не витрачати час на сканування і їх — так як треба ж перевіряти наш проект, а не інші :) — нам треба поставити «контекст» тільки для однієї папки, яку ми хочемо перевірити. Для цього вибираємо потрібну папку і включаємо її в контекст.

Після того, як ми поставили папці контекст, ми повинні знайти в ній запит, який виконувався на авторизацію, а потім створити юзера для цього методу, вибравши пункт «Використовувати як контекст», а там — пункт Form-based.

Після вибору цього пункту відкриється попап з налаштуваннями локаторів для заповнення. Нам треба визначити, де локатор логіна і де локатор пароля, щоб ZAP міг розуміти, де яке поле введення, щоб він міг вписувати туди дані для аутентифікації. Тут нам треба вибрати з випадаючого списку, що буде застосовуватися в якості значення в шукачеві.

У цьому випадку нам треба вибрати в першому ДД username, у другому — password. Натискаємо OK. На POST-запит у вас з'явиться іконка двері.

Потім треба створити самого бота (юзера), задати йому креденшелы, які він буде вводити в ті инпуты, налаштовані нами раніше. Для цього заходимо в розділ Users і в цьому розділі додаємо нашого користувача, який зможе авторизуватись.

У відкритому попапі задаємо цього юзеру ім'я (яке — не має значення, це робиться для вашого розуміння, що це за юзер), пароль та логін (email), який підходить для авторизації в нашій системі.

Тепер нам треба показати OWASP ZAP якийсь локатор (XPath) на сторінці авторизованого юзера, щоб сканер розумів, що авторизація пройшла успішно. Для цього нам треба зайти на відповідь, отриманий від сервера, з HTML-розміткою, яку отримує авторизований юзер. Потім знаходимо якийсь локатор, до якого прив'яжемо наш сканер. Цей локатор OWASP буде шукати після виконання авторизації і розуміти, успішно він пройшов авторизацію на сайті.

Цей локатор вставляємо в розділ аутентифікації, в якому ми ставили параметри входу, — в инпут Regex pattern identified Logged in.

Як тільки ми виконали все, що написано вище, можемо починати атаку і перевірку того, на що здатне наше додаток. Для цього клікаєм по нашій папці, якій поставили контекст, і тиснемо на скан або атаку.

Після цього у випадаючому списку знаходимо нашого користувача, під яким зайде сканер.

І вуаля! Пішло сканування вашого проекту на всілякі уразливості.

Але пам'ятайте: жодна з програм не може гарантувати, що будуть знайдені всі уразливості. Знайдені вразливості можуть бути і false positive, те, що знайде сканер, по-любому треба перевіряти руками.

Підсумуємо

Тепер ви знаєте:

про двох вразливості;
за допомогою якого інструменту можна шукати уразливості;
де можна практикуватися у пошуку вразливостей.

Тепер ваше завдання полягає в тому, щоб, коли сканер знайде новий вид уразливості, ознайомитися з ним, дізнатися, як він відтворюється і яку серйозність несе в собі. Таким чином, зустрічаючи все нову і нову вразливість, виявлену сканером чи знайдену в якійсь статті, ви заробите досвід, з яким можете потім шукати ці ж дірки в інших ваших проектах, щоб зробити продукт безпечним. А також з боку менеджерів вас помітять і по-любому накинуть бабосов за те, що ви такий крутий спеціаліст.

І пам'ятайте: все показане вище зроблено в цілях навчання! Застосовувати на своїх проектах можна тільки з дозволу.

Читайте також:Зарплати українських тестувальників — червень 2019

Опубліковано: 06/08/19 @ 10:00
Розділ Безпека Блоги

SEO Блог