Bug or Defect?

Друзі привіт, як ви? Ну шо як і завжди повертаємося про беспеку? Сьогодні хочу поділитись штукою, яка, як на мене, має бути у кожного хто працює з API - неважливо, ви QA, Dev чи просто хочете краще розуміти, що відбувається “під капотом”.Натрапив на дуже цікавий репозиторій - API Security Empire.І чесно, виглядає це як нормальний “центр управління польотами” по всіх темах безпеки для REST, GraphQL і SOAP.Що я маю вам сказать)Це зібрана в одному місці база знань по тестуванню безпеки API.Там є і майндмепи, і інструменти, і сценарії атак, і чеклісти - все, щоб не просто “тикати ендпоінти”, а реально розуміти, де слабкі місця.Реально прикольная структура• структуровані mindmap-и для розвідки і атак• нормальний список тулзів, якими реально користуються (Burp, FFUF, Arjun, Kiterunner, SecLists і т.д.)• сценарії атак під REST, GraphQL, SOAP• купа навчальних матеріалів - дуже зручно, якщо хочеш підтягнути або систематизувати знанняви же знаєте тестувати API тільки на “expected result”- це база.А от дивитися на API як на поверхню атаки - це вже зовсім інший рівень.Можна набагато краще розуміти архітектуру, поведінку запитів і логіку обробки даних.Ну і чесно, воно прокачує вашу інтуїцію QA дуже сильно.само репо:https://github.com/Cyber-Guy1/API-SecurityEmpireЯкщо хочете реально рости в темі API - це гарне місце почати або продовжити.Можу зробити окремий пост з тим, як КУА може використовувати ці техніки без пентест-скилів, але дуже ефективно.Всім гарного дня і настрою друзіСильні 💛💛💛

Доброго ранку банда! Як ваш ранок?Слухайте, хочу вам розказати як я вчора в 10 веччері попав на фокап , і коли ти думаєшь «Чорт, а я ж думав, що знаю мережі» ))Ранкові QA-історія: як же іх давно не було ТАК???Тестував я інтеграцію між двома сервісами.Умовно Сервер Х шле запити на Сервер Y - і раптом половина викликів тупо падає в таймаут. Без помилок. Без 5xx. Просто тиша.Ну окей, думаю«Зараз три каманди в терміналі - і розберемося».Ага… як же жНу перевірка, як завжди, з очевидногоЦе - ncnc -vz server-y 9090 конект є, все красиво.як же без telnettelnet server-y 9090 - всі помьятають шо він робе так? і теж ок.ну і сurlcurl -v http://server-y:9090/health і тут вже починається «вічне завантаження»… і Потім timeout.Тобто дістатися можна, а відповіді нема.Так-так, це той самий момент, коли мозок каже: «ооо, походу буде весело».Короче поліз я даліТобто сервері Y сервіс живий:Спробуємо sudo ss -tulnp | grep 9090 У логах видно, що запит прийшов і навіть була сформована відповідь, і трафік на вихід теж є - tcpdump підтвердив.І тут уже зрозумів:проблема не на стороні Y, відповідь відправляється.І ось тут почалося цікавеНа сервері X зняв дамп:Через sudo tcpdump -i eth0 host server-y -w debug.pcap Відкриваю у Wireshark.І реально видно:SYN → SYN-ACK → ACK → запит полетів → а назад пакетів НУЛЬ.Не дроп, не RST, не ICMP. Просто… нічого.Як у чорну діру.тобто розгадка яка (після години матюків і інфри)Виявилось, що сервер X після міграції в інший датацентр отримав новий набір правил фаєрвола.І там було правило типу: - дозволити вихід на порт 9090, але заборонити вхідні пакети з цього діапазону IPТобто:- вийти можна- повернутись не можнаІ curl зависав, бо пакет-відповідь просто рубився фаєрволом ще до додатку.Шо я маю вам сказать:Не ведіться на «telnet працює - значить все добре».Telnet і nc показують тільки те, що можна достукатись,А не те, що відповідь повернеться назад.Фаєрволи інколи працюють за принципом:«Випущу. Але назад не пущу.»І це найпідліший тип багів.Всім гарного дня і настрою!Обняв, друзі 🤗🤗🤗