Всім доброго вечора друзі)

Щось давно не було!
Вечірня історія QA. Як перевірити, чи проект світиться назовні і заробити плюсик в репутацію.

ну що я маю вам сказати.

Повертаємось до теми безпеки. І якщо ви QA, який не просто клікає кнопки, а хоче розуміти, що реально з проектом ця історія для вас.

Сьогодні поділюсь одним лайфхаком з реальної практики.

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

Задача яка перевірити, чи проект відкриває щось зайве через nginx. якщо якась службова інфа світиться зовні, це реальна дірка.
І я вирішив це перевірити

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

Суть яка
Береш якийсь умовний, непримітний файл. Називаєш його скажімо,

internal-status/health.txt або zxc123/debug.log.

Далі, пробуєш просто постукати по порту напряму.
Наприклад, у вас девсервер був на

10.10.123.123

, і пробуйте

curl -I http://10.10.123.123:443/zxc123/debug.log

І Якщо
200 OK. І пішов контент.
то цей лог доступний зовні. Просто валяється під руками, без авторизації, прямо через NGINX.
Це не баг у коді. Це неправильна конфігурація nginx. просто забули закрити або прибрати шлях у location.

І от тут ви вже не просто QA, а той, хто потенційно врятував реліз від зливу інфи.


А тепер ще цікавіше: .git/

я часто читаю шо деви особливо не опетні забувають прятати .git, і ви можете це перевірити не відкрита службова папка .git/ (а вона часом випадково заливається разом із кодом).

просто зробіть

curl -I http://{{IP}}/.git/config

І якщо знову 200 OK і у відповідь прийшов вміст git-конфігу з remote URL, ім'ям розробника, і навіть ssh-ключем (true story 🫣). то це просто провал)

Це реальна загроза, бо

 .git/HEAD, .git/config, .git/index

- відкривають структуру репозиторію, через них можна відновити весь код і навіть знайти секрети, які колись хтось пушнув

як перевірити, що шось лишнє світиться,

Найпростіше через curl
Умовно

curl -I http://<IP>:<port>/.git/config

Можете перевірити ще кілька

curl -I http://<IP>/.env
curl -I http://<IP>/debug.log
curl -I http://<IP>/logs/latest.log

Якщо щось дає 200 OK бігом в чат з девами


Чому це важливо для QA?
Бо іноді найкращий тест це просто подивитись трохи глибше. Ти можеш реально знайти вразливість, яка обійде всі UI-тести, не вилізе в CI. і яку ніхто навіть не шукав

А ти взяв і знайшов і тебе вже хвалять)

Поінт від мене простий
Навіть не будучи сек'юріті інженером, ви можете знаходити великі речі. Просто треба розуміти, що і навіщо перевіряти.

Такі штуки це реальний плюс до твоєї репутації як QA.

якщо хочете окрему шпаргалку по типових шляхах, які треба перевірити чекаю від вас ❤️

а вообще спробуйте шо у вас і напешіть в коментарях шо вийшло або ви про це взнали і перевіряєте це вже давно)

Бажаю вам гарного вечора!
Обняв 🤗

Друзі, всім доброго раночку ☀️
Сподіваюсь, ви в безпеці, і вже з кавою)

Нехай сьогодні буде день без багів, з приємною командою і нормальним інтернетом (це теж важливо ) бо у мене вчора був просто жесть.
А якщо ви сьогодні не на роботі просто відпочиньте. Ви це заслужили 💛

А відео просто як легке нагадування всім, хто часом переживає, що GPT, AI, роботи йдуть забирати нашу роботу.


Спойлер, не заберуть, якщо ти думаєш, аналізуєш і вмієш задавати питання 😉

Гарного і спокійного вам дня, обняв 🤗

НА ВІДЕО ПРИСУТНІЙ МАТ

Збираємося???

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

І так що я маю вам сказать!

(A) Компонент кешує старий state і чому одна з правильних відповідей
Це прямо топова причина, фронт після логіна не перерендерив потрібний компонент або взяв дані з попереднього useState/useEffect.
Таке буває, якщо логіка не підв’язана на userId чи authState, а просто працює як було.


(B) Куки не оновились після логіна це майже відпадає.
Якби куки не оновились, API скоріш за все повернув би 401 або дані старого юзера, А ми ж бачимо, що API дає правильну відповідь, просто UI не встигає або не знає.


(C) Браузер тримає старий localStorage тут можливо, але залежить від реалізації. бо якщо фронт бере дані не з API, а з localStorage (бо так хтось оптимізував) то після логіна може не бути оновлення.
Тоді в дашборді буде старе userInfo, поки не перезавантажиш сторінку.



(D) Race condition між запитами. це серйозний кандидат у винуватці.
Уявіть ви логінитесь, UI одразу відправляє запит на дані юзера, але токен або куки ще не оновились.
І бах дашборд приходить з даними попереднього юзера або взагалі кешованим.


(E) У бекенда затримка в записі даних, Рідко, але трапляється.
Якщо бек ще дописує сесію, або профіль юзера не одразу оновлюється в БД тоді дані можуть повертатись із затримкою.
Це зазвичай вирішується ретраєм або затримкою перед фетчем.


Якщо ловили таке у проєктах діліться як відловлювали.


Note: Про зустріч) це не інфо циганство це просто корисна зустріч щоб круто провести час, поспілкуватися обсудити якісь круті насушні питання)

Банда привіт!
Сьогодні п’ятниця, той день, коли хочеться все встигнути, все доробити, і вже о 17:00 сидіти нога на ногу з кавусею в руках

Але ж ми знаємо, як воно буває.
18:00 і твій тімлід такий: А давайте ще швидко придумаємо концепт на понеділок. 😅
Ти якого вже як годину у компа нема)))
Ви сильні 💪 Гарного дня!

Всім доброго вечора) Як ваш день?

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


Що я маю вас сказати, ось ТОП службових файлів і директорій, які іноді забувають сховати

Як завжди по класиці через curl -I або навіть просто в браузері, якщо IP/домен доступний)

Це перевірка конфігів

curl -I http://<IP>:8080/.env
curl -I http://<IP>:8080/config.json
curl -I http://<IP>:8080/.htpasswd

Це лог-файлів

curl -I http://<IP>:8080/debug.log
curl -I http://<IP>:8080/logs/latest.log

Це git

curl -I http://<IP>:8080/.git/config
curl -I http://<IP>:8080/.git/HEAD
curl -I http://<IP>:8080/.gitignore

Це health/статуси

curl -I http://<IP>:8080/healthz
curl -I http://<IP>:8080/server-status
curl -I http://<IP>:8080/internal/status

ну і не забувайте шо якщо це https то це по замовчуваню 443 - на 8080 це я вам як приклад)


Якщо щось з цього повертає 200 OK це означає
- Файл/шлях світиться
- Немає захисту (навіть найпростішого deny all або auth_basic)
- І будь-хто ззовні може отримати доступ до внутрішньої інфи (url-и, конфіги, ключі, логи)

І ше раз повторюсь чому це критично
- Це не якась дрібничка, це може коштувати компанії витоку
- Це може бути точкою входу для атаки
- І ви, як QA, можеш бути тим, хто зупинив це ще до релізу

ну і мій поіт по висновку
куа не зобов’язаний бути сек’юріті-спецом, але розуміти, де шукати дірки, це вже 50% справи. Навіть простий curl і трохи уважності можуть підняти тебе в очах команди.


Ну що всім гарного вечора друзі, відпочивайте хто як вміє)

Всіх обняв 🤗💛