[securitylab::pro]
// Безопасность / Веб

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

2026.08.23  //  Редакция  //  00:26
Как защитить интернет-магазин от взлома

Интернет-магазин теряет деньги двумя путями: от взлома сервера и от «логических» дыр в самой покупке, которые не видит ни один сканер. Второй путь коварнее, он не требует эксплойтов — только внимательного чтения бизнес-логики. И расплата бывает огромной: атака Magecart на British Airways (скиммер карт на сайте) стоила 380 000 карт клиентов и штрафа £20 млн. Ниже главные векторы предметно, а как защитить интернет-магазин целиком, проверяем на пентесте интернет-магазина.

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

Самая частая и дорогая ошибка — доверять цене, которую прислал клиент:

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

# атакующий меняет price ↓
{ "product_id": 501, "qty": 1, "price": 1 }        # флагман за 1 ₽

# или отрицательное количество ↓
{ "product_id": 501, "qty": -3, "price": 79990 }    # итог уходит в минус

Правило: цена и итог всегда пересчитываются на сервере из каталога, количество валидируется как положительное целое. Клиент передаёт только product_id и qty, но никогда цену.

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

  • Повторное применение одноразового кода, когда нет атомарной проверки использования.
  • Стекирование скидок, которые складываться не должны.
  • Промокод >100% в связке с дорогой доставкой даёт отрицательную сумму.
  • Race condition: 50 одновременных запросов применяют «одноразовый» код 50 раз, пока не сработает лимит.

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

3. Уязвимости оплаты и безопасность онлайн-платежей

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

Статус «оплачен» должен ставить только шлюз и только по проверенной подписи. Для платёжных данных действует отдельный стандарт, см. пентест по требованиям PCI DSS.

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

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

5. Платформа: скиммеры, плагины, админка

  • Magecart-скиммеры: вредоносный JS на странице оплаты крадёт карты, как это было у British Airways. Часто проникает через уязвимый плагин или сторонний скрипт.
  • Уязвимые плагины и темы CMS (Bitrix, WooCommerce) — см. пентест CMS.
  • XSS в отзывах и поиске, открытые админки, отладочные режимы, утечки в API каталога.

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

  1. Цена и итог считаются только на сервере, количество — положительное целое.
  2. Промокоды применяются атомарно в транзакции; защита от гонок на кодах, остатках, балансе.
  3. Платёжные webhook проверяются по подписи и сумме, статус «оплачен» ставит только шлюз.
  4. Проверка владельца на всех операциях с заказами (анти-IDOR).
  5. Контроль сторонних скриптов на странице оплаты (SRI, CSP) против Magecart.
  6. CMS, тема и плагины обновлены, админка под 2FA, отладка выключена.
  7. Пентест за 3–4 недели до «чёрной пятницы»: в пик атакующие ищут именно логику скидок и оплаты.

Ваш магазин теряет деньги на уязвимостях?

Пройдём весь путь покупателя как злоумышленник — покажем, где можно купить за рубль, применить промокод дважды, поймать гонку на остатках или увести карты клиентов.

Пентест интернет-магазина →

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

Профильные услуги SecurityLab: тестирование на проникновение · пентест веб-приложений · Пентест CMS.

← назад в блог