AI-агенты и skimmer-атаки: checkout теперь нужно защищать как production-код

Проблема

В e-commerce больше нельзя считать skimmer-инцидент редкой ручной операцией. Когда агентные инструменты помогают быстро искать поверхность, выбирать путь доступа и повторно внедрять код после удаления, защита checkout должна быть устроена как защита production-критичного сервиса, а не как косметическая проверка JavaScript.

Что изменилось

Главный сдвиг не в том, что появилась «магическая AI-атака». Сдвиг в экономике: оператору уже не нужно вручную держать в голове десятки вариантов атаки. Агент может долго и методично перебирать маршруты: CMS, плагины, админ-панели, S3/CDN, cache layer, tag manager, базу данных, Kubernetes deployment или старый cron, который возвращает loader после чистки.

Для защитника это означает неприятную вещь: одно удаление подозрительного скрипта больше не доказывает завершение инцидента. Нужно понимать, откуда он появился, какие права были использованы и какой механизм может восстановить его снова.

Что проверить руками

• Все источники кода на checkout: локальные JS-файлы, tag manager, сторонние виджеты, CDN/S3 buckets, шаблоны CMS и database-backed snippets.
• Цепочку публикации фронтенда: кто может менять checkout, через какой CI/CD, с каким approval и какие логи остаются.
• Integrity-контроль: хэши критичных файлов, diff на tag manager export, immutable buckets, запрет произвольных inline-скриптов там, где это реально внедрить.
• Платежную архитектуру: желательно, чтобы сайт не видел номер карты целиком, а работал с hosted fields/tokenization от платежного провайдера.
• Recovery-план: restore checkout без проверки persistence и secret rotation не считается восстановлением доверия.

Defensive playbook

checkout_integrity:
  watch:
    - public/checkout/**/*.js
    - tag-manager/export.json
    - cdn-bucket/payment-assets/**
  block_if:
    - unsigned_change
    - new_external_domain
    - inline_script_without_owner
  incident_response:
    - preserve_html_and_js
    - rotate_admin_and_ci_tokens
    - compare_clean_baseline
    - retest_checkout_from_fresh_browser

Типичные ошибки

Самая частая ошибка — лечить симптом: удалить подозрительный script tag и закрыть задачу. Вторая — не различать маркетинговые теги и платежные теги. Третья — хранить checkout-логи слишком мало: через неделю уже невозможно доказать, был ли skimmer, какой домен он дергал и кто изменил asset.

Вывод

Checkout теперь нужно воспринимать как отдельный trust boundary. Хорошая защита начинается не с красивого WAF-правила, а с инвентаря источников кода, жесткого процесса изменений, контроля целостности, ограниченных секретов и проверенного восстановления.