Сьогодні ти перевіряєш чужий продукт і даєш перевірити свій. Це останній урок модуля — і єдиний, де правила читають до техніки, а не після
Сьогоднішня робота зветься крос-аудитом. Кожна група перевіряє не себе, а сусідню. 10A перевіряє продукти 10B, 10B перевіряє 10C, 10C перевіряє 10A. Кільце замкнене, і своєї роботи не перевіряє ніхто.
Ти отримуєш адресу цілі. Списку авторів ти не отримуєш. Хто саме писав цей код, дізнаєшся аж на захисті. Так перевіряти чесніше: нема кого пожаліти і нема кому помститися. Є тільки чек-лист.
| Етап | Хв | Що робимо |
|---|---|---|
| Брифінг red team | 10 | Межі: лише ціль зі списку, лише за чеклистом, без псування даних |
| Крос-аудит | 30 | Запускаємо перевірки за 12 картками, збираємо докази в audit-report.json |
| Обмін звітами | 10 | Читаємо чужі знахідки, ставимо уточнювальні питання |
| Виправлення (blue team) | 30 | Лагодимо спершу блокуючі 🔒-пункти, перезапускаємо перевірки |
| Повторний прогін | 10 | audit.sh по всіх продуктах — фіксуємо фінальний стан чеклиста |
| Захист проєктів | 20 | Проблема → рішення → демо → архітектура → «що зламали у себе самі», 3 хв + 2 хв питань |
| Підсумок модуля | 10 | Зведене табло — формулюємо 3 правила, які заберемо із модуля |
| Разом | 120 |
audit-rules.md у теці команди.
Вихід за межі анулює весь звіт команди — не лише знахідку того,
хто вийшов.Твоя ціль — 91.219.61.4/s/team-b3. Перевіряючи її, ти помічаєш,
що на сусідній адресі 91.219.61.4/s/team-b4 форма відгуків
очевидно вразлива — видно з першого погляду. Що робиш?
Ламати цікавіше. Лагодити цінніше. Сьогодні ти півтори години робиш і те, і те — і побачиш, що це різні голови
Одні шукають, чим продукт можна зіпсувати. Вони діють як зловмисник, але в дозволених межах і з обов'язком усе записати. Таку сторону називають red team, «червона команда».
Інші приймають знахідки й закривають їх. Вони розставляють, що лагодити першим, лагодять і перевіряють, чи справді полагодилося. Це blue team, «синя команда».
достатньо одного пропущеного місця
треба закрити всі місця, і надовго
FIXES.md, що і коли зроблено.У житті це не дві професії, а одна. Людина, яка вміє знайти вразливість, зазвичай знає й ціну виправлення.
Тому в резюме пишуть не «я вмію ламати», а «інженер з безпеки». І на співбесіді питають не «що ти зламав». Питають інше: як ти це полагодив і чим довів, що полагоджено.
Команда за 30 хвилин знайшла в цілі одинадцять проблем і дуже цим пишається. Свій продукт після отриманого звіту вона не чіпала: «там дрібниці, полагодимо вдома». Що на це скаже регламент уроку?
Чек-лист потрібен не для бюрократії. Він робить аудит повторюваним: дві різні команди перевіряють однаково й порівнянно
Перші три пункти — про те, чи продукт узагалі живий і зрозумілий. Далі йдуть вісім технічних, і серед них усі блокуючі.
Останній, дванадцятий, перевіряє сам звіт. Аудит, який не оформлено, не зараховують: результату, якого ніхто не може прочитати, наче й немає.
Команда починає аудит із пункту 11, ліміту частоти. Вона шле 3000 запитів на форму цілі, «щоб одразу побачити найцікавіше». Сайт після цього перестає відповідати. Решту пунктів перевірити вже неможливо. Що тут порушено насамперед?
«У вас усе погано» — це не знахідка. Знахідка — це те, що чужа команда може відтворити, зрозуміти й полагодити без тебе
Формат тут один і той самий: і в школі, і в дорослих звітах. Полів чотири, і кожне відповідає на своє питання.
| Поле | Питання | Приклад |
|---|---|---|
check_id | який пункт чек-листа | env_hidden |
evidence | що знайшов і як відтворити | GET /.env → 200, у тілі рядок DB_PASS=…;
команда: curl -sS http://91.219.61.4/s/team-b3/.env | head -3 |
impact | чим це загрожує | пароль до бази доступний будь-кому в інтернеті без входу |
fix | як полагодити | винести .env вище за ~/www, додати правило
заборони для файлів, що починаються з крапки, змінити пароль |
evidence не зараховують — так прямо записано
в критеріях./feedback.php
приймає поле name довжиною 10 000 символів» — про систему.
Друге можна полагодити. На перше можна тільки образитися.У звіті написано: «форма відгуків небезпечна, перевірте її». Команда-адресат прочитала й нічого не зробила. Чия це проблема і що саме бракує в цьому реченні?
Відсутній SECURITY.md і відкритий .env
із паролем до бази — це не «дві знахідки». Це різні всесвіти
Щоб оцінити знахідку, дай відповідь на два питання. Перше: що отримає зловмисник, якщо скористається цією дірою. Друге: наскільки легко йому це зробити.
Відповіді складають у одне слово — серйозність знахідки. Ми беремо просту шкалу з п'яти рівнів. Саме за нею ти вибиратимеш серйозність в арені.
Правило черговості на сьогодні просте. Спершу всі блокуючі 🔒,
потім критичні й високі, а вже потім решта. Команда, яка почала
з дрібниць і не встигла закрити .env, модуль не закриє.
У цілі дві знахідки. Перша: у коді сторінки лежить робочий API-ключ
платного сервісу. Друга: на сайті немає файлу
SECURITY.md. Команда за дві хвилини виправила другу
і звітує про прогрес. Як це оцінити?
Тренувальна ціль 91.219.61.4/s/team-b3 — вигадана
й навмисно дірява. Тут ти проходиш увесь шлях знахідки, перш ніж
торкнутися справжньої адреси
Кожна картка — один пункт чек-листа. Кнопка «запустити» показує, що повернула б така перевірка: код відповіді й фрагмент виводу.
Далі шлях знахідки. Червону додаєш у звіт одним кліком. Обираєш серйозність за шкалою з кроку 5. Учитель підтверджує доказ, команда лагодить, а ти перезапускаєш перевірку. Табло рахує все це саме.
91.219.61.4/s/team-b3 · аудитор: твоя командаТабло оновлюється саме. «Час до виправлення» — середній по виправлених знахідках, від моменту подання у звіт.
Жодної знахідки ще не подано. Запусти перевірки вище.
Це симуляція: сторінка не робить жодного мережевого запиту.
Коди відповідей і фрагменти виводу — заздалегідь записані приклади того,
що видає справжня перевірка. На реальній цілі ті самі кроки ти виконуєш
у терміналі й вставляєш вивід у evidence власноруч.
.env, секрети, права й ліміт частоти. І лише
потім беруться за SECURITY.md.Перевірка «секрети» повернула рядок із живим ключем платного сервісу. Команда прибрала ключ із файлу, залила виправлену сторінку, перевірка позеленіла. Чого вона ще не зробила — і чому це найважливіше?
Одна й та сама знахідка може стати задачею на десять хвилин або сваркою на весь урок. Різниця — у трьох реченнях
Нижче три ситуації з арени. До кожної є чотири варіанти повідомлення команді-власнику. Обери той, який ти справді надіслав би. Після відповіді буде розбір усіх чотирьох.
Ти знайшов у цілі збережений XSS і хочеш переконатися, що команда поставиться серйозно. Який доказ у повідомленні працює найкраще?
Знайти діру — половина справи. Друга половина — розповісти про неї так, щоб її встигли закрити раніше, ніж нею скористаються
Про відповідальне розкриття ти вже читав на уроці 15. Нагадаємо коротко. Той, хто знайшов вразливість, спершу повідомляє власника й дає час на виправлення. Публічно говорить лише потім.
Друга половина домовленості — на власнику. Він за цей час лагодить. І не переслідує того, хто повідомив, а дякує йому.
SECURITY.md (у нас — команді
й учителю);Саме для цього в чек-листі є пункт SECURITY.md. Без цього
файлу людина, яка знайшла у вас діру, не знає, куди писати. І напише
або в загальний чат, або нікуди.
| Хто | Скільки часу дає до публікації |
|---|---|
| Google Project Zero | 90 днів + 14 днів на встановлення оновлення |
| CERT/CC (Carnegie Mellon) | 45 днів від повідомлення |
| Стандарт ISO/IEC 29147 | строк не фіксує — вимагає домовленості й каналу зв'язку |
| Наш урок | 30 хвилин етапу виправлення |
Ти знайшов у цілі відкритий .env із паролем. До кінця
етапу аудиту лишилося 20 хвилин, команда-власник сидить за сусідньою
партою. Який порядок дій відповідає правилам розкриття?
Вразливість небезпечна рівно стільки часу, скільки вона відкрита. Двадцять дірок, які лежать невиправленими тиждень, гірші за одну, закриту за годину. Вікно ризику міряють не кількістю, а часом.
Тому дорослі команди рахують не «скільки багів знайшли». Вони рахують час від повідомлення до виправлення. Це число видно на табло арени окремою колонкою. Воно й показує найчесніше, чи вміє команда тримати свій продукт.
Команда A знайшла 11 дірок у чужому продукті, а свої три отримані знахідки не закрила. Команда B знайшла 3, зате свої дві закрила за 12 і 18 хвилин і перезапустила перевірки. Хто ближчий до зарахованого модуля і чому?
Урок жорстко розкреслений за часом: аудит, обмін звітами, виправлення, повторний прогін, захист. Кожен етап має свій вихід
~/www, звідки беруться секрети;На захисті команда показує гарну презентацію, живе демо й архітектуру. Але на питання «що знайшли у вас і що ви виправили» відповідає: «нам прислали звіт, ми не встигли подивитися». Що з оцінкою?
Аудит і всі файли ти готуєш у себе на комп'ютері. По FTP у кабінет їде тільки текст. Галочки зберігаються
curl — це псевдонім
Invoke-WebRequest, тож у командах пиши curl.exe.
І зберігай JSON без BOM, інакше чекер не прочитає файл:
[IO.File]::WriteAllText($p, $t, (New-Object Text.UTF8Encoding $false)).
У Git Bash, macOS і Linux просто > audit-report.json.Скрипт учителя audit.sh проходить по твоєму
продукту й по твоєму звіту. Спроби не обмежені — перезапускай після
кожного виправлення
Демонстраційний режим: результат згенеровано для показу.
На сервері ця кнопка викликає POST /api/check, який запускає
/opt/lessons/16/audit.sh від імені учня.
audit-report.json: чи кожна знахідка має доказ,
який учитель може відтворити при ньому;FIXES.md: що знайшли у вас, що виправлено, о котрій
годині подано знахідку і о котрій закрито;Це те, що бачить учитель, коли виставляє оцінку за урок і закриває модуль
| Складник | Вага | Результат |
|---|
Порівняй два стовпчики нижче. Ліворуч — те, як ти працював у вересні. Праворуч — те, що ти робиш зараз, не задумуючись. Різниця в цій таблиці набиралася по одному уроку, і саме тому вона непомітна зсередини.
| Було в уроці 1 | Стало в уроці 16 |
|---|---|
| Пароль на всі сервіси один і той самий | Вхід на сервер за ключем ed25519, пароль на вході вимкнено |
| «Права доступу» — незрозумілі цифри у FTP-клієнті | 755 на теки, 644 на файли,
жодного o+w — і ти можеш пояснити чому |
| Ключ від API просто в коді сторінки | Ключ у .env поза веб-корінням, у .gitignore,
і ти вмієш його відкликати |
| Форма приймала будь-що, бо «на фронті ж є перевірка» | Валідація на сервері, екранування виводу, CSRF-токен, ліміт частоти |
| Персональні дані й чужі медіа клалися «щоб було» | Згода, походження файлів, ліцензії, жодних зайвих даних |
| Вебхук приймав подію від кого завгодно | HMAC-підпис, мітка часу, захист від повтору |
| Помилку в чужій роботі формулював як «тут усе погано» | Знахідка: check_id, severity,
evidence, fix |
| Про вразливість дізнавався випадково й від когось | Сам проходиш чек-лист із 12 пунктів і міряєш час до виправлення |
І остання річ, яку варто забрати з собою. Сьогодні у твоєму продукті знайшли помилки — і це нормально. Їх знаходять у всіх, у дорослих командах теж. Різниця тільки в тому, чи вмієш ти їх спокійно прийняти й закрити. Сьогодні ти це вмів.
evidence: немає ні коду відповіді,
ні фрагмента виводу — не зараховується;audit-report.json збережено в PowerShell із BOM —
чекер бачить невалідний JSON;~/www/ чи ~/upload/ лишилися відео
або файли понад 2 МБ — падає наскрізний критерій no_media.Напиши особистий підсумок модуля: три правила безпеки, які ти застосуєш до власних проєктів поза школою. До кожного додай одне речення. У ньому назви конкретний випадок із цих шістнадцяти уроків, який тебе в цьому переконав.
Другим абзацом візьми один свій старий проєкт або акаунт. Напиши, що саме ти перевіриш у ньому цього тижня за нашим чек-листом.
Усе, що можна перевірити, має посилання. Усе, що є ілюстративним прикладом, підписано прямо на сторінці
Referer.
cheatsheetseries.owasp.org.env і «ліміт частоти».
developer.mozilla.org · HTTP status429 Too Many Requests
і заголовка Retry-After.
rfc-editor.org/rfc/rfc6585Invoke-WebRequest —
чому curl там не справжній curl і потрібен
curl.exe.
learn.microsoft.com192.0.2.0/24,
198.51.100.0/24, 203.0.113.0/24 для документації.
Усі адреси на цій сторінці звідти, вони нічиї.
rfc-editor.org/rfc/rfc5737Повний список із поясненнями, що звідки взято і що є
ілюстративним прикладом, — у файлі urok-16-джерела.md
поруч із цією сторінкою.