Як створити колекції запитів API для цілі, коли вони не існують в swagger

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

У цій статті я розповім про те, як ви можете створювати власні колекції для API, якщо їх не існує в свагере. Я продемонструю, як автоматизувати цей процес, і покажу вам, як озброїтися колекціями безпосередньо в Postman всього за кілька за декілька хвилин.

Чому потрібна документація API?

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

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

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

Про специфікацію Swagger ми поговоримо пізніше. Але спочатку я хочу пояснити, що таке недобросовісна документація API.

Що таке фальшивий документ API?

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

У деяких випадках його також можна використовувати для безпосередньої атаки на API. Ми дійдемо до цього. Наразі давайте поговоримо про деякі переваги фальшивих документів API.

Переваги фальшивої документації API

В ідеальному світі ми завжди мали б опис API, які нам пропонують атакувати. Розробники запропонували б повну документацію API, використовуючи специфікацію OpenAPI, і включили б опис змінних, об’єктів і кінцевих точок, необхідних для підтримки коду, який інтегрується з віддаленою службою. .

Але це реальний світ. Нам пощастило б, якби розробник знав, що таке документи OpenAPI. Хоча створення документації з коду вимагає мінімальних зусиль, нам потрібно взяти на себе контроль і виконати роботу зі створення документації API під час дослідження сервера.

Давайте будемо чесними. Підтримувати документацію в актуальному стані може бути важко. Оскільки API змінюються, розробник може легко забути відредагувати деталі про існуючу кінцеву точку; вони можуть забути написати нову документацію або відредагувати існуючу.

Так буває. Розробники теж люди.

Тож, створюючи власну фальшиву документацію API, ви завжди матимете найновішу документацію на основі того, що насправді РОБИТЬ API вашої цілі. Ви фіксуєте фактичну URL-адресу в запитах разом із усіма її даними, зазвичай у форматах XML або JSON. Таким чином, навіть якщо у вас є документи зі специфікаціями, ви можете зрозуміти, як ДІЙСНО працює API, і можете взяти до відома будь-які розбіжності.

Відстеження життєвого циклу API цілі

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

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

Отже, давайте розберемося, як можуть виглядати фальшиві документи API. Найкраще почати з обговорення Swagger і специфікації OpenAPI.

Swagger і специфікація OpenAPI

Специфікація OpenAPI , також відома як специфікація Swagger, — це формат документа, який дозволяє описати можливості API. Він надає спосіб визначення ресурсів, які надає API, включаючи методи (або кінцеві точки) і параметри, доступні для кожного. Крім того, його можна використовувати для створення інтерактивної документації та клієнтських бібліотек.

Специфікація OpenAPI є популярним вибором для опису сучасних API і підтримується рядом інструментів. Для наших цілей ми будемо використовувати інструмент із відкритим вихідним кодом Swagger Editor для відображення, пошуку та редагування нашої підробленої документації API після її створення.

Swagger проти OpenAPI

Останнім часом існує багато плутанини між Swagger та OpenAPI. Найпростіший спосіб зрозуміти відмінності:

• OpenAPI = Специфікація

• Swagger = Інструменти для впровадження специфікації OpenAPI

OpenAPI — офіційна назва специфікації. Її підтримують такі галузеві лідери, як Microsoft, Google і IBM.

Swagger — це назва найвідомішого набору інструментів, який використовується для створення документів OpenAPI. Зараз він належить Smartbear Software, яка також є членом ініціативи OpenAPI.

Зазвичай Swagger і OpenAPI використовуються як взаємозамінні. Але це невірно. Ви можете використовувати все, що завгодно, для створення документів Open API.

Фактично, я збираюся показати вам інструмент під назвою mitmproxy2swagger , який може зробити фальшиву документацію.

Як створити фальшиві документи API

Найкращий спосіб створювати фальшиві документи API – це розбирати живий трафік до сайту руцями, як звичайний користувач. Зазвичай це можна зробити за допомогою проксі. Чудові проксі-сервери для атак, такі як Burp Suite і ZAP, можуть зробити це досить добре. Як і mitmproxy, більш відомий як проксі-сервер man-in-the-middle.

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

Це чудовий спосіб, коли ви змушені збирати трафік в межах іноземної цілі, яка може не мати достатніх привілеїв для встановлення додаткових інструментів, таких як проксі.

А тепер дозвольте мені показати вам, все це покроково.

Налаштування та підготовка

Окрім використання інструментів розробника браузера, вам потрібно буде встановити mitmproxy2swagger . Ви можете завантажити його безпосередньо з GitHub, якщо хочете. Простіший спосіб — скористатися менеджером пакунків Python (він же pip ), щоб встановити його:

pip install mitmproxy2swagger

або

pip3 install mitmproxy2swagger

Коли ви його встановите, ми можемо почати захоплювати певний трафік!

Крок 1. Налаштуйте свій браузер для захоплення трафіку

Зайдійть в інструмент розробника в вашому браузері, а там на вкладку Network, щоб бачити зібраний трафік, який буде накаплюватись по мірі ваших дій на сайті.

Крок 2. Використовуйте програму для збору трафіку

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

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

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

Крок 3. Створіть HTTP-архів (HAR)

Після завершення виконання всіх дій додатку, поверніться до devtools. Тепер потрібно експортувати всі ці дані про трафік у архівний файл HTTP, або більш поширену назву HAR capture. Ви можете зробити це за допомогою інструменту експорту, який зазвичай виглядає як шестерня у інструментах розробників:

Буде створено файл із розширенням .har. Це в основному структуровані дані у форматі JSON про все, що записано інструментом розробника. І з цим ми можемо почати розважатися.

Крок 4. Імпортуйте файл HAR для створення Документації OpenAPI

Тепер настав час використати mitmproxy2swagger для перетворення HAR у приблизний файл визначення OpenAPI.

Це ще не справжній документ API, але він забере весь трафік і створить файл YAML, який ми зможемо редагувати. Ось приклад командного рядка, який можна використовувати:

mitmproxy2swagger -i crapi.har -o crapi.yaml -p http://crapi.apisec.ai -e -f har

• -i <ім'я файлу>.har : експортований файл з браузера HAR.

• -o <ім'я файлу>.yaml : переформатований файл YAML, який ви хочете створити. Цей файл нам потрібен щоб відредагувати деякі моменти.

• -p http://example.domain : це домен сайту звідки ви збираєтесь качати доку. Зазвичай це буде щось на зразок example.domain або example.domain/v1 тощо.

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

• -f har : це повідомляє інструменту, що вхідний файл є записом HAR, а не типовим файлом потоку mitmproxy.

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

Крок 5: відредагуйте файли YAML для опису кінцевих точок API

Відкрийте файл визначення YAML у вашому улюбленому редакторі та подивіться.

Зауважте, що під шаблонами x-path у вас є маса рядків, які починаються з слова «- ignore:/». Це так задумано.

Перегляньте файл і видаліть «ignore:» із будь-якого запиту, який виглядає як виклик API сайту. Вам не потрібні такі речі, як зображення, значки, HTML, Javascript тощо. Ви хочете лише описати фактичні кінцеві точки, ендпоінти API.

Коли закінчите, збережіть файл. Це може виглядати приблизно так:

Тепер ви готові фактично згенерувати документацію щодо API.

Крок 6: Створіть документацію OpenAPI з визначення

Тепер запустіть той самий командний рядок, щоб виконати другий проход до файлу визначення YAML, це потрібно, щоб прибралось все зі значенyям ignore:

mitmproxy2swagger -i crapi.har -o crapi.yaml -p http://crapi.apisec.ai -e -f har

Знову відкрийте файл YAML. Подивіться, як сильно воно змінилося.

Зверніть увагу на структуру. Він містить кінцеві точки, використані методи, параметри та властивості об’єктів і навіть містить повні приклади, якщо ви включили параметр -e.

Це ваша документація API, яка відповідає специфікації OpenAPI!

Але наскільки це відповідає специфікаціям? Давай дізнаємось.

Крок 7. Перевірте документ OpenAPI в Swagger Editor

Перейдіть на сторінку https://editor.swagger.io . В редакторі Swagger завантажте ваш документ API, це той файл який ви сформували двічі YAML, він пробує його проаналізувати. Залежно від того, наскільки ретельно було виконано ваші дії, ви можете або не можете побачити помилки.

Для іморту файлу YAML зайдіть File → Import File

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

Ви навіть можете натиснути кнопку «Спробувати» та виконати запит до сайту безпосередньо з документів API.

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

Як використовувати ваші фальшиві документи API у Postman

1)Налаштуйте нове робоче середовище в Postman

Запустіть Postman. Створіть і назвіть унікально ваш проєкт, що символізує ваш сайт. Workspaces → Create Workspace

2)Імпортувати файл визначення OpenAPI

У верхній лівій частині робочої області, поруч із назвою, яку ви назвали, є кнопка «Імпортувати» . Натисніть це. Коли буде виконано, скористайтеся провідником, щоб знайти файл YAML, який ви створили. Потім натисніть кнопку Імпорт .

Це може виглядати приблизно так перед імпортом:

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

Після виконання запиту в Postman, з налаштованими проксями як і в бурпі, ви будете бачити всі ці киконані запити і в Burp Suite, а далі що з цим робити залежить від вашої фантазії для перевірки. Додатків як веб так і мобайл.

Висновок

Доклавши трохи зусиль, тепер у вас має бути власна специфікована документація API, яка відповідає специфікації OpenAPI. Це дає змогу використовувати запити з Postman і Burp Suite разом для більш точної атаки на цільовий API, а також дає змогу тестувати кінцеві точки, які можуть бути або невідомі з наявної чи старої документації.

Пам’ятайте, що головне – вивчити кожну функцію програми, щоб записати весь трафік, необхідний для створення повної картини API. Сподіваюся було вам корисно. Удачі!