Ну тут надо уже искать. я тогда в другой ветке это делал и ее всю схлопнул в один киммит. ну вот маленький пример из отчета
2. Information Disclosure — ExceptionMiddleware отдаёт тексты исключений клиенту (CRITICAL) Файл: src/Middleware/ExceptionMiddleware.php return $this->buildResponse($exception->getMessage()) ->setStatus(ResponseStatus::INTERNAL_SERVER_ERROR); Текст любого исключения (включая \Throwable) напрямую возвращается в HTTP-ответ. Это раскрывает: - Пути файловой системы (Unable to open '/var/www/app/var/log/error.log') - Имена таблиц/колонок БД из будущих SQL-ошибок - Внутренние имена классов и структуру приложения - Потенциально — строки подключения и учётные данные из PDO-исключений Комментарий в коде говорит «фильтрация — ответственность разработчика», но это должно быть безопасным по умолчанию. 3. CSRF-токен в GET-параметрах (HIGH) Файл: src/Middleware/CsrfMiddleware.php $tokenFromRequest = trim( $request->get->getString(self::CSRF_TOKEN_NAME, '') // ← GET параметр! ?: $request->post->getString(self::CSRF_TOKEN_NAME, '') ?: $request->headers->getString(self::CSRF_TOKEN_HEADER, ''), ); CSRF-токен принимается через GET-параметры. Это означает: - Токен попадёт в URL (?csrf_token=abc123...), а значит: - В логи веб-сервера (access.log) - В заголовок Referer при переходе по ссылкам - В историю браузера - В логи прокси-серверов - Это фактически обнуляет CSRF-защиту, так как токен может быть легко перехвачен 8. Ротация логов — гонка и перезапись (MEDIUM) Файл: src/Logging/Handlers/StreamHandler.php if (file_exists($stream) && filesize($stream) > $maxFileSize) { rename($stream, $stream . '.old'); // ← хранится только 1 архив } - Race condition: между file_exists/filesize и rename другой процесс может записать в файл - Хранится только один архивный файл (.old), предыдущий архив удаляется без предупреждения — потеря логов в production - Нет блокировки файла при записи (fwrite без flock) — возможна перемешивание строк логов при конкурентных запросах
Каким образом? С онлайн моделью?
Вот пример из сводки этого отчета
┌─────┬────────────────────────────────────────────┬──────────┬─────────────────────────────┐│ # │ Уязвимость │ Уровень │ Тип (OWASP) │├─────┼────────────────────────────────────────────┼──────────┼─────────────────────────────┤│ 1 │ XSS через HtmlResponse │ CRITICAL │ A03: Injection │├─────┼────────────────────────────────────────────┼──────────┼─────────────────────────────┤│ 2 │ Information Disclosure через тексты │ CRITICAL │ A01: Broken Access Control ││ │ исключений │ │ │
Скорее реальные: пару попались "спорных". т.е в моем понимании в универсальном фреймворке эти две должны решаться на другом уровне проекта, иначе фреймворк будет "резать крылья разработчикам" :) Пара была действительно критических - проморгал. Были такие, просто обусловлены тем, что еще идет разработка и я тупо еще не сделал.
Но тут нужно так же понимать, что цель видео была просто показать возможности (неизвестный фреймворк и его анализ), "отчет по уязвимостям" - конкретно такой задачи не было. т.е. если озадачится и даже, если быть точным, сформировать определенный "чек лист" с достаточно узкими задачами (и поиск уязвимостей как одна из таких). то вполне себе интересный и полезный инструмент. Так что если привычная пирамида тестирования, мутационное тестирование и прогон через ИИ - уменьшаем шанс прорыва бага на прод.
Таки с фреймворком тема все переключился на LLM?
