Business Logic: Подмена цены в форме

# Подмена цены при оформлении заказа ## Сценарий Вы — аудитор маркетплейса электроники **TradeNest**, приглашённый после инцидента в финансовом отделе: выручка за неделю не сошлась с суммой списаний, а в истории нашёлся дорогой товар, оплаченный символически. Корзина и оформление заказа выглядят защищёнными: авторизация, CSRF-токен, проверка баланса. Ваша задача — воспроизвести схему покупателя, ничем не повышая свой баланс и не подделывая товары. ## Цель 1. Изучите форму оформления заказа: какие поля уходят на сервер и какие из них сервер использует как финансовые. 2. Найдите параметр, которому обработчик доверяет при расчёте списания, и объясните, почему клиентскому значению нельзя верить. 3. Купите товар **CTF Flag**, не превысив стартовый баланс, и заберите флаг со страницы профиля. ## Теория Уязвимости бизнес-логики не ломают ни синтаксис запросов, ни разметку страниц — они ломают инвариант «цену определяет сервер». Классический сценарий: итог заказа приходит из формы готовым числом, и обработчик списывает его, не пересчитывая корзину по базе. Для атакующего форма — обычный текст запроса: скрытые поля видны и редактируемы в инструментах разработчика, и ничто не мешает отправить другое число. **Уязвимый паттерн:** ```go total, _ := strconv.Atoi(r.FormValue("total_price")) h.db.Exec("UPDATE users SET balance = ? WHERE id=?", user.Balance-total, user.ID) ``` Сервер доверяет полю итоговой суммы из запроса: списывается то, что прислал клиент, а не стоимость товаров в корзине. Скрытое поле с суммой — удобство интерфейса, а не гарантия: протокол HTTP не различает «значение из моего шаблона» и «значение, вписанное руками». ## Точка входа атаки `POST /cart/checkout` — оформление заказа (скрытое поле `total_price` в форме корзины). * **Учётные данные:** `demo` / `demo`, стартовый баланс — $500 * **Товар-цель:** **CTF Flag** за $9999 в каталоге * **Флаг:** появляется на странице профиля после покупки