Добавлен модуль учёта заказов клиентов #5

сценарий: Если этот файл попадёт в публичный репозиторий или логи (например, при отправке в Git), злоумышленник может скопировать токен и использовать его для аутентификации в GitHub API (например, через curl -H 'Authorization: token ghp_...'), получить доступ к приватным репозиториям, получить secret-базы, выкачать код, выполнить атаки через GitHub Actions.

HIGH (1.00) orders.py:84 — Command injection via user-controlled host parameter

сценарий: Злоумышленник вызывает 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').

MEDIUM (1.00) orders.py:69 — Missing authorization check for order ownership

сценарий: Пользователь A создает заказ, получает order_id, и затем посылает GET /orders/{order_id} с любым аутентифицированным заголовком Authorization (в котором достаточно, чтобы токен был non-null), даже если он не владелец заказа (user_id не совпадает). Аналогично — он может изменить сумму чужого заказа через PUT /orders/{order_id}, если знает ID.

MEDIUM (1.00) orders.py:83 — No role-based access control for /admin/backup endpoint

сценарий: Любой аутентифицированный пользователь (даже не admin) вызывает /admin/backup с подконтрольным хостом (например, evil.com), и сервер пытается скопировать orders.py на этот хост. Если rsync настроен на использование SSH с агентом или ключами, это может привести к утечке кода. Также, если злоумышленник может контролировать content orders.py, он может запланировать вредоносные данные.

MEDIUM (0.50) orders.py:89 — Potential SSRF via rsync to user-controlled host

сценарий: Вызвать POST /admin/backup с host=169.254.169.254 — если rsync поддерживает URL вида rsync://... или ssh-подобные параметры, это может привести к попытке считать metadata-данные. Аналогично, user@internal-server:... может привести к внутреннему пробингу, если используется SSH.

Полный список: security-analysis/findings/pr-5/1787496475-review.json

🔴 Merge заблокирован — есть находки выше порога security-analysis/policy.yml.

## AI Security Review (Level 1) - **CRITICAL**: 1 - **HIGH**: 1 - **MEDIUM**: 3 **CRITICAL** (`1.00`) `orders.py:12` — Hardcoded GitHub personal access token сценарий: Если этот файл попадёт в публичный репозиторий или логи (например, при отправке в Git), злоумышленник может скопировать токен и использовать его для аутентификации в GitHub API (например, через `curl -H 'Authorization: token ghp_...'`), получить доступ к приватным репозиториям, получить secret-базы, выкачать код, выполнить атаки через GitHub Actions. **HIGH** (`1.00`) `orders.py:84` — Command injection via user-controlled host parameter сценарий: Злоумышленник вызывает 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'`). **MEDIUM** (`1.00`) `orders.py:69` — Missing authorization check for order ownership сценарий: Пользователь A создает заказ, получает order_id, и затем посылает GET /orders/{order_id} с любым аутентифицированным заголовком Authorization (в котором достаточно, чтобы токен был non-null), даже если он не владелец заказа (user_id не совпадает). Аналогично — он может изменить сумму чужого заказа через PUT /orders/{order_id}, если знает ID. **MEDIUM** (`1.00`) `orders.py:83` — No role-based access control for /admin/backup endpoint сценарий: Любой аутентифицированный пользователь (даже не admin) вызывает /admin/backup с подконтрольным хостом (например, `evil.com`), и сервер пытается скопировать `orders.py` на этот хост. Если rsync настроен на использование SSH с агентом или ключами, это может привести к утечке кода. Также, если злоумышленник может контролировать content `orders.py`, он может запланировать вредоносные данные. **MEDIUM** (`0.50`) `orders.py:89` — Potential SSRF via rsync to user-controlled host сценарий: Вызвать POST /admin/backup с host=169.254.169.254 — если rsync поддерживает URL вида `rsync://...` или ssh-подобные параметры, это может привести к попытке считать metadata-данные. Аналогично, `user@internal-server:...` может привести к внутреннему пробингу, если используется SSH. Полный список: `security-analysis/findings/pr-5/1787496475-review.json` 🔴 **Merge заблокирован** — есть находки выше порога `security-analysis/policy.yml`.

playground-security-bot referenced this issue from a commit

2026-08-23 14:47:58 +00:00

security: AI review results for PR #5

playground-security-bot added 1 commit 2026-08-23 14:47:58 +00:00

security: AI review results for PR #5

security / scan (pull_request) Skipped

Details

security / review (pull_request) Skipped

Details

security / deep-audit (pull_request) Skipped

Details

67d3eef3c6

testclient-admin closed this pull request

2026-08-23 14:50:50 +00:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: i.kologriv/playground#5