Как защитить интернет-магазин от взлома: чек-лист

Интернет-магазин теряет деньги двумя путями: от взлома сервера — и от «логических» дыр в самом процессе покупки, которые не видит ни один сканер. Второй путь опаснее: он не требует эксплойтов, только внимательного чтения бизнес-логики. По данным индустрии, до 50% критичных уязвимостей e-commerce — это ошибки логики (цены, скидки, оплата, заказы), а не классический OWASP. Разбираем главные векторы и даём чек-лист. Полную проверку проводим на пентесте интернет-магазина.

1. Манипуляция ценой и корзиной

Самая частая и дорогая ошибка — доверять цене, пришедшей от клиента. Если сумма считается на фронтенде и передаётся в заказ, её можно подменить:

POST /api/cart/add
{ "product_id": 501, "qty": 1, "price": 79990 }

--- атакующий меняет price ---
{ "product_id": 501, "qty": 1, "price": 1 }   // купил флагман за 1 рубль

Сюда же — отрицательное количество (qty: -3), которое в кривой логике уменьшает сумму заказа или даже начисляет возврат. Правило: цена и итог всегда пересчитываются на сервере из каталога, количество валидируется как положительное целое.

2. Злоупотребление промокодами и скидками

• Повторное применение одноразового кода (нет атомарной проверки использования).
• Стекирование нескольких скидок, которые не должны складываться.
• Промокод на 100%+ в сочетании с дорогой доставкой = отрицательная сумма.
• Race condition: одновременная отправка кода в 50 потоков применяет его 50 раз до того, как сработает лимит.

Race condition (состояние гонки) на промокодах и остатках товара — наша частая находка. Пример: товар «1 шт в наличии», но 100 одновременных запросов «оформить» проходят все, потому что проверка остатка и списание не в одной транзакции. Магазин продаёт то, чего нет, и уходит в минус по возвратам.

3. Уязвимости оплаты

Платёжная логика — зона повышенного риска. Что проверяем:

• Подмену статуса заказа на «оплачен» без реального платежа (манипуляция callback от платёжного шлюза).
• Отсутствие проверки суммы и подписи в webhook платёжной системы.
• Возможность оформить заказ, отменить оплату, но сохранить товар/доступ.
• Валюта: оплата в валюте с курсом, выгодным атакующему.

Для платёжных данных отдельно применяется стандарт — см. пентест по требованиям PCI DSS.

4. Доступ к чужим заказам (IDOR)

Классика e-commerce: /order/1042 → меняем id → чужой заказ с ФИО, адресом, телефоном и составом покупки. Массовый перебор выкачивает базу клиентов целиком. Подробный разбор — в статье IDOR на практике.

5. Классические уязвимости и платформа

• Инъекции и XSS в отзывах, поиске, оформлении.
• Уязвимые плагины и темы CMS (Bitrix, WooCommerce) — см. пентест CMS.
• Открытые админки, отладочные режимы, утечки в API каталога.

Чек-лист безопасности интернет-магазина

1. Цена и итог считаются только на сервере; количество — положительное целое.
2. Промокоды применяются атомарно, с проверкой лимита в транзакции; защита от гонок.
3. Платёжные webhook проверяются по подписи и сумме; статус «оплачен» ставит только шлюз.
4. Проверка владельца на всех операциях с заказами (антиIDOR).
5. HTTPS везде, HttpOnly/Secure на сессии, защита от перебора на входе и промокодах.
6. CMS, тема и плагины обновлены; админка под 2FA; отладка выключена.
7. Регулярный пентест перед крупными распродажами (нагрузка = окно для атак).

Практический совет: планируйте пентест магазина за 3–4 недели до «чёрной пятницы». В пик распродаж атакующие ищут именно логические дыры в скидках и оплате, а цена ошибки максимальна.

Читайте также: IDOR на практике, Пентест CMS.