Лучшие практики защиты e-commerce сайтов



    Интернет-магазины всегда привлекали злоумышленников: это и источник данных кредитных карт (сейчас практически неактуальный); пользовательских данных; данных о заказах и рыночных трендах (покупательском спросе); источник трафика; манипуляция со скидочными купонами и т.д. E-commerce сайт может быть атакован как злоумышленниками в «свободной охоте» (нецелевая атака), так и по заказу недобросовестных конкурентов. В последнее время популярны разного рода DoS/DDoS атаки, как для вывода конкурента из строя, так и в виде инструмента для шантажа.

    В этом топике я опишу лучшие практики по защите e-commerce сайтов.

    Основные векторы атаки


    Векторов атаки на веб-приложение довольно много, условно их можно разделить на прямые и косвенные.

    Прямые — когда атака направлена на веб-приложение:
    • Эксплуатация веб-уязвимостей (CMS, плагины, темы, модули, служебные скрипты).
    • Брутфорс форм авторизации (админ-панели, пользовательские данные).
    • DDoS/DoS/full browser stack.
    • Разного рода fraud операции, race condition и т.д.

    Косвенные — когда для атаки на интернет-магазин используются смежные сервисы:
    • Эксплуатация уязвимостей веб-сервера.
    • Брутфорс служебных сервисов (ftp/ssh).
    • Кража учетных данных технического персонала (трояны, перехват в WiFi сетях, социальная инженерия).
    • Кража учетных данных подрядных организаций персонала — веб-студии, контент-менеджеров, seo-специалистов, технической поддержки (трояны, перехват в WiFi сетях, социальная инженерия).
    • Выявление уязвимостей в смежной инфраструктуре (например, через «соседей» на хостинге при неверно выставленных правах).
    • Взлом хостинг-провайдера (редкий случай, но и такое встречается).


    Хостинг


    В первую очередь необходимо выбрать надежного хостинг-провайдера. Многие ведущие игроки рынка имеют специализированные предложения для интернет-магазинов. Важно чтобы ваш хостинг-провайдер поддерживал регулярное резервное копирование; вел всесторонние журналы действий; выполнял мониторинг сетевой активности. Также одним из важных факторов является система уведомлений об аномальных действиях на аккаунте, возможном заражении сайта и т.д. Техническая поддержка (обычно в рамках тарифа) должна уведомить о нарушении и снабдить хотя бы минимальными инструкциями (или ссылкой на базу знаний) о методах решения возникшей проблемы и содействовать в ее решении. Оптимальным решением будет использование VPS/VDS-хостинга.

    CMS


    По возможности используйте безопасную e-commerce платформу. Она должна поддерживать сложную систему аутентификации (2F, OTP и т.д.), возможность ограничения административной зоны и т.д.

    Сама CMS, ее плагины, модули и т.д. должны быть актуальных версий. Оптимальный вариант CMS — возможность автообновления (особенно это касается критичных уязвимостей). Немаловажным фактором должно стать нативное использование WAF/детектора аномалий/блокировщика атак из коробки, либо дополнительным модулем или плагином.

    Дополнительным плюсом будет использование в CMS разного рода механизмов проверки и санитайзинга данных, фреймворков или библиотек типа HTML Purifier.

    SSL/TLS


    Используйте защищенное соединение — шифруйте канал связи между сайтом и браузером клиента для передачи информации. В наше время актуальным является использование TLS (Transport Layer Security — безопасность транспортного уровня), который по привычке многие до сих пор называют SSL (Secure Sockets Layer — уровень защищённых сокетов).

    Важно использовать последние (актуальные) версии криптографических протоколов для надлежащей защиты данных.

    Отличной практикой будет использование HSTS (HTTP Strict-Transport-Security) — механизм, активирующий форсированное защищённое соединение по HTTPS. Данная политика безопасности позволяет сразу же устанавливать безопасное соединение, вместо использования HTTP. Механизм использует особый заголовок HTTP Strict-Transport-Security, для переключения пользователя, зашедшего по HTTP, на HTTPS-сервер.

    Данные


    Не храните критичные данные. Никаких CVV кодов, сейчас не начало нулевых. Более того, стандарт PCI DSS это прямо запрещает: такие элементы как CVV2 (Card Verification Value 2 — код проверки подлинности карты платёжной системы Visa) и CVC2 (аналогичный код платежной системы MasterCard) относятся к критичным аутентификационным данным, а значит не подлежат хранению.

    Если что-то приходится хранить — минимизируйте объем хранимых данных и по возможности применяйте шифрование. Это касается, в основном, обработки ПДн общей категории — ФИО, адрес, заказ и т.д.

    Парольная политика


    Требуйте использование надежных паролей — цифро-буквенные комбинации различного регистра, использование спецсимволов, ограничение минимальной длины пароля. Таким образом и клиент будет более надежно защищен от действий злоумышленников. Зачастую вопрос юзабилити (конверсии, отказов) ставится во главу угла и позволяет пользователям использовать любые пароли — это является плохой практикой, необходимо использовать сложные комбинации для защиты пользовательских данных.

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

    После проведения подрядных работ необходимо удалять неиспользуемые учетные записи. Также необходимо менять пароли после увольнения ключевых сотрудников.

    Антифрод


    Использование системы предупреждений и оповещений о подозрительной активности — множество операций с одного IP, смена реквизитов доставки и множество других факторов, обычно узкоспециализированных в той или иной сфере онлайн торговли. Здесь же может применяться холд/проверка чистоты сделки и прочее.

    Хорошей практикой будет использование 3-D Secure, MasterCard SecureCode, J/Secure и SafeKey. За рубежом зачастую иcпользуется система AVS (Address Verification System).

    Защитные механизмы


    Хорошим решением будет превентивное использование AntiDDoS, IDS, IPS и WAF механизмов для защиты от использования уязвимостей сетевой архитектуры, сервисов и приложений.

    Эти системы способны выявить и предотвратить большинство детектируемых (сигнатурных) атак, но панацеей не являются. Необходим комплекс мер и аналитическая работа по анализу аномалий/детекту вредоносной активности.

    Немаловажным фактом является грамотная и кастомизированная настройка этих систем.

    PCI DSS


    Следование требованиям стандарта PCI DSS и регламентные проверки.

    PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности данных индустрии платежных карт. Стандарт разработан международными платежными системами Visa и MasterCard. Любая организация, планирующая принимать и обрабатывать данные банковских карт на своем сайте, должна соответствовать требованиям PCI DSS

    Стандарт представляет собой совокупность 12 детализированных требований по обеспечению безопасности данных о держателях платёжных карт, которые передаются, хранятся и обрабатываются в информационных инфраструктурах организаций. Принятие соответствующих мер по обеспечению соответствия требованиям стандарта подразумевает комплексный подход к обеспечению информационной безопасности данных платёжных карт.

    Аудит безопасности


    Интернет-магазин, как основной инструмент торговли, должен стабильно и бесперебойно работать. Обеспечить данные условия возможно только уделяя надлежащее внимание безопасности ресурса, а именно такой процедуре, как аудит безопасности сайта.

    Регламентная процедура (например, раз в квартал) проведения аудита безопасности информационной системы позволяет оценить зрелость системы управления ИБ и выявить уязвимости для их оперативного устранения. Один из основных этапов — проведение внешнего Blackbox тестирования на проникновение.

    Комплексный аудит безопасности сайта необходим для выполнения требований 6.3, 6.5, 6.6, 11.3.2 стандарта PCI DSS.

    К компаниям, работающим только с платёжным шлюзом и не принимающих на своем данных банковских карт клиентов, относятся только требования департамента рисков платежного шлюза (ПЦ) и требования к проведению аудита не такие жесткие, как в стандарте PCI DSS, но и в этом случае необходимо проводить работы по выявлению возможных уязвимостей e-commerce сайта.

    Патч менеджмент


    Необходимо поддерживать актуальность используемых компонентов информационной системы — как версии CMS и ее составляющих, так и всего остального — версии серверной ОС и модулей и т.д.

    Важность обновлений и их своевременной установки очевидна для поддержания надлежащего уровня информационной безопасности.

    Хорошей практикой будет тестирование обновлений в dev-среде, перед обновлением продакшена, некоторые обновления могут содержать или вносить ошибки, в том числе содержащие критичные уязвимости.

    Резервное копирование


    Важными параметрами являются схема резервного копирования и планирование. Необходимо проводить регулярное резервное копирование, как инкрементного, так и дифференциального типа. Периодически проверять актуальность и работоспособность текущих резервных копий, обеспечивать их надежное и безопасное хранение, вне контура резервируемого объекта.

    Осведомленность персонала


    Необходимо проводить инструктаж персонала и подрядчиков по существующим угрозам ИБ. Одним из важным факторов будет объяснение основных социо-технических векторов атаки и приемов манипулирования.

    Заключение


    Безопасность ресурса — это непрерывный процесс, позволяющий защитить e-commerce от большинства существующих угроз, включающий в себя следующие действия:
    • аудит безопасности сайта и мониторинг;
    • немедленная реакция на выявленные проблемы и их фиксация;
    • проверка устранения выявленных проблем;
    • проведение регламентных работ.

    Только при комплексном подходе к безопасности ресурса ваши клиенты и их данные будут находится в безопасности, сведя на минимум вероятность компрометации ресурса и возникшие вследствие этого финансовые и репутационные риски.
    • +11
    • 14.1k
    • 6
    Pentestit
    56.29
    Информационная безопасность
    Support the author
    Share post

    Comments 6

      +1
      Ну по полочкам-то все верно. Но от:

      Требуйте использование надежных паролей — цифро-буквенные комбинации различного регистра, использование спецсимволов, ограничение минимальной длины пароля.


      ломает нещадно. Хочется верить, что перейдем на одноразовые пароли по смс и все упроститься.
        0
        Зачастую вопрос юзабилити (конверсии, отказов) ставится во главу угла и позволяет пользователям использовать любые пароли — это является плохой практикой, необходимо использовать сложные комбинации для защиты пользовательских данных.

        А что для интернет-магазина важнее — конверсия или стойкие пароли клиентов? И почему мы до сих пор говорим о паролях, как основном объекте интереса безопасника, хотя уже несколько лет как в качестве альтернативы можно «прозрачно» аутентифицироваться и через VK/Facebook/Google и т.п.?

        При обороте интернет-магазина выше определенной планки недополученная выгода при усложнении процедуры регистрации клиента или входа в личный кабинет оказывается больше, чем возможные прямые потери и косвенные затраты (WAF, доработки сайта, и даже зарплата безопасника) при реализации упомянутых мер защиты. Это ж как в супермаркетах — в цену товара закладывается допустимый процент потерь.
          0
          И никто не мешает при повторных попытках ввода пароля требовать капчу/сброса пароля через email.
            0
            Так что же автор рекомендует по обновлениям: автоматическую установку или тестирование в dev среде?
            Если первое, то можно всё положить,
              0
              скорее тестирование автоапдейтов на стейджинге. хотя многое зависит от степени кастомизации CMS и уровня покрытия автоматическими тестами. если кастомизация велика и/или покрытие тестами мало — только через дев-стейджинг в лайв
              +1
              Автор, определитесь, что же вы советуете по обновлениям CMS: устанавливать автоматически или все-таки тестировать в dev среде?

              Only users with full accounts can post comments. Log in, please.