Guide to API Hacking
У цій статті ми обговоримо деякі основні поняття та ви отримаєте кілька порад щодо того, як почати тестувати API. Майте на увазі, що це лише посібник для початківців – про злом API можна дізнатися набагато більше, ніж те, що ми тут розглянемо. Я сподіваюся скерувати вас у правильному напрямку щодо того, як по-іншому поглянути на безпеку API за допомогою кількох методів атаки на API… як перевірити веб-API та як зловживати веб-додатками, які використовують API, щоб знайти ці помилки.
TOOLS FOR FIND VULNERABILITY
Guide to API Hacking
Що таке API?
API — це інтерфейс прикладного програмування. Іншими словами, це спосіб для різних програм спілкуватися один з одним.
API всюди – вони забезпечують взаємодію між нашими улюбленими програмами, веб-сайтами та пристроями.
Багато сучасних веб-додатків покладаються на API. Наприклад, коли ви замовляєте продукт на Prom чи Розетка, компанія використовує API для зв’язку з вашим банком для обробки платежу. Так само, коли ви перевіряєте погоду на своєму телефоні, він використовує API для отримання даних із служби погоди.
Коротше кажучи, API сьогодні – це те, що крутить сучасний світ!
А коли йдеться про безпеку API, є багато реальних прикладів, які демонструють це як найкраще місце для пошуку вразливостей. Для прикладу, як хакерська група Anonymous (за підтримки IT Army of Ukraine) зламала API найпопулярнішої російської таксі компанії Yandex, спричинивши величезну пробку посеред Москви.
Злом API – це тип тестування безпеки, спрямований на використання слабких місць в API. Націлившись на кінцеву точку API, ви, як зловмисник, потенційно можете отримати доступ до конфіденційних даних, перервати роботу служб або навіть захопити цілі системи.
Кажуть, що більше 80% усього веб-трафіку зараз керується запитами API.
Тестування безпеки веб-API може бути прибутковим, особливо якщо вам подобаються брати участь в bug bounty. Багато програм винагороди за помилки мають чітко визначений обсяг інтерфейсів програмування веб-додатків, якими ви можете скористатися для тестування API на проникнення.
Хороший дослідник безпеки може додатково запропонувати послуги тестування на проникнення щодо поширених уразливостей API, щоб допомогти своїм клієнтам перевірити веб-API. Незалежно від того, чи це внутрішній API, чи загальнодоступний, зламати програмування веб-додатків за допомогою brute force дозволяє виконувати типові атаки методичним і послідовним способом.
Перш ніж ми зможемо все це зробити, нам потрібно визначити деякі ключові основи роботи Інтернету, щоб почати зламувати API.
Основи HTTP
Щоб протестувати веб-API, вам потрібно зрозуміти, як вони спілкуються. Найпоширенішим способом взаємодії додатків є HTTP-запити.
HTTP — це протокол, який дозволяє веб-браузерам/клієнтам і серверам спілкуватися один з одним. Коли ви вводите URL-адресу у свій браузер, ваш комп’ютер надсилає HTTP-запит на сервер, на якому розміщено веб-сайт. Потім сервер відповідає HTML та іншими файлами, які потрібні для відображення веб-сайту.
API працюють приблизно так само. Однак зазвичай замість відповіді за допомогою HTML він надсилає дані вперед і назад у структурованому вигляді за допомогою JSON або XML. Наприклад, REST API та GraphQL API віддають перевагу використанню об’єктів JSON. З іншого боку, API SOAP вимагає від вас використання XML.
Фактично, це чудовий спосіб виявити інформацію API. Їх легше виявити, переглянувши заголовок запиту та перевіривши Content-Type. Якщо це application/json або application/xml, є хороший шанс, що ви натрапили на кінцеву точку API.
Оскільки ми говоримо про заголовки запитів, ми, ймовірно, повинні розглянути решту того, що становить запит.
Ключові частини запиту
HTTP-запит складається з трьох частин: URL-адреса запиту, метод запиту та тіло запиту (якщо воно є). Розглянемо кожну докладніше:
URL-адреса запиту:
Це адреса ресурсу, до якого ви хочете отримати доступ. Він складається з двох частин – імені хоста та шляху. Ім’я хосту – це просто доменне ім’я веб-сайту (наприклад, https://www.prom.ua ). Шлях — це розташування ресурсу на сервері (наприклад, /products/shoes).Метод запиту:
Метод запиту використовується для визначення способу доступу до ресурсу. Найпоширенішими типами методів запиту є GET, POST, PUT і DELETE.Тіло запиту (якщо воно є):
деякі методи запиту (наприклад, POST) вимагають тіла для передачі даних між клієнтом і сервером. Тіло зазвичай містить інформацію про те, який тип даних надсилається та як їх слід обробляти.
Іноді ви можете почути термін CRUD знання в вакансіях.
Більше CRUD
CRUD — це абревіатура від Create , Read , Update , Delete . Ці операції є основою для більшості веб-додатків сьогодні. І CRUD дуже тісно пов’язаний із методами запитів, про які ми щойно говорили.
Для виконання операцій CRUD ми використовуємо такі методи запиту:
Створити: POST
Читайте: GET
Оновлення: PUT/PATCH
Видалити: DELETE
REST і CRUD працюють разом, оскільки CRUD може існувати в середовищі REST, і їхні функції часто відповідають одна одній.
Але вони не однакові!
Найкращий спосіб розрізнити їх — пам’ятати, що REST — це стандарт (архітектура API), а CRUD — це функція . Розуміння цієї істотної, але простої різниці необхідно для розуміння обох.
Тепер, коли ви розумієте, як працюють HTTP-запити та як ідентифікувати API-запити, давайте поговоримо про те, як розпочати роботу зі створення оптимізованої лабораторії тестування API.
Створення власної лабораторії тестування API
Чудовий спосіб ознайомитись із хаком API – це націлити на навмисно вразливі API. Це дає практику виконувати типові атаки на ваші власні API в вашому проекті.
Є кілька різних способів зробити це:
Docker: це чудовий спосіб почати, оскільки він надає вам автономне середовище, у якому ви можете експериментувати, не боячись щось зламати.
Саморозміщені віртуальні машини: це другий метод. Якщо ви використовуєте Mac, ви можете використовувати Parallels Desktop для запуску віртуальної машини. Користувачі Linux та Windows можуть використовувати VirtualBox або VMWare всі працюють добре.
Хмарні віртуальні машини: Azure. AWS, Гугл клауд та інші. Є багато хмарних провайдерів, на яких можна розгортати вразливі програми. Просто не забудьте заблокувати екземпляр лише за своєю IP-адресою; Якщо цього не зробити, ваша віртуальна машина буде скомпрометована в найкоротші терміни.
Усі ці методи мають свої плюси та мінуси, але я віддаю перевагу Virtualbox, а ви дивіться від вашого сприйняття та ОС яка у вас.
Виберіть додаток з вразливостями API
Коли ви вирішите, як запустити свою хакерську лабораторію, вам потрібно буде вибрати навмисно вразливий API, який можна атакувати грубою силою. Щоб розпочати роботу, я б рекомендував вам скористатися одним із наступних двох варіантів:
OWASP crAPI : це «абсолютно безглуздий API», який висвітлює десять найбільш критичних ризиків безпеки API. Його можна встановити за допомогою Docker або для віртуал бокс
OWASP Juice Shop : це, мабуть, найсучасніша та найскладніша незахищена веб-програма. Його також можна встановити за допомогою Docker або для віртуал бокс
Обидві ці програми чудово підходять для початку. Вони обидва прості в установці та мають широкий спектр уразливостей, якими можна скористатися.
Отже, тепер, коли у нас є місце для гри та практики, давайте створимо просту та зрозумілу методологію атаки на API.
Хакерські інструменти
API клієнт
Для клієнта API я рекомендую Postman . Її набагато зручніше використовувати, ніж веб-клієнт. Це, безперечно, найнадійніший інструмент для створення, спільного використання, тестування та документування API.
веб-проксі
Для веб-проксі вам потрібен Burp Suite . Незважаючи на те, що багато людей рекомендуватимуть вам розпочати роботу з безкоштовної версії Community Edition, але в майбутньому, краще вам придбати Burp Suite Professional якнайшвидше, особливо якщо ви плануєте пропонувати послуги тестування на проникнення.
Burp — це найповніший набір інструментів для тестування проникнення в Інтернет. Якщо ви справді серйозно ставитеся до своєї майстерності злому API, вам потрібна продуктивність і можливості професійної версії. Я не є проповідником розробників PortSwigger, але інструмент реально крут і включає в себе дуже великий спект можливостей для тестування на вразливості, не тільки АПІ, а й інші технології.
Чому вам потрібна Pro версія Burp Suite
У професійній версії вона відкриває масу можливостей, які ви просто не маєте в безкоштовній версії Community, а саме:
Ви отримуєте можливість зберігати проекти, тож можете зберегти свою роботу та повернутися до неї пізніше.
Ви можете організовувати спеціальні атаки, використовуючи всі можливості інструментарію Intruder . Ви не можете виконувати практичні атаки грубою силою, використовуючи версію Community, оскільки вона має низьку швидкість/продуктивність. У професійній версії це обмеження знято.
Ви отримуєте вбудований сканер веб-вразливостей, ВКЛЮЧАЮЧИ сканер API.
Ви отримуєте доступ до ексклюзивних розширень BApp, які надають Burp більше функцій. Деякі з цих розширень значно прискорюють виявлення та використання вразливостей і пропонують методи обходу захисту.
Ви маєте повні можливості пошуку та виявлення вмісту
Ви отримуєте тестування безпеки додатків (OAST) через Burp Collaborator . Дуже корисно під час сліпого ін’єкційного тестування.
Ви маєте доступ до планування та автоматизації завдань
і ще багато іншого, але то буде довго перераховувати
Burp + Postman = ЦЕ ПРОСТО ПЕРЕМОГА
Отже, ви завантажили та встановили два інструменти, які вам потрібні для зламу API. От вам приклад як вони можуть працювати разом:
Можна налаштувати Postman на використання Burp як свого проксі. Іншими словами, ви можете налаштувати його так, що коли ви запускаєте запит API за допомогою Postman, його можна контролювати та маніпулювати ним у Burp. Це стає надзвичайно корисним, коли ви не хочете втручатися в попередньо визначені колекції Postman і хочете використовувати такі речі, як інструмент Repeater від Burp , щоб змінити запит і подивитися, як він реагує.
Кроки для налаштування Postman на проксі через Burp
Відкрийте Postman
Натисніть коліщатко COG у верхньому правому куті екрана та виберіть Налаштування . Вимкніть « Перевірку сертифіката SSL ». Це дозволить Postman працювати з самопідписаним сертифікатом від Burp, який використовується в проксі.
У проксі вимкніть « Системний проксі » та ввімкніть « Додати спеціальну конфігурацію проксі ». Переконайтеся, що позначено як HTTP, так і HTTPS, і що ви встановили проксі-сервер на localhost:8080 або 127.0.0.1:8080, який вказан на проксі Burp.
Тепер запустіть Burp
Повернувшись у Postman, перейдіть до вже наявної колекції API (або створіть новий запит) і надішліть його. Ви повинні побачити запит в історії HTTP в Burp.
Клацніть правою кнопкою миші на елементі логів в історії Burp і виберіть «Send to Repeater» .
Перейдіть на вкладку Repeater у Burp і натисніть кнопку Send . Зауважте, що тепер у вас є повний контроль і можливість зламати запит.
Гаразд, після того, як Postman і Burp налаштовано, ми можемо почати перевіряти безпеку веб-API у вашій лабораторії тестування API.
Давайте почнемо з вивчення того, як знайти API за допомогою розвідки (recon).
API Recon
Коли справа доходить до API, слід розглянути три основні типи – публічний, партнерський і приватний.
Публічний API – це ті, які кожен може використовувати. Наприклад, Twitter API або Google Maps API. Зазвичай ці API добре задокументовані, оскільки до них може отримати доступ практично кожен.
Партнерські API – це ті, до яких ви повинні мати певні стосунки з постачальником, щоб отримати доступ, але це не те, що повністю приховано від громадськості. Хорошим прикладом цього є Stripe API. У багатьох випадках існує хороша документація API, але вона доступна лише якщо ви є партнером.
Приватні API - це як і слід було очікувати, повністю приховані від очей громадськості, і до них можуть отримати доступ лише ті, хто має на це явний дозвіл. Зазвичай вони знаходяться в організації, яка створила власний API для внутрішнього використання, наприклад для якогось мобільного додатку. Ви рідко коли знайдете документацію для цих API. Це змушує вас перепроектувати API, щоб коли-небудь зрозуміти, як він працює.
Як виявити API
Незалежно від того, чи хочете ви зламати загальнодоступний, партнерський чи приватний API, є загальні методи, які можна використати, щоб визначити кінцеву точку API.
Першим спосіб - це відстежити, як програма взаємодіє з API, ви можете виявити URL-шляхи, щоб, виявити, де можуть існувати веб-API. Простий спосіб контролювати це – відкрити DevTools у своєму браузері та просто спостерігати за запитами на вкладці Network під час використання програми. Іншим варіантом було б використовувати веб-проксі та записувати всі запити.
Знайдіть документацію API
Другий спосіб — спробувати знайти документацію API. Це можна зробити кількома способами:
Ви можете шукати документацію щодо API безпосередньо від постачальника/видавця веб-API на їхньому веб-сайті або в загальнодоступних сховищах вихідного коду, як-от GitHub.
Ви можете шукати опубліковану документацію API в самому API. Це зазвичай називають документацією «swagger» або «OpenAPI».
Ви можете шукати документацію API у сторонніх каталогах API.
Існує чудовий список слів, розроблений спеціально для пошуку документації API під назвою swagger.txt , який є частиною репозиторію SecLists Деніела Місслера. Ви можете використовувати Burp Intruder для автоматичного тестування кожного відомого шляху за допомогою фаззингу, щоб виявити, чи існує документація API на цілі.
Звичайно, іноді так само легко шукати шляхи за замовчуванням. Третій метод виявлення API полягає в пошуку загальних шляхів, наприклад:
Під час фаззингу шляхів слід також фаззити субдомени. Нерідко можна побачити, що API існують у субдомені, наприклад api.exapmle.com. Я б порекомендував вам взяти звичайний список слів для субдоменів, як-от subdomains-top1million-5000.txt, і адаптувати його для пошуку API у вашій цільовій мережі.
Перевірте сторонні каталоги API
Як четвертий метод, ви можете перевірити загальнодоступні сторонні каталоги API, де можна знайти інформацію про API. Ви можете використовувати кілька каталогів API, зокрема:
Коли ви визначите, де може розташовуватися ваш API і як він може працювати, настав час піти глибше та дізнатися більше про поверхню атаки API. Перший крок — провести пасивну розвідку за допомогою розвідки OSINT.
Пасивна розвідка
На цьому кроці ви захочете дізнатися якомога більше про свою ціль, не взаємодіючи з нею. Це називається пасивною розвідкою, і вона може бути дуже корисною на ранніх етапах тестування на проникнення.
Саме під час цієї фази ви можете виявити не лише кінцеві точки та документацію, але й артефакти інтерфейсу додатків, як-от версії, ключі, облікові дані та маркери. Уся корисна інформація, яка допоможе вам вирішити, як наблизитися до своєї цілі.
Давайте розглянемо деякі з найпоширеніших методів пасивної розвідки, які можна використовувати, щоб дізнатися більше про свою ціль:
1) Google Dorking
Я думаю, само собою зрозуміло, що Google дуже добре справляється зі своєю роботою, аналізуючи практично все. Використовуйте це на свою користь. Навіть щось таке просте, як «<prom> api», може відобразити вам результати та скерувати вас до документації API.
Але не зупиняйтеся на досягнутому.
Ви можете поєднати синтаксис пошуку, як-от inurl , із site , щоб знайти артефакти API. Наприклад, пошук "inurl:/api/admin site:slack.com" не лише показує спеціалізований API-сайт Slack за адресою api.slack.com , але ви можете виявити, що там є кінцева точка, https://slack.com/api/admin.users.list, яка містить список усіх користувачів у slackspace. Дуже корисний.
Ось кілька інших дорків Google, які ви можете спробувати:
intitle:"index of" intext:"api" - Знайти артефакти API, які виявляються на веб-сервері, наприклад ключі та конфігурацію
inurl:"/api/*" intext:"index of" - Знайдіть цікаві каталоги API
intext:api filetype:env - Знайдіть можливі змінні середовища, пов’язані з API, зокрема ключі та маркери
intitle:"index of" api_key OR "api key" OR apiKey -pool - Знайти потенційні ключі API
intext:APIKey ext:js | xml | yaml | txt | conf | py intitle:"index of" - Знайти ключі API в цікавих файлах.
intitle:"index of" "api.yaml" - Знайдіть потенційні конфігурації API
"api" ext:log - Знайдіть файли журналів, які можуть містити інформацію про артефакти API
Та НЕ забудьте також включити параметр site: , щоб охопити пошук до вашої цілі, яку ви тестуєте.
2) Shodan
Shodan — це пошукова система, яка дозволяє знаходити певні пристрої та інформацію в Інтернеті. Його можна використовувати для пошуку вразливих систем, таких як сервери з відомими вразливими місцями, або для визначення конкретних пристроїв у мережі. Shodan також містить функцію під назвою «Сканування», яка дозволяє користувачам шукати пристрої, які відповідають певним критеріям, таким як номер порту або операційна система.
Звичайно, ви також можете використовувати його для пошуку інформації про API.
Пам’ятаєте раніше в статі було написано, що хорошим показником того, що ви знайшли API, є його Content-Type? За допомогою Shodan ви можете додати фільтр до свого запиту, щоб шукати це. А також такі речі, як номер порту та коди відповіді. Ось кілька шоданських дорків, які ви можете спробувати:
port:80,443 http.status:200 "Content-Type: application/json" - Знайти веб-сервери, які повертають потенційні кінцеві точки REST
"Content-Type: application/xml" - Знайти веб-сервери, які повертають потенційні кінцеві точки, які використовують XML (тобто: SOAP)
"X-*API*" hostname:"*.target.domain" - Знайдіть сервери, які містять спеціальні заголовки, пов’язані з «API». наприклад: X-API-KEY, X-API-VERSION, X-API-ENV, X-AMZ-API-PATH тощо
ssl.cert.subject.cn:target.domain - Знайти сервери, яким видано сертифікат SSL для *.target.domain
ssl:"Company Name" - Знайдіть сервери, яким видано сертифікат SSL, що стосується цільової компанії. Корисно для сертифікатів, згенерованих постачальниками SaaS/хмари, які пропонують послуги цільовим клієнтам (наприклад, AWS, Azure, Google тощо).
Тут можна проявити креативність. Якщо обсяг вашої роботи включає великі блоки IP-адрес, ви можете провести робочий день, знаходячи незадокументовані кінцеві точки в усій інфраструктурі за допомогою Shodan Dorks.
Активна розвідка
Коли справа доходить до активної розвідки, існує маса цікавих інструментів. Ви можете робити майже все з Postman і Burp.
Однак перед тим, як це зробити, я скажу, що наявність і інших інструментів у вашому наборі інструментів для активної розвідки є корисною. Ось лише деякі з них, якими можете користуватись, які з часом, напевно, стануть вам у нагоді:
nmap для розвідки портів на своїх цілях. Що ще важливіше, я використовую сценарії NSE nmap, такі як http-enum, http-methods, http-headers тощо, щоб детальніше розглянути обʼєкт.
feroxbuster для перерахування каталогів, особливо для пошуку активних кінцевих точок і документації. Це неймовірно швидкий інструмент виявлення вмісту, який підтримує рекурсію.
kiterunner аналог feroxbuster, оскільки він знаходити більше артефактів API, ніж брутфорсинг необроблених каталогів. Він знаходить більше ресурсів, коли витягує фактичні маршрути та може виявити методи, заголовки, параметри та значення, які може мати API.
Закінчивши це, скористаємося інструментом Burp Intruder, щоб знайти API за допомогою методів фаззингу.
1) Відкриття API за допомогою Burp
Фаззинг каталогів — це процес підбору каталогів і файлів на веб-сервері для пошуку потенційних API. Це можна зробити за допомогою feroxbuster, kiterunner або інших подібних інструментів. Однак ми також можемо зробити це за допомогою Burp Suite.
Давайте попрактикуємось з burp. Для нашого прикладу, скажімо, наша ціль — https://juice-shop.herokuapp.com/ , і ми хочемо знайти будь-які кінцеві точки API, які можуть існувати на сервері. Ми б налаштували нашу атаку так:
Відкрийте Burp і запустіть вбудований браузер
Відвідайте https://juice-shop.herokuapp.com/, щоб створити перший запит і заповнити історію HTTP.
Клацніть правою кнопкою миші на елементі журналу в історії та виберіть Send to Intruder . Крім того, ви можете скористатися комбінацією клавіш CTRL+I.
Тепер відкрийте вкладку Intruder. Ви маєте бути на вкладці Position вашого останнього запиту.
Для «Типу атаки» залиште значення «Sniper» .
У розділі «Payload position» додайте слово FUZZ після « GET /». Потім виділіть слово та натисніть кнопку «Додати» , щоб установити зміну. Це має виглядати приблизно так ( GET / §FUZZ§ HTTP/1.1):
Тепер виберіть вкладку Payload .
У розділі «Payload settings» натисніть кнопку «Load» .
Виберіть список слів, який ви б хотіли використати. Як відправну точку, common-api-endpoints-mazen160.txt від SecLists є хорошим вибором.
Після завантаження списку слів натисніть кнопку start attack , щоб почати.
Після завершення атаки відсортуйте за стовпцем Status і/або Length. Якщо щось було знайдено, типу 200 відповідей, а не 404, типу сторінка не знайдена, то ви отримали сторінку з якоюсь інформацією, а з випадком довжини, існуючої сторінки, то вона має відрізнятися від довжини не існуючої сторінки.
Ось такі інструменти, як feroxbuster і kiterunner, кращі. У цей момент він може рекурсивно продовжувати пошук по маршрутах. наприклад: /api/v1і т.д. А за допомогою Burp тепер вам потрібно буде оновити корисне навантаження, щоб врахувати щойно знайдений підкаталог, і сканувати знову.
2) Відкривайте маршрути
Коли ви знайдете шлях до місця, де, на вашу думку, може існувати API, ви захочете насправді спробувати виявити маршрути через об’єкти та дії . У SecLists є кілька хороших списків слів, які можна використовувати як основу під назвами objects.txt і actions.txt відповідно, які можуть працювати з вашими методами фаззингу.
Для цього, ви можете використовувати потужну функцію атаки в Burp Intruder під назвою Cluster bomb:
Надішліть успішний запит, який ви зробили в історії HTTP, до Intruder з вашого щойно знайденого каталогу API. тобто: https://juice-shop.herokuapp.com/api
Оновіть корисне навантаження, щоб налаштувати мало дві зміні позиції. тобто: https://juice-shop.herokuapp.com/api §FUZZ1§ / §FUZZ2§
На вкладці «Position» встановіть тип атаки «Cluster bomb» .
На вкладці «Payload» виберіть 1 для першого розкривного меню «Payload set», а потім виберіть payload type «Runtime file» та перейдіть до каталогу, куди ви завантажили ці текстові файли. Виберіть «actions.txt».
Повторіть крок 3, встановивши для набору Payload 2 значення «objects.txt».
Тепер натисніть кнопку «start attack» та випийте кави. Це займе деякий час.
Через деякий час, якщо пощастить, ви почнете знаходити маршрути до API, про які ви можете знати чи ні. Ласкаво просимо у світ виявлення API за допомогою брутфорсингу!
Тепер, коли ми відкрили API, настав час навчитися атакувати їх і знаходити вразливості.
Атаки на API
Тепер, коли ви знайшли кінцеві точки веб-API, які хочете дослідити, вам потрібно подумати, як ви плануєте підійти до тестування на проникнення.
Існує кілька методів атаки API, які можна використовувати під час злому API. Знання найпоширеніших типів атак допоможе вам залишатися зосередженим і дає змогу розробити просту методологію, якої легко слідувати.
OWASP зробив досить хорошу роботу, задокументувавши це у своєму списку Топ-10 безпеки OWASP API, і доречі оновив цей список у 2023 році. Однак, коли ви тільки починаєте роботу, є кілька типів атак API, на які ви повинні звернути увагу. До них належать:
Порушений контроль доступу
Порушена автентифікація
Неправильне керування даними
Слабка перевірка вхідних даних
Неналежне управління активами
Давайте розглянемо кожну з цих категорій атак.
1) Порушений контроль доступу
Однією з найпоширеніших атак на безпеку API є використання порушеного контролю доступу. Цей тип атаки відбувається, коли зловмисник може отримати доступ до ресурсів або даних, до яких він не повинен мати доступу.
Один із способів використати несправний контроль доступу — вгадати URL-адресу ресурсу, до якого ви не повинні мати доступу. Якщо API не перевіряє належним чином дозволи, ви можете переглядати, редагувати або видаляти дані, які ви не маєте права переглядати або змінювати.
Коли я кажу «вгадати URL», я маю на увазі можливість змінити URL таким чином, щоб повернути інші дані. Наприклад, якщо доступ до вашого особистого профілю здійснюється за адресою https://example.com/users/11/profile, де 11 виглядає як можливий ідентифікатор користувача, чи можна постукатись та отримати доступ до користувача 10 чи 12.
Якщо так, це зазвичай може підкреслити проблеми контролю доступу.
Коли ви виконуєте пентест API, це називається авторизацією на рівні зламаного об’єкта. Якщо ви звикли зламувати веб-додатки, це також відомо як Insecure Direct Object Reference (IDOR).
1.1) Шукаємо вулни, що проходять шлях
Інший спосіб використання порушеного контролю доступу — це використання техніки під назвою «обхід шляху». Ця техніка використовує вразливі місця у файловій системі веб-сервера. Надсилаючи спеціально створені вхідні значення, зловмисник може переміщатися по файловій системі та отримувати доступ до файлів і папок, до яких він не повинен мати доступу.
Як приклад, уявіть API, який отримує звіти за таким шляхом:
https://example.com/api/reports/11/abc123.pdf
За допомогою обходу шляху можна отримати файл passwd сервера, використовуючи щось на зразок цього:
https://example.com/api/reports/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd
Зловмисники також можуть використати порушений контроль доступу, використовуючи атаки на захоплення сесії. Атака з захопленням сеансу дозволяє зловмиснику отримати доступ до ідентифікатора сеансу користувача та використовувати його для отримання несанкціонованого доступу до облікового запису користувача. У випадку API це зазвичай робиться шляхом викрадення маркера авторизації користувача, як правило, маркера-носія у форматі JSON Web Token (JWT).
Говорячи про JWT, давайте обговоримо ще один великий тип атаки, який полягає в порушенні автентифікації.
2) Порушена автентифікація
Автентифікація в API – це процес перевірки того, що користувачі, програми, служби або пристрої API (іноді їх називають суб’єктами) є тими, за кого вони себе видають.
Є багато способів використання несправної автентифікації, зокрема вгадування паролів, зловживання витоком ключів API, викрадення ідентифікаторів сеансу або використання вразливостей у самому процесі автентифікації API.
Порушена автентифікація є серйозною вразливістю, яка може дозволити вам отримати неавторизований доступ до цільового API. Цей тип атаки відбувається, коли ви можете обійти процес автентифікації та увійти як дійсний суб'єкт.
Це можна зробити кількома способами, зокрема:
Через погано розроблений процес скидання пароля
Використання облікових даних. Це може спрацювати, оскільки користувачі API часто повторно використовують свої старі імена користувачів і паролі на різних сайтах. Отже, якщо їхні облікові дані витікають з іншого місця в Інтернеті, вони тепер можуть бути використані проти цільового API.
Викрадення конфіденційних даних, таких як паролі або токени, які можна використовувати для автентифікації, які зберігаються в параметрах GET. Це може навіть дозволити атаки «людина посередині» (MiTM).
Зловживання API, які не перевіряють дату закінчення терміну дії маркерів автентифікації, таких як маркери сеансу та JWT.
Зловживання API, які не перевіряють цифровий підпис JWT або дозволяють використовувати їх без підпису за допомогою алгоритму None.
Знання процесу автентифікації API може допомогти вам визначити найкращий спосіб, як атакувати його, особливо якщо у вас є доступ до журналів користувачів.
2.1) Процес автентифікації API
Існують різні способи автентифікації API. Чотири найпоширеніші методи:
HTTP Basic Auth
Ключ API
OAuth
NO/NULL Auth
2.1.1) HTTP Basic Auth
HTTP Basic Auth — це проста схема автентифікації, у якій ім’я користувача та пароль надсилаються з кожним запитом, зазвичай у кодуванні Base64. Це означає, що ім’я користувача та пароль можна легко розшифрувати, що є серйозною проблемою безпеки. Якщо API не використовує SSL, це означає, що будь-хто, хто може перехопити запит, може отримати доступ до облікових даних.
2.1.2)Ключ API
Автентифікація ключа API – це процес авторизації доступу до API за допомогою унікального секретного ключа, який генерується для кожного користувача. Зазвичай це складний рядок цифр і літер – зазвичай щонайменше 32 символи завдовжки, хоча для цього немає встановленого стандарту. Зазвичай він передається в заголовку авторизації API або як додатковий заголовок, як-от X-API-KEY тощо. Поширеним вектором атаки є відновлення цих ключів безпосередньо з вихідного коду (тобто: на GitHub) або програм зворотного проектування, які використовують API де ключ може бути статично скомпільований.
2.1.3) OAuth
OAuth2.0 — це популярна структура авторизації, яка дозволяє користувачам автентифікуватися в API за допомогою наявних облікових даних від таких постачальників, як Google, Microsoft, Facebook і Twitter. Протокол OAuth2.0 визначає, як робляться ці запити автентифікації та як використовується кінцевий маркер доступу. Щоб використовувати OAuth2.0 для автентифікації, вам спочатку потрібно зареєструвати свою програму у вибраного постачальника. Після реєстрації вашої заявки вам буде надано ідентифікатор клієнта та секрет клієнта. Ці облікові дані використовуються для створення маркера доступу (зазвичай JWT), який потім використовується для автентифікації запитів до API.
2.1.4) NO/NULL Auth
Іноді API може взагалі не використовувати автентифікацію. Зазвичай це спостерігається, коли від програм очікується внутрішній зв’язок або коли вони очікують використання шлюзу керування API для безпеки API, який неправильно налаштовано.
Розуміння того, як працює процес автентифікації API, дозволить вам відповідним чином маніпулювати цими запитами. На щастя, Burp робить чудову роботу, розкриваючи це та керуючи маркерами авторизації для вас. Ви навіть можете використовувати такі розширення Burp, як Autorize , AuthMatrix і JSON Web Token , які можуть допомогти вам перевірити та зловживати проблемами автентифікації та авторизації в API.
3) Неправильне керування даними
Розробники API повинні ретельно керувати даними, які вони надають. Якщо вони цього не зроблять, це може призвести до ряду проблем із безпекою.
Є два ключові способи використання неправильного керування даними. Перший полягає в викраденні додаткових даних, які повертаються, коли це не повинно бути – це зазвичай називають уразливістю «надмірного доступу даних».
Другий спосіб — скористатися тим, як розробники читають і зберігають об’єкти даних у своєму API. Якщо вони необережні, стає можливим перезаписувати об’єкти таким чином, щоб отримати додатковий доступ, підробити дані та обійти механізми безпеки. Зазвичай це називається «масовим призначенням».
3.1) Надмірний доступ до даних
Надмірна кількість даних виникає, коли розробники ненавмисно повертають більше даних, ніж вони повинні.
Сучасні мови програмування сьогодні люблять працювати з об'єктами . Зазвичай вони структуровані у схемі моделі даних, яка полегшує переміщення даних у службі. Оскільки більшість API розглядаються як прямі джерела даних, розробники іноді впроваджують їх у загальний спосіб, не думаючи про конфіденційність відкритих даних.
Вони очікують, що інтерфейсна програма відфільтровує непотрібну їм інформацію. І ми можемо зловживати цим, надаючи нам доступ до додаткових даних, яких ми не повинні мати.
У поєднанні з іншими вразливими місцями, такими як IDOR, через це ми спостерігали серйозні витоки даних популярних сервісів. Від витоку облікових даних до кредитних карток, пошук надмірної вразливості даних — чудовий початок під час злому API.
3.2) mass assignment vulns
Розглянемо типовий об'єкт «Користувач». Він може містити такі дані, як ваше ім’я , адреса електронної пошти та пароль . Він може навіть містити список полів, якщо ви адміністратор чи ні. Скажімо, для цього прикладу поле є булевим типом (true/false) і називається isAdmin . А тепер уявіть, що під час створення нового користувача (тобто під час реєстрації) йому автоматично встановлюється значення false . Саме тут ми можемо зловживати призначенням.
Як зловмисник, ви можете відтворити створений користувачем (тобто запит POST), але змінити об’єкт та встановити для параметра isAdmin значення true. Результат? Новий користувач стає адміністратором, навіть якщо він цього не повинен робити. Захистити API важко, коли розробники повторно використовують і узагальнюють дані, як це.
Це стає ще цікавішим, коли API вразливий до надмірного впливу даних. Коли ви можете побачити всю модель даних і зрозуміти, як речі зберігаються, ви можете використовувати все це неправильне керування даними, щоб справді зловживати роботою програми.
4) Слабка перевірка вхідних даних
Коли справа доходить до написання безпечного коду, ключове правило полягає в тому, щоб НІКОЛИ не довіряти введенням від користувача і завжди перевіряти їх, коли вони переходять межі довіри. Однак у API розробники часто не звертають увагу на це під час роботи з об’єктами даних, що призводить до вразливості ін’єкції.
Це може спричинити різноманітні проблеми. Ось лише кілька типових уразливостей ін’єкцій, якими можна зловживати:
Впровадження SQL/NoSQL – ви можете змінювати дані таким чином, щоб маніпулювати запитами, надаючи вам додатковий доступ до сховища даних або навіть дозволяючи запускати команди безпосередньо з бази даних.
Впровадження команд – ви можете змінювати дані таким чином, щоб виконувати довільні команди в операційній системі хоста.
Впровадження шаблону – ви можете змінити дані таким чином, щоб заплутати механізм шаблонів і змусити його виконувати код на веб-сервері. Зазвичай це називається серверним впровадженням шаблону (SSTI).
Впровадження XSS – ви можете змінювати об’єкти таким чином, щоб зловживати тим, як користувачі API можуть відтворювати дані у своїх інтерфейсних програмах, використовуючи потенційну вразливість міжсайтового сценарію.
Це дуже небезпечно, коли розробники не очищають вхідні дані, коли вони надходять і виходять з API; Якщо цього не робити, ви, як зловмисник, зможете напряму маніпулювати тим, як працює програма, і навіть можете закріпитися на інфраструктурі сервера.
5) Неналежне управління активами
Однією з переваг сучасної розробки API є гнучкість і швидкість, з якою можна розгортати новий код. Щоб забезпечити зворотну сумісність, ці API зазвичай використовують схему управління версіями, яка дозволяє старішим версіям API запускатися паралельно з новим кодом. Ми можемо скористатися цим.
У міру написання нових API моделі даних можуть змінюватися. Як і спосіб управління. Часом ви можете зловживати цим, викликаючи старішу версію API, яка може бути невиправленою та не підтримуватися регулярно. Їх іноді називають зомбі API .
Інша проблема полягає в шахрайському API . Це API, який був написаний, але не належним чином задокументований або зареєстрований як офіційний API для компанії. Ці фальшиві API можуть бути небезпечними, оскільки вони ніколи не перевірялися на безпеку та можуть містити всілякі вразливості. Гірше того, якщо вони створені зовнішніми третіми сторонами, початкові власники даних базових API можуть не знати, що їхні дані розкриваються таким чином.
5.1) Zombie API
Переваги атак зомбі-API полягають у тому, що вони зазвичай досить статичні. Зазвичай вони задокументовані, і ви можете порівняти версії, щоб побачити зміни. І, звичайно, ви можете використовувати це як рецепт, щоб побачити, чи зможете ви маніпулювати запитами на основі цих змін.
Наприклад, якщо ви помітили, що в об’єкт даних додано нові поля, які потребують більш високого рівня доступу для читання, подивіться, що станеться під час доступу до цих полів із старішої версії API. Наприклад ви відкрили через API сторінку користувача https://example.com/api/v2/user-11/ і коли ви будете стукатись на сторінку іншого користувача https://example.com/api/v2/user-22/ , то у вас може і не буде доступу, але якщо ви зміните v2 на v1 версію апі, то у вас все вийде, бо розробники не закрили цю дирку в старій версії API.
5.2) Шахрайські API
Небезпечними шахрайські API є те, що часто вони існують, навіть без здогадувань у власників даних. Наприклад, дані CRM можуть надаватися сторонній маркетинговій платформі, яка надає їм занадто великий доступ до основних записів клієнтів. Саме так у минулому відбувалися серйозні зломи таких служб, як Facebook і Salesforce.
Іншим прикладом фальшивих API є екземпляри API для розробників і тестування, які можуть не мати таких самих елементів керування безпекою, як робочі екземпляри. Наткнувшись на ці випадки під час розвідки, ви можете отримати більше часу та доступу для зловживання API, не боячись, що про це дізнається NOC/SOC. Наприклад стукаєтесь ви до юзера через API https://example.com/api/prod/v2/user-11/ і ви не можете достучатись без належних прав, але якщо ви зміните prod на test https://example.com/api/test/v2/user-11/, щоб спробувати постукатись може до тестової інфраструктури компанії, то якщо тестове середовище доступно для зовнішніх користувачів і там немає належних перевірок на захист, ви як шахрай зможете отримати звідти дані
Висновок
Багато в чому злом API дуже схожий на злом веб-додатків. Різниця полягає в тому, як розробники довіряють API для переміщення даних. Якщо ви можете зрозуміти, як вони це роблять, і матимете чітке уявлення про те, як вони працюють з об’єктами під ними, ви можете підійти до цілі більш кращим способом під час тестування API на проникнення.