Сьогодні ми зосередимося на інструменті Repeater та його функціях у версії Burp Suite Professional. Він дозволяє пентестеру надсилати запити всередині Burp та аналізувати відповіді в режимі реального часу, не перериваючи потік запитів, що надходять із браузера.

Зміст

• Вступ
• Перейменування вкладок
• Зміна методу запиту (Request Method)
• Історія запитів (Request History)
• URL як запит (URL as Request)
• URL-кодування (URL Encode)
• Керування перенаправленнями (Redirection)
• Пошук
• Відновлення закритих вкладок
• Режими перегляду (Views)
• Експорт даних Repeater
• Висновок

Вступ

Навіть початківці, які щойно відкрили Burp Suite, зазвичай знайомі з базовими функціями Repeater. Це інструмент, розроблений для того, щоб користувач або зловмисник міг змінювати та повторно надсилати окремі HTTP-запити для аналізу відповідей сервера.

Щоб почати роботу, перехопіть HTTP-запит у вкладці Proxy > Intercept. Натисніть правою кнопкою миші на запит і виберіть «Send to Repeater» (або натисніть Ctrl + R).

Тепер у вкладці Repeater ми можемо маніпулювати запитом. Після натискання кнопки Send запит буде надіслано цілі, а відповідь відобразиться у правій секції Response.

Перейменування вкладок

Під час аудиту Repeater швидко захаращується численними вкладками з номерами (1, 2, 3…). Це збиває з пантелику, коли проект стає масштабним.

Двічі клацніть на назву вкладки, щоб перейменувати її. Використовуйте назви, що відповідають типу тестування (наприклад, “SQLi Test”, “Admin Bypass” тощо), щоб легко орієнтуватися в сесії.

Метод запиту (Request Method)

Repeater дозволяє миттєво змінювати HTTP-методи (GET, POST, PUT, OPTIONS тощо). Наприклад, якщо сторінка з формою приймає дані через GET, але ви хочете протестувати їх передачу через POST — просто виберіть у контекстному меню «Change request method».

Burp автоматично змінить метод і перенесе параметри з URL у тіло запиту (body) згідно з нормами POST-запитів.

Історія запитів (Request History)

Repeater має кнопки «Назад» (<) та «Вперед» (>). Це надзвичайно корисно, якщо ви тестуєте різні параметри й хочете повернутися до попередньої ітерації запиту, яка працювала коректно. Ви можете переглянути всю історію змін у вкладці, натиснувши на стрілку поруч із кнопкою «Назад».

URL як запит (URL as Request)

У середовищі тестування на проникнення трапляються ситуації, коли необхідно перевірити відповідь конкретної URL-адреси без фактичного перехоплення самого запиту. Також можливий сценарій, коли ви виявили певну вразливість, але не маєте відповідного запиту в історії. У такому разі зазвичай доводиться переходити в HTTP History, шукати потрібний запит і надсилати його в Repeater. Цей процес можна скоротити, просто використавши URL-адресу. У нашому прикладі ми копіюємо URL безпосередньо з веббраузера.

Тепер ми переходимо в Repeater і створюємо нову вкладку, натиснувши правою кнопкою миші на відповідній панелі. З’явиться запит про тип нової вкладки: HTTP-запит чи WebSocket-запит. Оскільки ми працюємо з вебсторінкою, обираємо HTTP.

Тепер ми натискаємо правою кнопкою миші на порожню область розділу Request і вибираємо в контекстному меню опцію «Paste URL as request» (Вставити URL як запит).

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

URL-кодування (URL Encode)

Вебсервери не завжди коректно обробляють пробіли та певні символи. Тому пробіли та символи на кшталт & конвертуються у формат URL Encode. Зазвичай розробники програмують вебсайти так, щоб дані кодувалися на стороні клієнта перед генерацією запиту та відправкою на сервер. Якщо під час внесення змін у запит всередині Repeater ви забудете про належне кодування, запит може спрацювати непередбачувано.

Крім того, деякі фільтри безпеки налаштовані на пошук конкретних символів, таких як < >, але їхні еквіваленти у форматі URL Encode можуть не фільтруватися. Це дозволяє обійти захист шляхом простого кодування корисного навантаження (payload). У демонстрації нижче ми натискаємо правою кнопкою миші на запит у Repeater і обираємо опцію «URL-encode as you type». Це дозволить автоматично кодувати наш текст у формат URL Encode безпосередньо під час введення.

Ми бачимо, що до параметра searchFor було додано значення, при цьому пробіли автоматично замінилися на символ +, а весь рядок було конвертовано у формат URL Encode. Цю функцію можна вимкнути, повторно обравши ту саму опцію в меню.

Керування перенаправленнями (Following Redirection)

Перенаправлення (редирект) є важливою частиною будь-якого вебдодатка. Воно допомагає користувачеві навігувати сторінками так, як це задумав розробник, а також дозволяє інтегрувати кілька різних вебзастосунків в один сайт. Веббраузери за замовчуванням автоматично слідують перенаправленням, і це створює проблему для пентестера. Під час тестування таких сценаріїв, як Open Redirection (відкритий редирект) або Web Cache Poisoning (отруєння вебкешу), спеціалісту необхідно перехоплювати та аналізувати саме відповідь сервера з кодом перенаправлення.

Repeater має функцію, яка допомагає в таких ситуаціях. Вона дозволяє користувачеві вибрати один із варіантів:

• Never (Ніколи не слідувати редиректам);
• On-site only (Слідувати лише в межах поточного сайту);
• In-scope only (Слідувати лише для доменів, що входять в область тестування — Scope);
• Always (Завжди слідувати перенаправленням).

Це дає змогу гнучко налаштувати Repeater відповідно до особливостей архітектури конкретного додатка.

Оскільки на попередньому етапі ми обрали варіант «Never» (Ніколи не слідувати перенаправленням), на зображенні нижче ми бачимо відповідь сервера з кодом 302. Тепер, маючи відповідь із редиректом, ми можемо продовжити роботу із запитом, натиснувши кнопку «Follow redirection», як показано нижче.

Пошук (Search)

В обох секціях Repeater (запит і відповідь) знизу розташована панель пошуку. Оскільки відповідь сервера зазвичай містить весь HTML-код сторінки, вона може бути дуже об’ємною, що ускладнює пошук конкретних ключових слів. Це стає проблемою, коли необхідно перевірити, чи відобразилися передані нами параметри у відповіді сервера (reflected parameters).

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

• активувати чутливість до регістру (Case Sensitive);
• використовувати регулярні вирази (Regex) для пошуку за шаблоном.

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

Відновлення закритих вкладок (Reopening Closed Tab)

Якщо ви користуєтеся Burp уже певний час, ви напевно хоча б раз випадково закривали вкладку в Repeater, яка вам була потрібна. Ви не самотні, і це не ваша провина. Кнопка закриття (X) розташована так, що на неї дуже легко натиснути помилково. Після численних запитів користувачів компанія PortSwigger додала функцію для розв’язання цієї проблеми. Тепер ви можете натиснути правою кнопкою миші на область вкладок і вибрати опцію «Reopen Closed Tab», щоб відновити будь-яку вкладку, закриту помилково.

Режими перегляду (Views)

Для відображення розділів запиту (Request) та відповіді (Response) у Burp Suite передбачено кілька режимів перегляду. Вибір зазвичай залежить від особистих уподобань користувача. Перший із трьох доступних варіантів — це класичне розташування панелей Side-by-side (пліч-о-пліч), як показано на зображенні нижче.

Далі ми маємо режим Top-Bottom (Зверху-вниз). Ця орієнтація може бути корисною для тих користувачів, кому зручніше бачити запит і відповідь у вертикальному порядку.

Нарешті, існує режим Tabs (Вкладки), який додає ще один набір вкладок до загальної схеми інтерфейсу Burp. Цей режим надає користувачеві всю робочу область для конкретного розділу. Це може бути дуже зручним у певних сценаріях, коли потрібно зосередитися на великих обсягах даних. У цьому режимі створюються окремі вкладки для запиту та відповіді, і ви можете просто перемикатися між ними.

Експорт даних Repeater (Exporting Repeater Data)

Як відомо, документування є життєво важливою частиною будь-якого проекту з тестування. Коли ми надсилаємо численні запити в Repeater, ми часто вносимо зміни в кожен із них. Для того, щоб відстежувати ці зміни за межами Burp Suite, існує функція збереження історії всіх запитів. Після завершення роботи з декількома запитами просто натисніть правою кнопкою миші на будь-який запит і виберіть опцію «Save entire history» (Зберегти всю історію) у випадаючому меню.

Після цього відкриється вікно з запитом обрати місце для збереження файлу. Обравши директорію, ми називаємо файл відповідно до наших потреб і додаємо розширення XML. Також є можливість закодувати запити у форматі Base64, проте в нашому випадку ми цього не робитимемо.

Збережена історія буде зберігатися у вибраному місці у форматі XML. Як видно на зображенні нижче, файл містить такі деталі, як IP-адреса цілі, домен, порт, протокол, а також повний вміст як запиту, так і відповіді.

Висновок

Repeater — один із базових інструментів Burp Suite. Проте завдяки постійним дослідженням та розробкам він поповнився безліччю прихованих можливостей. Сьогодні цей інструмент досяг рівня, коли його функціонал здатен значно полегшити життя будь-якому пентестеру.