Тест OpenAI Daybreak Blue: реальна знахідка щодо безпеки вебсайту
Мій тест OpenAI Daybreak Blue виявив проблему безпеки на моєму власному робочому вебсайті, яку я зміг відтворити у новому браузері: сторінка входу залишалася на HTTP замість перенаправлення на HTTPS. Сторінка також завантажувала 20 ресурсів першої сторони через те саме незашифроване з’єднання.
Цей результат був корисним із простої причини. Моделі не знадобився екзотичний експлойт, щоб виявити значущу проблему. Вона ідентифікувала базову помилку транспорту, оцінила її та надала конкретне твердження для перевірки. Незалежний базовий тест виявив ту саму основну проблему.
Це була авторизована, неруйнівна оцінка Mixanalytic — сервісу, яким я володію. Я не надсилав облікові дані, не входив у систему, не експлуатував сайт, не змінював дані й не намагався закріпитися в системі.
Чому я тестував Daybreak Blue на реальному вебсайті
Демонстрації моделей безпеки часто використовують підготовлені зразки коду або відомі вразливі лабораторні середовища. Такі тести контрольовані, але вони не показують, як модель працює зі звичайною робочою системою з неповним контекстом.
Я хотів провести вужчий тест із чіткою умовою успіху: чи зможе модель перевірити публічну поверхню сайту, яким я володію, знайти відтворювану проблему та відокремити докази від припущень?
Я також хотів порівняти її результат із незалежним базовим тестом. Я тестував інші AI-системи за подібним підходом, орієнтованим на докази, у моєму тесті безпеки AI-чатбота→, де корисним результатом стала перевірена інженерна зміна, а не драматична історія атаки.
Яку модель я насправді запускав?
Початкова оцінка виконувалася в окремому працівнику Codex, якому було призначено ідентифікатор моделі `gpt-daybreak-blue-latest`. У документації OpenAI схвалену пропозицію названо GPT-Daybreak-Blue.
Ця відмінність важлива. Зміна моделі, вибраної для пізнішого чату, не перетворює заднім числом попередній запуск на тест Daybreak. Виконання, яке проводить оцінку, має використовувати схвалену модель Daybreak і відповідну продуктову поверхню.
OpenAI описує Daybreak Blue як відправну точку для більшості авторизованих захисних завдань, зокрема виявлення вразливостей, безпечного аналізу коду, моделювання загроз, розробки засобів виявлення, реагування на інциденти та перевірки виправлень. Компанія також рекомендує контрольовані середовища, дозволи з найменшими привілеями, визначену область перевірки та людський контроль для чутливих дій (Models and Trusted Access).
Налаштування та область тесту OpenAI Daybreak Blue
Я надав моделі дозвіл перевіряти Mixanalytic і локальні файли проєкту. Зовнішні перевірки я обмежив неруйнівними діями:
Моделі не дозволялося надсилати форму входу, перевіряти реальні облікові дані, створювати облікові записи, завантажувати payload-и, експлуатувати підозрювану слабкість або змінювати робоче середовище.
Ця межа спростила інтерпретацію результату. Кожна знахідка мала походити з публічної поведінки або доказів у коді, доступних лише для читання.
Основна знахідка: сторінка входу залишалася на HTTP
Перевірка методом black-box показала, що і коренева адреса сайту, і маршрут входу повертали `200 OK` через HTTP. Жодна з відповідей не перенаправляла браузер на HTTPS.
Потім я відкрив сторінку входу в новому контексті Chromium. Браузер залишався на URL `http://`, відображаючи поля імені користувача та пароля. Під час завантаження сторінки 20 запитів до JavaScript, CSS, зображень і документів першої сторони також використовували HTTP.
| Перевірка | Спостережуваний результат |
|---|---|
| --- | --- |
| Перенаправлення HTTP | На перевірених кореневій сторінці та сторінці входу перенаправлення на HTTPS не було |
| Новий браузер | Chromium залишився на сторінці входу через HTTP |
| Ресурси першої сторони | Під час цього запуску браузера через HTTP завантажилося 20 запитів |
| Cookie анонімної сесії | `Secure=false`, `HttpOnly=true`, `SameSite=Lax` |
Результат із cookie потребує контексту. `HttpOnly` і `SameSite=Lax` були позитивними атрибутами, але відсутність прапорця `Secure` дозволяла передавати cookie анонімної сесії через незашифроване з’єднання.
Після браузерної перевірки я оцінив проблему транспорту як високоризикову. Зловмисник, який перебуває на мережевому шляху, міг би спостерігати або змінювати HTTP-трафік. Якби користувач надіслав облікові дані на цій сторінці, незашифроване з’єднання могло б їх розкрити. Я не знайшов доказів того, що хтось викрав облікові дані, і не надсилав їх під час тесту.
Перевірка в браузері змінила оцінку серйозності
Початковий незалежний базовий тест класифікував поведінку HTTP як проблему середньої серйозності. Ця оцінка змінилася після того, як перевірка під час виконання показала, що справжня форма пароля залишається на HTTP, а її допоміжні ресурси також завантажуються через HTTP.
Ця зміна більше говорить про метод тестування, ніж про моделі. Перевірка заголовків виявила проблему конфігурації. Докази з браузера встановили, як із нею зіткнувся б відвідувач. Додаткові докази зробили вплив достатньо конкретним, щоб обґрунтувати вищий пріоритет.
Daybreak Blue дійшла того самого основного висновку. Обидва запуски скористалися одним правилом: знахідка має містити відтворюване спостереження, обмежене твердження про вплив і чіткий перелік дій, які не виконувалися.
Що показали додаткові перевірки
Оцінка також виявила кілька результатів нижчого пріоритету.
Сучасні версії TLS працювали
Перевірений хост відхиляв TLS 1.0 і 1.1, приймаючи TLS 1.2 і 1.3. Це позитивний результат для HTTPS endpoint. Однак він не компенсує того, що процес входу дозволено залишати на HTTP.
Content Security Policy дозволяла inline-код
Спостережувана Content Security Policy містила `'unsafe-inline'` для скриптів і стилів. Я розцінив це як прогалину в hardening, а не як доказ вразливості cross-site scripting. Видалення дозволів для inline-коду зазвичай потребує змін у застосунку та регресійного тестування, тому це має виконуватися після виправлення транспорту.
На сайті не було `security.txt`
Стандартний шлях `/.well-known/security.txt` повертав `404`. Я класифікував це як інформаційний результат. Файл із контактами безпеки надає дослідникам зрозумілий канал для повідомлень, але його відсутність не створює експлуатованої вразливості.
Перевірений CORS preflight не дозволив зовнішній origin
Один preflight-запит із непов’язаного origin не отримав дозволу на доступ до перевіреного публічного маршруту. Це корисний негативний результат, обмежений endpoint і preflight, які я перевірив. Це не повний аудит CORS сайту.
Чи перевершив Daybreak Blue базову модель?
Цей тест не дає підстав для загального рейтингу моделей. Daybreak Blue та незалежний базовий тест виявили проблему транспорту. Оцінка серйозності базового тесту покращилася, коли я додав докази з браузера.
Daybreak Blue була цінною, оскільки зосередилася на авторизованому захисному завданні та створила знахідку, яку я міг перевірити. Один вебсайт, одна область перевірки та одна дата тестування не можуть встановити, що вона перевершить іншу модель у перевірці коду, реагуванні на інциденти, аналізі malware або масштабніших penetration tests.
Сильніший benchmark мав би повторювати ті самі приховані тестові випадки в кількох застосунках, якими ми володіємо, надавати кожній моделі однакові інструменти й часовий бюджет та оцінювати відтворюваність, false positives, пропущені знахідки, калібрування серйозності й якість виправлення.
Я використовую ширший метод оцінювання в Як проводити benchmark AI-моделей для реальної роботи→. Цей запуск Daybreak — один польовий звіт, а не повний benchmark.
Як отримати OpenAI Daybreak Blue?
Доступ до Daybreak потребує схвалення через програму OpenAI Trusted Access for Cyber. Фізичні особи можуть подати заявку через індивідуальну заявку Trusted Access, а організації можуть скористатися формою запиту для підприємств.
Схвалення прив’язане до схваленої особи або сервісу, робочого простору або API-організації та проєкту, моделі й продуктової поверхні. Завершення перевірки особи або надсилання форми не гарантує доступу. Daybreak Red також потребує окремого схвалення; доступ до Blue не включає його автоматично.
Ширший робочий процес Daybreak від OpenAI поєднує розслідування, перевірку репозиторію, докази, запропоновані виправлення та людську перевірку. Власні рекомендації OpenAI залишають інженера відповідальним за наслідкові зміни (Scaling cyber defenders with Daybreak).
Джерела та запис тесту
Я виконав авторизовані перевірки 30 серпня 2026 року. Спостереження щодо браузера, заголовків, cookie, TLS, CSP, `security.txt` і CORS у цій статті походять із запису цього тесту.
Твердження щодо моделі та доступу походять із двох основних джерел OpenAI:
Згідно з рекомендаціями OpenAI щодо доступу, схвалення залишається специфічним для особи, робочого простору або API-проєкту, моделі та продуктової поверхні. Результати мого тесту не виходять за межі описаної вище області Mixanalytic.
Що я виправив би та перевірив повторно далі
Для знахідки щодо транспорту є короткий порядок пріоритетів:
Повторний тест має завершитися невдачею, якщо будь-яка сторінка входу, form action, ресурс першої сторони або session cookie повертається до HTTP. Я також повторно запустив би оцінки Daybreak і базової моделі проти виправленої версії, щоб перевірити, чи розпізнають вони виправлення та чи не повторюють ту саму знахідку.
Перший тест дав корисний результат, не виходячи за межі авторизації. Daybreak Blue виявила реальну ваду. Незалежні докази з браузера показали, чому вона заслуговує на увагу. Наступне достовірне твердження полягає не в тому, що інструмент одного разу спрацював, а в тому, що виправлення витримує той самий тест.
---