"description":"В коде захардкожен GitHub token (GITHUB_TOKEN), несмотря на то, что он с замаскированными символами (ghp_xxx...).",
"impact":"Утечка токена позволяет злоумышленнику получить доступ к репозиториям и API GitHub от имени владельца токена, потенциально ведёт к компрометации инфраструктуры, откату или подмене кода, краже данных.",
"exploit_scenario":"Если этот файл попадёт в публичный репозиторий или логи (например, при отправке в Git), злоумышленник может скопировать токен и использовать его для аутентификации в GitHub API (например, через `curl -H 'Authorization: token ghp_...'`), получить доступ к приватным репозиториям, получить secret-базы, выкачать код, выполнить атаки через GitHub Actions.",
"recommendation":"Никогда не храните секреты в коде. Используйте переменные окружения (например, `os.getenv('GITHUB_TOKEN')`), secrets-менеджер (HashiCorp Vault, AWS Secrets Manager) или конфигурационные файлы с `.gitignore`. Старый токен немедленно отозвать в настройках GitHub.",
"title":"Command injection via user-controlled host parameter",
"description":"Параметр `host`, передаваемый в эндпоинт /admin/backup, напрямую подставляется в команду rsync через subprocess.run без валидации. Это позволяет выполнить произвольные команды на сервере через инъекцию аргументов.",
"impact":"Полный компрометация сервера: злоумышленник может выполнить произвольные команды с правами сервиса, выкачать данные, установить backdoor, выполнить внутреннюю снэйфинг-атаку.",
"exploit_scenario":"Злоумышленник вызывает POST /admin/backup с хостом вида: `; rm -rf / ; echo 'hacked' ||`. После подстановки в subprocess команда будет выполнена как: `rsync -avz /workspace/orders.py ; rm -rf / ; echo 'hacked' ||:/backup/`. Благодаря || и ; это приведёт к выполнению произвольной команды. Также возможна инъекция через опции rsync (например, `--rsync-path=;malicious`) или через SSH-опции (если SSH-хост — `user@host -oProxyCommand='cmd'`).",
"evidence":"[\"rsync\", \"-avz\", \"/workspace/orders.py\", f\"{host}:/backup/\"] — подстановка user-controlled строки напрямую в аргумент команды без экранирования и валидации.",
"recommendation":"Не использовать user input напрямую в команде. Валидировать host: проверить по белому списку доменов/IP, использовать regex `^[a-zA-Z0-9.-]+$` или IP-адреса, либо использовать `shlex.quote(host)` (но это не защитит от всех случаев, лучше белый список). Рассмотреть альтернативу — вызов через Python-библиотеку (fabric, paramiko), где можно явно передать параметры без shell.",
"title":"Missing authorization check for order ownership",
"description":"Все эндпоинты (/orders/{order_id}, /orders, /admin/backup) проверяют наличие токена авторизации, но не проверяют, что пользователь имеет право доступа к конкретному заказу (owner check).",
"impact":"IDOR (Insecure Direct Object Reference) — аутентифицированный пользователь может получить доступ к любым заказам, включая чужие, по известному order_id.",
"exploit_scenario":"Пользователь A создает заказ, получает order_id, и затем посылает GET /orders/{order_id} с любым аутентифицированным заголовком Authorization (в котором достаточно, чтобы токен был non-null), даже если он не владелец заказа (user_id не совпадает). Аналогично — он может изменить сумму чужого заказа через PUT /orders/{order_id}, если знает ID.",
"evidence":"get_order, update_order — проверяют только `if authorization is None`, но не проверяют, что `orders[order_id].user_id == authenticated_user_id`. В POST /orders — user_id передаётся, но не связывается с аутентифицированным пользователем (нет извлечения из токена).",
"recommendation":"Извлекать идентификатор пользователя из токена (например, JWT), валидировать его подпись и claim. Сравнивать `user_id` из запроса с `authenticated_user_id`. Для GET и PUT проверять, что `order.user_id == authenticated_user_id`.",
"title":"No role-based access control for /admin/backup endpoint",
"description":"Эндпоинт /admin/backup доступен любому, у кого есть валидный authorization токен — нет роли admin. Это позволяет обычным пользователям вызывать опасную операцию бэкапа, включающую подозрительный вызов rsync с внешним хостом.",
"impact":"Злоумышленник может использовать сервис как прокси для утечки данных или для внутренней репликации вредоносного контента, а также проводить SSRF через rsync (если rsync поддерживает специфичные схемы или настроен на взаимодействие с internal сервисами).",
"exploit_scenario":"Любой аутентифицированный пользователь (даже не admin) вызывает /admin/backup с подконтрольным хостом (например, `evil.com`), и сервер пытается скопировать `orders.py` на этот хост. Если rsync настроен на использование SSH с агентом или ключами, это может привести к утечке кода. Также, если злоумышленник может контролировать content `orders.py`, он может запланировать вредоносные данные.",
"evidence":"В /admin/backup нет проверки ролей или специального заголовка (например, X-Admin: true). Все функции использует только `if authorization is None`.",
"recommendation":"Добавить роль: извлекать claim 'role' или 'scopes' из токена, и явно проверять `if not is_admin(auth_user): raise HTTPException(403)`. Либо использовать специальный service token, передаваемый в другом заголовке.",
"title":"Potential SSRF via rsync to user-controlled host",
"description":"Эндпоинт позволяет задавать произвольный хост для rsync, и если rsync сконфигурирован с поддержкой SSH или других протоколов, это может привести к SSRF или утечке данных.",
"impact":"Если rsync использует SSH под капотом, а злоумышленник передаёт хост вроде `localhost`, `127.0.0.1`, `169.254.169.254` (AWS metadata), `internal.local`, это может привести к чтению метаданных инфраструктуры или закрытых сервисов.",
"exploit_scenario":"Вызвать POST /admin/backup с host=169.254.169.254 — если rsync поддерживает URL вида `rsync://...` или ssh-подобные параметры, это может привести к попытке считать metadata-данные. Аналогично, `user@internal-server:...` может привести к внутреннему пробингу, если используется SSH.",
"evidence":"subprocess.run([\"rsync\", \"-avz\", \"/workspace/orders.py\", f\"{host}:/backup/\"]) — host может быть подконтрольным и вредоносным (например, `127.0.0.1#-e/bin/sh -c ...`, если интерпретация команды не экранирована).",
"recommendation":"Блокировать внутренние IP (RFC1918), localhost, AWS metadata-адреса (169.254.169.254/32), домены внутри доверенного списка. Ограничить допустимые хосты (белый список доменов) и проверять host вручную перед вызовом subprocess.",
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.