Bug or Defect?

Друзі привіт - як ваш день? Сподіваюсь ви та ваші близки в безпеці. Ну шо ви вже бачили новий HTTP метод QUERY?) тут RFC 10008 виглядає прям як спроба трохи полегшити життя тим, хто працює зі складними API-запитами.https://www.rfc-editor.org/info/rfc10008/Якщо я правельно зрозумів то QUERY це ти щось QUERY /usersContent-Type: application/json{ "status": "active", "roles": ["admin", "qa"], "sort": "-createdAt"} Тобто виглядає ми можем передати складний query у body, але сам метод при цьому задуманий як safe та idempotent. Для КУА тут виглядає цікаво те, що такі запити можна безпечніше retry-ити після network failure, а ще для них передбачено кешування.Тобто умовно: GET - простий query через URL POST - ми виконуємо операцію через body а вже QUERY - робимо складний пошук через body без зміни стану ресурсу чи не?? І ще один момен який виглядає цікавий момент для тестування: типо для QUERY важливий Content-Type. Якщо його немає або body йому не відповідає - сервер повинен повернути 4xx. Як на мене, виглядає реально зручно. Особливо для складних фільтрів, search API, великих запитів і випадків, коли URL вже перетворився в якусь магічну строку на пів екрана)Звісно Побачимо, наскільки швидко це почнуть підтримувати фреймворки, proxy, API Gateway і різні інструменти. Обняв 🤗Сильні 💛

Друзі доброго раночку - як ви?Недавно побачив 1 круту штуку і вигляждає прикольно - це для тих хто дивиться в сторону security, AI і pentest.Короче OWASP APTS роблять штуки) це типо стандарт від OWASP про те, як мають працювати автономні pentest-системи, особливо ті, де використовується AI. Тобто це не про “як тестувати API” або “як знайти SQL injection”.Це більше про правила гри: як не вилізти за scope або як логувати дії типр як мати human approvalчи зробити kill switch ну і як же без контролювати AI-агентівТобто проєкт офіційно знаходиться в OWASP, але він ще на ранній стадії. Яб не називав це типо золотим стандартом, але як база для розуміння дуже цікаво.Також окремо подивився, хто стоїть за проєктом і чи немає якихось дивних зв’язків.всіж знаю так? що AI в security вже не просто “прикольна іграшка”. І якщо інструмент може самостійно сканувати, атакувати, приймати рішення і будувати ланцюжки дій там дуже важливо мати правила, обмеження і контроль.Бо без governance це вже не автоматизація, а “ну подивимось, що воно зламає”.Писав писав а лінк чуть не забув додати)) https://github.com/OWASP/APTSОбняв 🤗Сильні 💛

Друзі привіт, як ваш день?Сподіваюсь ви та ваші близькі в безпеці.Давайте сьогодні трохи спустимось нижче браузера, Postman і красивих UI-кнопочок. всеж кінець тижня треба чучуть подумати?))) Протоколи для QAЩо я маю вам сказати одразу: іноді проблема виглядає так: “апка не конектиться” “дзвінок не стартує” “дані не приходять” “сервер живий, але клієнт каже timeout” тощо - причин мільон і ви без мене з цим стикалися і знаєте І дуже часто це не UI, не API і навіть не завжди бекенд. Це може бути рівень нижче: порт не слухається/ TCP-з’єднання не встановилось або UDP пакети не доходять ну і DNS резолвиться не туди чи краше firewall ріже трафік тобто стільке же причин як і проблем - ага?)) давайте коротко ще раз TCP - це коли важлива доставка, порядок і контроль.тобто це все що HTTP / HTTPS/ SSH / WebSocket і деякі REST API. Працює вроді складно, але просто)Клієнт каже типо щось я хочу підключитись і ось мій SYNСервер відповідає: ок, бачу тебе ось мій SYN-ACKКлієнт підтверджує: ACK, погнали працювати І тільки після цього нормально йдуть дані.UDP -це вроді одна історія але це вже інша історія. Тут вже швидкість важливіша за гарантії. тут вже буде DNS/ VoIP/ RTP/ WebRTC media/ стрімінг/ і UDP просто відправив пакет і далі вже як життя складеться)Для кастомерів це може виглядати типо так нема звуку/ нема відео / дзвінок підключився, але медіа не йде/ realtime працює нестабільно а для КУА це вже сигнал: треба дивитись нижче.Реально знати на рівні лінукса корисно і мати цим користуватися) ss -tulnp Показує вам, які TCP/UDP порти слухаються і який процес їх використовує.Типо щось ss -tan Показує TCP-з’єднання і їх стани. Тут можна побачити:- ESTAB - з’єднання встановлено- SYN-SENT - клієнт стукає, але відповіді нема- TIME-WAIT - з’єднання вже закривалось- CLOSE-WAIT - апка могла не закрити connection нормальноМожно ще 1 корисну штуку nc -vz server.com 443 Це перевірка, чи доступний TCP-порт і тут важливо не плутати:- Connection refused - хост доступний, але порт закритий або сервіс не слухає.- Connection timed out - відповіді нема. Може бути firewall, routing або network issue.а ось це окремий кайф це tcpdump або udpsudo tcpdump -i any port 443 sudo tcpdump -i any udp це тут коли треба розуміти чи пакет взагалі виходить чи приходить відповідь або є DNS-запит чи UDP реально йде ну і сервер сам закриває з’єднанняЦе як 1 криклад вам розбору умовно є баг: “Клієнт не може підключитись до сервера” ну і тут І замість просто написати “не працює”, можна перевірити:ping server.comnslookup server.comnc -vz server.com 443ss -tan | grep 443sudo tcpdump -i any host server.com І потім у баг-репорті написати вже нормально: типо щось “Під час спроби підключення клієнт відправляє TCP SYN на server.com:443, але SYN-ACK у відповідь не приходить. З’єднання залишається в SYN-SENT і завершується timeout.” Оце вже звучить як куа, який прийшов не просто кнопку натиснути)Що я хочу до вас донести Linux-рівень для КУА - це не про “стати адміном”. Це про те, щоб коли апка каже: “Something went wrong” і ви могли зрозуміти, де саме проблемаІноді один ss або tcpdump дає більше, ніж 30 хвилин кліків по UI.Всім гарного дня і наближення вихідних) Сильні💛Обняв 🤗

Друзі доброго вечора) АНОНС❗️❗️❗️Добрався я до посту і вже який можно робити анонс) Ну шо, ви готові, я прислухався до вас і ваших запросив і робимо першу ітерацію Запуску міні курсу по протоколам, будемо розбирати в першому курсі всі відомі протоколи з моделі osi , не про рівні а саме про відомі протоколи, якщо перший зайде і якщо вам сподобається , другий буде чуть по нижче Курс буде состоять з 6 уроків я думаю що 2 раза на тиждень - але час пізніше точно узгоджемо з усіма в окремому чаті) Будемо розбирати як працює кто куди ходе і шо питає і навіщо, вже чучуть пізніше дам більше обширно інфу)Ну я думаю хто у мене був знає про шо я а хто не то взнає - шо води не буде - будемо практикуватися!Курс буде платним 4300 грн Як тільки курс буде готовий на 80%, ми одразу звʼяжемося з усіма хто забронював місце і розкажемо деталі: дати, час, формат і оплату. Note: бронь поки без оплати) Для броні місця, пишіть сюди https://t.me/Oleh_AmelinДаже якщо будуть ті люди які мені писали в лс все одно курс буде) Сильні💛Обняв, 🤗

Друзі привіт - як ваш день?Чучуть хотів повернутися до протоколів і я особливо думаю не дуже буде зрозумілий до всіх саме цей протокол)Протоколи для QA - MQTTЩо я маю вам сказать.шо це за такий MQTT - це не “ще один HTTP для галочки”. Це реально легкий протокол для обміну повідомленнями, який дуже часто живе там, де є: IoT, датчики, телеметрія, смарт-девайси, промислові системи, робототехніка, всякі пристрої які постійно щось шлють і слухають.І тут КУА дуже часто впирається в стіну бо MQTT працює не так, як звичний REST чи API-запит.саме тут вам важливо зрозуміти, що MQTT = це модель publish / subscribe. тобто один клієнт публікує повідомленняbroker його приймає а інші клієнти підписані на topic і отримують це повідомленняНе “запит-відповідь”, а події. ну я думаю всі знають про вебсокіт так?? Умовно є датчик температури шле в topic: factory/sensor1/tempСаме повідомлення типу:{ "temp": 23 } І вже інша система це читає і реагує.Тобто якщо MQTT не працює як треба - ніякий “перезапусти UI”, “глянь API” або “а в Postman ок” не допоможе. Бо саме тут логіка асинхронна.Самі типові симптоми MQTT-проблем:повідомлення інколи не доходять, або приходять із затримкою, або дублюються, або subscriber нічого не отримує, або після reconnect все перестає працювати, або один клієнт бачить дані, а інший ні.і так тут все на низах, пару прикладів якщо колись будете стикатися з цимЧи взагалі приходить повідомлення:mosquitto_sub -h localhost -t "factory/sensor1/temp" Чи можете самі відправити тестове:mosquitto_pub -h localhost -t "factory/sensor1/temp" -m '{"temp":23}' Чи не губляться повідомлення, чи немає дублювань, який QoS, що буде при reconnect, що буде якщо broker впаде, чи правильно працюють retained messages.Звісно КУА не зобов’язаний піднімати брокер і ставати IoT-інженером. Але зобов’язаний розуміти, коли проблема саме там.Бо інакше половина “дивних” багів так і залишаться магією.Сильні💛Обняв🤗

Друзі привіт, як ваш день? Сподіваюсь, що ви та ваші близькі в безпеці.Сьогодні хочу вам трохи пожалітись, а може й понити, але тема реально болюча.Я вже 3 місяці шукаю людину до себе в команду. Позиція скоріше десь рівня сіньйора, але, скажімо так, можна і сильного перспективного мідла.І ви скажете: невже 3 місяці нема кандидатів?Кандидатів дуже багато. Реально багато. Але проблема не в кількості.Одна частина відпадає ще на рівні резюме, бо просто не вистачає досвіду або потрібних скілів. Це окей, таке буває.Але інша частина доходить до співбесіди і от тут починається найцікавіше. Люди приходять з 5, 7, 10 роками досвіду в мануальному тестуванні і, чесно, не тягнуть навіть базові речі. Не тому, що проект якийсь космічно складний чи специфічний. А тому, що часто нема глибини: по термінах, по підходах, по загальному розумінню тестування, по технічній базі.І я вам скажу чесно і це дуже часта історія.Скоріше на мою думку це відбувається саме за того бо людина колись зайшла на проект, де умовно треба було тестувати веб без сильного заглиблення в технічну частину, і сидить там 5+ років. Працює в комфорті, задачі знайомі, все стабільно. І наче досвід росте по рокахА потім людина хоче перейти на вищу зарплату, на складніший проект, на цікавішу роль і не може. Не тому що. А тому що не росла, поки була можливість.І от що я хочу до вас донести.Якщо ви сидите на простому проекті, розвивайтесь самі.Не чекайте, що проект вас виростить автоматично.Саморозвиток ніхто не відміняв.Читайте, дивіться, що відбувається з технологіями, копайте глибше.Зараз ринок реально йде в сторону нижчого рівня розуміння: як працюють фічі, як влаштована архітектура, як поводиться система під капотом, а не просто “я перевірив веб і написав баг”.Якщо хочете рости, бути конкурентними і не хочете, щоб вас просто з’їли на ринку - треба розвиватись. Інакше 7–10 років досвіду можуть важити менше, ніж 2–3 роки, але у людини, яка реально копала глибше і хотіла розуміти більше.І повірте мені на слово: компанії зараз готові платити великі гроші. Але не за роки в резюме. А за знання, мислення і глибину. І AI тут не завада,він не заміняє голову.Всіх обняв.🤗Сильні.💛

Друзі, привіт. Як ваш день?Ну що продовжимо нашу рубрику бо я бачу шо ви пишете чого бвльше про це не пишешь всім заходить вона ТОПротоколи для QA.Сьогодні про штуку, яку всі бачать щодня, але мало хто реально розуміє, як вона працює. Я це про SMTP.SMTP це не “пошта взагалі”. Це саме протокол відправки email.Тобто коли система шле: reset password або verify email чи OTP і нотифікацію то дуже часто під капотом працює саме SMTP.По факту логіка проста: ваша апка не “магічно” відправляє лист. Вона підключається до SMTP-сервера і каже: ось від кого, ось кому, ось тема, ось тіло - відправляй.Виглядає це десь щоссь приблизно так:HELO app.localMAIL FROM: <[email protected]>RCPT TO: <[email protected]>DATASubject: Reset password... Так шо я маю вам сказать Більшість КУА тестують тільки факт: кнопку натиснули → лист прийшов.А далі не копають. І потім починається знайома класика:лист інколи не доходить або OTP приходить із затримкою чи verify link у спамі і частина листів відправляється, частина ні HTML зламаний або цікавіше from не той або SMTP взагалі відповів помилкою, але апка сказала “успішно”І всі дивляться на “пошту не працює”, а проблема може бути саме в SMTP-частині.Частіше проблем може буди дуже багато - дам то шо зустрічав - неправильний SMTP host або port- проблема з auth- TLS/STARTTLS не зійшовся- sender domain невалідний- rate limit- blacklisting- лист відправився, але провайдер його завернув- апка не обробила SMTP error нормальноТобто “лист не дійшов”, це взагалі не завжди один і той самий баг.Перевірити теж можно просто Подивитись SMTP-конект:nc smtp.server.com 25 Або якщо TLS:openssl s_client -connect smtp.server.com:465 Або STARTTLS:openssl s_client -starttls smtp -connect smtp.server.com:587 Для локального тесту дуже зручно ловити листи через локальні тули - тоді взагалі видно все, що система шле, без реальної доставки назовні.Що хочу до вас донести.SMTP це не “десь там інфра”це частина бізнес-логіки.Бо якщо у вас не працює reset password, verify email або OTP то для користувача система не працює взагалі.І якщо КУА тестує тільки “лист прийшов / не прийшов”, він бачить тільки половину картини. Друга половина це доставка, статуси, SMTP-відповіді і те, як апка на них реагує.Сильні 💛Обняв🤗

Друзі, Доброго ранку. Як ваш день?Хотів вам сьогодні показати не зовсім протокол, а 1 механізм, який ви точно бачили в API, якщо хоч раз тестували логін чи авторизацію.Я це про JWT token і дивно, що багато хто бачить його постійно, але не до кінця розуміє що це.Що я маю вам сказать) JWT це не якийсь окремий протокол. Це просто механізм, яким сервер типо каже: “ок, ти залогінився, ось тобі токен, далі ходи з ним”.По факту це такий підписаний шматок даних, який зазвичай передається в: Authorization: Bearer <token>Виглядає приблизно шось типо такого:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcxOTk5OTk5OX0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c В середині там все просто - я думаю шо ви знаєте шо це не просто список символів перша частина це як воно підписане, друга це payload, тобто дані ну і третя це signature, щоб ви не могли просто руками підмінити роль чи user idБільшість КУА бачать JWT і дивляться тільки: є токен чи нема токена. А далі не копають. І потім починається по колу:лог-аут зробили, а токен ще живий / пароль змінили, а старий токен працює або роль у юзера змінили, а доступ залишився тощоІ всі дивляться на “авторизацію в цілому”, а проблема саме в JWT-логіці.Зазвичай може поламатися такі штуки як, токен не протухає коли має або backend не перевіряє signature як треба/ logout не інвалідує токен/ refresh token живе вічно / role в payload одна, а доступи інші ну і access token працює після зміни пароляЩоб швидко глянути що всередині токена: можна просто відкрити в https://jwt.ioну або руками декоднути payload.як куа ви можете перевіритищо буде без токена/ що буде з протухшим токеном/ що буде з битим токеном/ що буде з токеном іншого юзера/ що буде після logout/ що буде після зміни ролі або пароля тощоБо якщо тестувати тільки “залогінився / не залогінився” ви бачите половину картини.Друга половина - це як токен живе далі.І якщо її не перевіряти - баги будуть. Стабільно.Обняв🤗Сильні💛

Друзі привіт, як ви?Хочу сьогодні кинути вам одну дуже корисну штуку, особливо коли приходите на проєкт, а API документації нема взагалі.Ну тобто не “погана”, а просто нема) Так що я маю вам сказатьЯкщо у сервісу нема нормальної API-доки - це ще не значить, що ви сліпі.Часто весь трафік можна перехопити прямо з браузера і подивитись, що фронт реально шле на бек.І це реально працює через Postman InterceptorChrome Web Store: https://chromewebstore.google.com/detail/postman-interceptor/aicmkgpgakddgnaphhhpliifpcfhicfoну і документація Postman: https://learning.postman.com/docs/sending-requests/capturing-request-data/interceptor/Далі в Postman вмикаєте Capture requests, якщо треба ставите сертифікат для HTTPS, перезавантажуєте сторінку сайту і все.Усі запити, які сайт відправляє з браузера, починають падати вам прямо в Postman:тобто URL/headers/body/cookies/токени/responseТобто по факту ви самі собі збираєте документацію з живого трафіку. це пряд дуже рятує коли нема Swagger, нема Postman collection, нема опису ендпоінтів, а тестувати треба вже зараз.Єдине, що важливо розуміти: це добре працює саме для браузерного трафіку. Тобто те, що реально шле фронт.Якщо там окремі бекендові інтеграції або щось іде не через браузер -ну і зрозуміло шо цього ви так не побачите.Але для старту, для дослідження API і для КУА штука прям дуже сильна.Так що ану кажіть хто працював без доки? я помьятаю свій проєкт перший коли прийшов один + ше в принцепі перший КУА на проект а там документації не просто нуль а мінусь нуль) Сильні💛Обняв🤗🤗🤗

Доброго дня друзі, як ваш день? Сподіваюсь ви в безпеці зі своїми любими)Нічого не постив бо хотів, щоб більше людей побачили пул.Бачу шо люди реально все більше і більше користуються ШІ - і це круто, правда.Він реально помічний: щось перекласти, перефразувати, приклад знайти, швидко згенерити тест чи SQL, не гуглити годину.І бачу шо GPT лідирує - бо він типо первий і це логічно.Але багато хто пише (і я теж це бачу), що з часом навіть платний ГПТ починає підторможувати, особливо коли чат довгий і вже забитий контекстом.І тут важливий момент. Памʼятайте, краще не давати корпоративну інфу компанії в публічні AI.Токени, прод-логи, внутрішні API, клієнтські кейси, не треба.Так, є платні плани, де кажуть, що не тренують на ваших даних. Але якщо можна не ризикувати, краще не ризикувати.Я шо тут хочу вам показать і розповісти про Ollama - я вроді вам вже говорив але ше раз)https://ollama.comЦе короче такий локальний AI-движок. - Тобто модель крутиться прямо у вас на компі. Без хмари. Без API-ключів. Без передачі даних кудись назовні.ну ставиться простоcurl -fsSL https://ollama.com/install.sh | sh Потімollama pull llama3ollama run llama3 І у вас вже локальний ШІ. ну він типо працює як і для генерити SQL, автотести, код, допомагати з логами або пояснювати, як працює запит чи працювати як локальний API ну і можна прикрутити до Postman або CIЯкщо залізо не топ. беріть легші моделі типу 3B.Я реально бачу, що майбутнє КУА це не просто manual чи automation.Це QA + AI + security ну я думаю і ви так же думаєте) І той, хто навчиться правильно юзати AI як інструмент, а не як костиль, буде рухатись швидше.Всім гарного дня і настрою.Обняв🤗🤗🤗