В данной статье я хочу рассказать про то, как технически устроены бот-атаки типа парсинг цен на e-commerce сайтах, какие механизмы используют атакующие, как противостоять бот-атакам самостоятельно и с помощью прикладных решений.
Я поделюсь практическим опытом нашей компании в защите e-commerce приложений и продемонстрирую реальные кейсы противодействия парсинга и бот-атакам.
Практика парсинга цен в современном e-commerce
В рамках статьи мы сосредоточимся на атаках, которые относятся к типу Scraping по классификации OWASP. Детальную классификацию автоматизированных угроз веб-приложениям можно изучить в документе OWASP Automated Threats to Web Applications. Конечно, противодействие бот-атакам данного типа позволит остановить и другие автоматизированные атаки, но в нашей практике мы видим, в основном, именно атаки типа price scraping – автоматизированный сбор информации о товарах и ценах, или парсинг цен.
Я не рассматриваю юридические и морально-этические вопросы парсинга цен в данной статье. Как мы видим, в ритейле и e-commerce, маркетинговый посыл предоставления “лучшей цены” является широко распространённым.
Делать такой анализ цен вручную для ассортимента в тысячи или десятки тысяч товаров не представляется возможным, поэтому я уверенно могу заявить, что практика парсинга цен в российском ритейле и e-commerce существует, применяется, и даже появился отдельный рынок услуг для парсинга.
Упрощенная классификация заказчиков и исполнителей парсинга цен
Прежде чем говорить об инструментах, давайте посмотрим на самих атакующих и их профиль – мотивацию, цели и доступные ресурсы.
Скрипт-кидди и школьники. Мотивация – поиск личной выгоды, например, поймать лучшую цену, забронировать дефицитный товар и так далее. Доступные ресурсы минимальные, часто это технически простейшие способы парсинга.
Невредоносные боты-парсеры, такие как новые и нишевые поисковые движки, инструменты анализа эффективности онлайн-маркетинга и так далее. Например, в ходе одного из проектов в области фуд-ритейла мы обнаружили следы активности специализированного поискового сервиса, который собирает и анализирует цены на вино.
Мотивация коммерческая, но такие акторы не будут идти на явные атаки, явные обходы систем защиты. Скорее, они используют базовые методы парсинга, не скрывают себя и не обходят системы защиты целенаправленно. Могут соблюдать robots.txt, а могут и нет.
Допускать таких клиентов на сайт или нет - решает владелец e-commerce ресурсы, часто такой парсинг цен - это полезный симбиоз, а не атака.
Профессиональные сборщики коммерческой информации.
Самая интересная категория, используют все доступные техники парсинга, маскировки и заметания следов, от сложных до самых продвинутых.
Заказчики таких атак — это конкуренты по рынку/сегменту.
Атака проводится либо силами самой компании-конкурента, либо руками компаний, предлагающих профессиональные услуги по парсингу данных.
Как меняются инструменты парсинга цен
Из практики мы видим, что по мере возрастания степени активного противодействия парсингу, инструменты проходят путь от самых простых до более продвинутых. Действительно, зачем сразу делать сложную систему парсинга, если на большинстве e-commerce сайтов вообще нет никакой системы противодействия парсингу или бот-атаками и срабатывают даже простые методы?
Вот какие инструменты мы наблюдаем, по мере возрастания сложности атаки.
Простые утилиты – wget, curl, например, в цикле на bash. Данные клиенты банально выполняют запросы с дефолтными параметрами, иногда меняют User Agent на более похожий на “человеческий”, то есть присущий обычному браузеру.
Кастомизированные скрипты. Используется скрипт, который выполняет целевой запрос или цепочку запросов, но это чуть более сложные системы, чем скрипт на bash. Как правило запросы выполняются с помощью таких библиотек как python-requests, атака может быть как с одного IP, так и распределенная со множества машин.
Эмуляторы браузеров. Это полноценные браузеры, как правило работающие в headless режиме, реализуются использованием комбинации таких инструментов как Selenium WebDriver, Headless Chrome, Puppeteer. Для масштабного парсинга запускается множество машин с различных серверов и работают в несколько потоков одновременно. Так как это браузер, то он может проходить проверки на поддержку Cookie, JavaScript и другие “технические” проверки.
“Эмуляторы человека”. Это более продвинутые инструменты и сценарии атак, использующие эмуляторы браузера, stealth-механизмы скрытия реальных параметров среды исполнения, использование резидентных прокси и интеграцию с системами обхода Captcha – так называемыми Captcha Farms. Captсha Farms представляют собой программные продукты с наборами API для передачи картинки или объекта Captcha для ее последующего автоматического или ручного решения, то есть включают инструменты распознавания текста (OCR) и десятки или сотни реальных живых людей, готовых за 2 доллара распознать 1000 светофоров, мостов или гидрантов.
Источники бот-трафика
По мере возрастания хитрости атакующего можно выделить следующие источники бот-трафика:
Дешевые VPS и хостинг, подсети облачных провайдеров. Здесь все просто – атакующий за пару долларов в месяц арендует виртуальную машину с IP адресом, запускает на ней свой инструментарий и начинает парсинг. Как правило, используются хостинг провайдеры, которые не сильно реагируют на abuse письма, но встречаются и вполне лигитимные облачные провайдеры. По своим проектам защиты мы часто видим в логах атаки десятки или сотни IP адресов, принадлежащих одному провайдеру.
Прокси-серверы. Все то же, что в первом пункте, но трафик проходит через прокси. Как раз для “маскировки” источника атаки. Частный случай – TOR, он больше используется для попыток эксплуатации уязвимостей прикладного характера, но иногда встречается и при парсинге.
IP адреса домашних и мобильных сетей в основном регионе присутствия онлайн-ритейлера. Это более сложный с точки зрения детектирования случай, так как используются сети типовых провайдеров и просто по анализу подсети парсинг-трафик совершенно не выделяется в общем потоке трафика.
Для организации такой схемы используются как “резидентные” прокси, так и зараженные браузеры и устройства ни в чем не подозревающих пользователей. Резидентные прокси стоят дороже, чем обычные, поэтому их реже используют, но, если мы говорим о целевой атаке, имеющей целью получение коммерческого преимущества – затраты на такие прокси несущественны для атакующего конкурента.
Как усложнить атакующим парсинг цен в e-commerce
Мы поговорили о проблеме, давайте перейдем к решению. Я приведу несколько типовых методов борьбы с ботами-парсерами, большую часть из которых можно реализовать самостоятельно, без использования специальных системы защиты.
Что можно сделать своими силами:
Ограничения по User Agent. Например, заблокировать “python-requests”.
Плюсы:
Очень просто внедрить.
Минусы:
Очень просто обойти. Помогает только от самых маленьких атакующих или от ботов, которые не пытаются маскироваться (специализированные инструменты и поисковики).
Ограничения по странам. Если вы продаете книги или еду в России, то скорее всего, трафик из Китая и Бангладеш не является для вас целевым, если у вас нет доставки в эти страны.
Плюсы:
Относительно просто внедрить.
Отсекает много лишнего.
Минусы:
Со временем, после блокировок всех нежелательных стран, бороться с атаками станет сложнее, так как атакующие перетекают в целевую страну. Например, если ранее боты приходили из Индии, то после блокировки страны этот же трафик будет идти из России. Это немного дороже для атакующего, но точно не остановит целевую парсинг-атаку.
Есть риск заблокировать соотечественников на отдыхе или в других странах. В нашей практике заказчик заблокировал Кипр, но не учел, что в стране большая русскоязычная тусовка и люди оттуда действительно делают заказы на российских онлайн-площадках.
Ограничения по провайдерам. Если вам не нужен трафик с Amazon или Digital Ocean, их подсети можно заблокировать.
Плюсы:
Довольно просто отсекается много хостингов, VPN и прокси-серверов.
Минусы:
Возможные ложные срабатывания, так как именно на этих хостингах размещаются VPN провайдеры, которыми могут пользоваться ваши покупатели.
Их много – сложно успевать контролировать.
Внедрение Captcha. Да, те самые веселые картинки с гидрантами и парковочными счетчиками, которые мы так любим.
Плюсы:
Captcha может быть довольно кастомизированной, ее можно встроить на те действия или в те области приложения, которые является критичными.
Отсекает подозрительный трафик, используется как средство дополнительной проверки.
Минусы:
Требуется модификация кода приложения.
Есть риск помешать реальным пользователям, это правда раздражает.
Эффективность далека от 100% - существуют готовые системы по обходу Captcha за три копейки - те самые Captcha Farms. Как с ними бороться - смотри другие разделы про продвинутую защиту.
Rate limiting. Ограничение количества/скорости запросов с одного IP или в рамках одной сессии.
Плюсы:
Эффективный механизм для остановки большого количества атак, удорожает атаку для злоумышленника.
Минусы:
Сложно настраивать вручную и управлять большим количеством разных лимитов для разных эндпоинтов.
Специализированные системы защиты от парсинга и бот-атак
Специализированные решения для защиты от парсинга и бот-атак используют и комбинируют все вышеперечисленные методы защиты, добавляя и более продвинутые технологии.
Внедрение механизмов fingerprinting. Это оценка клиента по множеству параметров, присвоение токена/идентификатора клиенту и последующий анализ собранных данных.
Позволяет классифицировать клиентов и идентифицировать клиентов, сопоставлять активность клиента во времени, даже если клиент приходит без cookie.
Не так сложно это внедрить, как анализировать большой объем данных и использовать его результаты для противодействия атакам - сам по себе fingerprinting не останавливает атаку, но позволяет реализовать более сложным механизмы защиты.
Проблемы связаны с обработкой больших данных, обеспечения срабатывания защиты в режиме реального времени, с минимальной задержкой на обработку.
Классификация и аттестация клиентов. Обычно этот процесс идет после фингерпринтинга. Классификация – отнесение к одному из классов трафика, например, к “хорошим ботам”, “плохим ботам”, “браузерам” или подозрительным клиентам.
Аттестация клиентов – принятие решения о том, является ли клиент, отправивший запрос в веб-сервер, легитимным. Как правило, после идентификации и классификации клиента становится понятно, разрешать ли такой трафик.Для веб-браузерных клиентов процесс классификации включает обработку специального JavaScript кода, который проводит заданные проверки клиента.
Для мобильных клиентов классификация проходит за счет встраивания мобильного SDK в приложения iOS/Android. Уже задача кода в SDK - провести проверку и встроить результаты проверки в исходящий трафик, генерируемый мобильным приложением к веб-серверу.
Продвинутые системы классификации учитывают сотни параметров:За кого клиенты себя выдают - анализ User Agent и других заголовков запросов.
Кем являются на самом деле на основе таких параметров как источник трафика (сети, провайдеры, страны), реакции на различные проверки.
Что делают и как себя ведут – частота запросов, паттерны поведения и тд.
Рейт-лимитинг.
Специализированные системы защиты от ботов упрощают управление для множества лимитов - для разных URL и типов клиентов.
В таких системах возможно простое создание лимитов по количеству запросов в минуту, за одну сессию, по длительности сессии в минутах и тд.
Классификация на основе машинного обучения и статистических методов.
С помощью статистических методов можно выявить закономерности в трафике, в поведении клиента.
Например, системы выявляют клиентов, делающих больше запросов, чем обычный пользователь.
Поведенческий анализ пользователей.
Помимо паттернов поведения, системы защиты от парсинга могут анализировать биометрию – движения и положение мобильного устройства, движения мыши. Такой функционал может быть встроен в мобильные SDK для анализа мобильных клиентов.
Базы репутации.
Глобальные вендоры, строящие системы защиты от ботов, видят трафик десятков/сотен тысяч топовых веб-сайтов и миллионов клиентов. Информацию можно переиспользовать, чтобы защитить веб-сайты от тех клиентов, которые уже совершали подозрительные или вредоносные действия на других веб-сайтах. В базах репутации содержатся как данные по IP адресам, так и по конкретным клиентам, на основе отпечатков клиентов.
Кейс из нашей практики – защита онлайн-ритейлера от парсинга
Ниже я приведу статистику по одному из наших заказчиков, без указания названия компании. Данные приведены примерно за месяц от начала проекта. Статистика по трафику – около 600-800 запросов в секунду (без учета статики), несколько доменов, работающие мобильные приложения, все работает на основе API.
Начинается проект с подключения системы защиты, но без включения каких-либо блокировок и без какого-либо влияния на трафик – полностью пассивный режим.
Для начала посмотрим на трафик, которые система сама определяет как “хороший бот-трафик” – это трафик поисковых систем и прочих легитимных ботов, в общепринятом смысле.
Здесь и далее на графике указано количество запросов (хитов), минимальное деление времени – 1 час. Данные приведены без учета запросов к статическим файлам.
Далее мы собрали достаточно данных для понимания, какой бот-трафик является легитимным именно для данного веб-сайта и добавили его в исключения, чтобы никакие дальнейшие настройки системы защиты не сказывались на данном трафике.
У каждого сайта будут свои исключения – партнерские боты, системы интеграции с какими-то внешними ресурсами, выгрузка в маркетплейсы, колл-бэки платежных систем и тд. Данный трафик мы классифицировали и “разметили” как исключения, то есть добавили в белый список – на графике обозначено как Whitelisted.
Включение защиты в активный режим. Лучше это делать после добавления исключений, но не всегда сам владелец ресурса знает, какой трафик считать легитимный, с кем еще есть интеграции и тд. Поэтому процесс добавления исключений будет продолжаться еще какое-то время после включения активной защиты.
После включения защиты владельцев e-commerce приложений интересует вопрос, а не заблокировали ли мы кого-то из легитимных пользователей? Здесь можно рекомендовать анализировать бизнес-метрики, например количество успешных заказов. Если не изменилось — значит все хорошо, и можно продолжать использовать включенную защиту.
Для примера ниже я покажу только легитимный трафик – как видим, объем трафика не изменился, даже несмотря на то, что мы включили активную блокировку. Пики на графике - это промо-акции ритейлера, при которых клиентам активно рассылались push-уведомления и сообщения по другим каналам связи, что привело к всплеску запросов.
Общий график количества запросов по категориям трафика представлен ниже.
На графике в категории Mitigated показано количество запросов, но это не обязательно именно заблокированные запросы – часть из них, это проверки клиентов с помощью дополнительных механизмов классификации, после которых уже отсекается часть автоматизированных клиентов просто не проходя проверку, а часть из подозрительных клиентов получает оценку “нормального” пользователя и продолжает работу. Поэтому мы можем видеть всплески Mitigated трафика и в пиковые часы наплыва легитимного трафика – часть из клиентов вызвала подозрения у системы, прошла прозрачную проверку (не Captcha) и продолжила работу с сайтом.
В результате общие данные по запросам в ходе 1 месяца с начала проекта представлены следующей диаграммой.
Как видим, примерно треть общего трафика поступает от бот-клиентов, которые не относятся к известным хорошим ботам. По нашему опыту, от отрасли к отрасли процент бот-трафика может отличаться, и в среднем составляет от 25% до 85%, в зависимости от ниши ритейлера и других факторов. Максимальный процент вредоносного бот-трафика и парсеров цен мы наблюдаем в travel отрасли.
Рекомендации по упрощению встраивания защиты
Детально механизмы защиты от автоматизированных атак описаны в уже упомянутом руководстве по защите от автоматизированных атак от OWASP. Реализовывать ли их самостоятельно на уровне приложения, или же использовать готовые системы защиты от ботов – решать владельцу e-commerce приложения исходя из оценки затрат, скорости получения результата и других бизнес-критериев.
Хотелось бы добавить несколько рекомендаций, которые мы прочувствовали на собственном опыте.
Используйте различные API эндпоинты для браузеров и мобильных приложений. Это поможет упростить внедрение защиты для веб-браузеров, не дожидаясь внедрения мобильных SDK, реализующих возможности классификации клиентов, в приложения на iOS/Android.
Разделяйте общедоступные API и все остальные. Чем меньше ценных данных доступно для публики – тем меньше поверхность атаки и тем проще защищать эти данные и API. В данном случае речь идет именно о ценах и характеристиках товаров.
Выдавайте ключи для легитимного использования API и внедряйте rate limiting на стороне сервера. На нашей практике даже авторизованные клиенты использовали механизмы автоматизации для получения большего количества данных, чем изначально хотел владелец веб-ресурса. Контролировать это проще на стороне самого сервера, чем на стороне отдельной системы защиты.
Выводы
Невозможно полностью ограничить доступ к публичным данным в сети. Если данные можно считать в браузере, их скорее всего считают и попытаются автоматизировать процесс. Вопрос лишь в стоимости осуществления таких мероприятий, то есть в конечном итоге – в мотивации атакующих. Коммерческая выгода от использования данных о ценах товаров конкурентов может в сотни/тысячи раз перекрывать стоимость организации сложных атак, использующих множество техник маскировки и обхода систем защиты.
Можно усложнить задачу парсинга цен для большого масштаба обработки ваших данных. Сюда входят внедрение механизмов защиты на стороне приложения, внедрение специализированных систем защиты. Часть мер можно внедрить самостоятельно, использование специализированных решений по защите от ботов дает дополнительные и продвинутые инструменты в борьбе с парсингом.
Сложность парсинга будет только возрастать по мере противодействия ему – это постоянный процесс борьбы щита и меча. Владельцам e-commerce приложений не стоит расслабляться после успешно отбитой парсинг-атаки, ведь атакующий сделает выводы, перегруппируется и запустит парсинг с новыми параметрами. В такой ситуации важно иметь возможность оперативной реакции и изменения настроек системы защиты.
