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

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

В прошлом мы часто имели большую часть рендеринга на стороне сервера, где мы выводили HTML в браузер. Это было немного проблематично для парсеров, потому что им нужно было анализировать HTML и получать данные таким образом. С развитием одностраничных приложений и рендеринга на стороне клиента (например, React) данные уже доступны в формате JSON, и это проблематично, если вы хотите защитить их от злонамеренных пользователей. Как только я начинаю работать с приложением на React, у меня возникает одна из тех вещей, которая приходит в голову: как я могу убедиться, что я не позволяю ботам загружать всю мою базу данных.

Хотя полностью устранить парсинг довольно сложно, есть вещи, которые вы можете сделать, чтобы отговорить от этого. Вы хотите найти баланс между удобством использования для законных пользователей и предотвращением попадания плохих ботов на ваши API. Вы также должны рассмотреть самые простые меры, прежде чем становиться слишком изощренными. Помните, что существует множество вещей, которые вы можете сделать, чтобы предотвратить хакеров от кражи ваших данных, но некоторые из вариантов гораздо дешевле других. Когда я пытался собирать данные... (шшш... никому не говорите, это было экспериментально и для личного использования), вот список некоторых вещей, которые я нашел самыми раздражающими. И под раздражающими я имею в виду, что мне пришлось решить, хочу ли я продолжать или сдаться, потому что время, затраченное на получение данных, просто не стоило этого.

Ограничение количества запросов с одного IP

Это, вероятно, первое, на что следует обратить внимание. Если IP-адрес часто обращается к вашему сайту, вы должны установить ограничение времени. Вы можете сделать это на уровне веб-сервера, и есть способы сделать это, например, в Nginx и Apache. Ограничение должно быть немного выше, чем у типичного пользователя, чтобы избежать ложных срабатываний. Если есть маршруты, которые не часто используются типичным пользователем, но необходимы для парсинга, то защита этих маршрутов - хорошая идея (например, маршруты обновления токенов, регистрации и входа пользователя).

Большинство парсеров сможет изменить IP-адрес с помощью VPN, поэтому я бы не рассчитывал на этот метод, чтобы решить все ваши проблемы. Это определенно один из неприятных моментов. Он просто показывает злоумышленнику, что вы знаете, что делаете, и что им лучше обратиться к вашим конкурентам в первую очередь. Если данные не являются супер-ценными, то бот, скорее всего, не настолько сложен, чтобы автоматически менять IP-адреса. Поэтому им придется сидеть и следить за процессом каждый раз, когда он блокируется. Это их раздражает.

Использование капчи для выявления аномалий

Предположим, что с определенного IP-адреса поступает слишком много запросов, но вы не хотите блокировать доступ реальных пользователей к данным. Вы все равно можете предложить пользователям пройти капчу, прежде чем они смогут получить доступ к дополнительным страницам. Это довольно стандартная практика на многих веб-сайтах. Google способен обнаружить изменения местоположения с помощью IP-адреса и считает это аномалией. Попытки входа с разных мест являются типичным сигналом опасности, хотя небольшой процент пользователей все же может быть законными (например, использование VPN для подключения к разным офисам). Но вот почему у вас есть капча, и когда она не пройдена, доступ блокируется. Хотя настройка этого требует некоторой работы в начале, это один из моих любимых методов блокировки парсеров.

Создание медовых горшочков и обфускация данных

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

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

Безопасность через неясность все еще работает

У разработчиков есть смешанные чувства относительно введения неопределенности в свой продукт, и я полностью понимаю это. Однако я считаю, что безопасность через неясность работает блестяще в некоторых случаях. Если вы выбрасываете случайный код ошибки, который не является ответом на ошибку "_429 Слишком много запросов", бот не будет знать, как с ним справиться. Вам не нужно раскрывать слишком много информации в публичных ответах API о том, почему запрос был отклонен. Аналогичный пример - реализация функции "Забыли пароль", где вы не сообщаете пользователю, существует ли имя пользователя в базе данных или нет. Если вы говорите, что сброс пароля был инициирован, независимо от того, существует ли пользователь или нет, злоумышленник не будет знать, существует ли имя пользователя в системе.

Введение водяных знаков и предотвращение горячей ссылки

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

Горячая ссылка - это еще одна вещь, которую вы можете сделать, чтобы предотвратить использование изображения другими приложениями, кроме вашего собственного. Это можно настроить на веб-сервере и это существует уже давно. Я не вижу полезного случая, когда вы хотите разрешить горячую ссылку, поэтому это хорошая практика блокировать ее.

Регулярно изменяйте свою DOM-структуру

Это применимо только в случае, если ваш контент генерируется на сервере в виде HTML. Если ваш контент генерируется на стороне сервера, то злоумышленники имеют доступ только к HTML. Путем частого изменения структуры, классов и идентификаторов в HTML вы будете затруднять работу парсерам. Я не считаю это самым эффективным методом для отпугивания злоумышленников, так как они могут быстро обновить свой скрипт, но это может помочь. Это особенно эффективно, если вы не оставляете слишком много уникальных атрибутов в вашей DOM, чтобы позволить ботам запрашивать конкретный контент. Например, если у вас есть ценный динамический контент в тегах <div> и <p>, но теги похожи на другой бесполезный статический контент, то не так просто скопировать только этот контент. Опять же, я не думаю, что стоит беспокоиться о том, как выглядит ваш HTML, так как всегда есть обходные пути, чтобы все равно получить этот контент. Но если вы можете избежать перечисления всей ценной информации, такой как идентификаторы, и сделать его слишком простым для запроса в HTML, это делает его немного сложнее для ботов.

Минификация и Обфускация вашего Javascript

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

Скрыть XML-карты сайта?

Скрытие XML-карт сайта может вызвать некоторые споры, так как это противоречит практикам SEO. Но действительно ли вам нужно, чтобы ваша карта сайта находилась в корневом каталоге вашего сайта и называлась sitemap.xml или sitemap.xml.gz? Некоторые даже предлагают поместить ее в файл robots.txt. Это хорошо для обеспечения обнаружения вашего контента, но это также дает ссылки на все страницы вашего веб-сайта. Я уже отправляю свои сайты в Google Search Console, и, возможно, у меня есть несколько карт сайта. Я просто не вижу смысла делать эти карты доступными для всех. Если она называется по-другому, чем default, я хотя бы уверен, что она не доступна для использования скраперами. Если у вас не так много контента, я не вижу в этом проблемы, но я еще не нашел приложение или веб-сайт с большим количеством данных, которое делает свою карту сайта очень легко угадать.

Сделайте контент доступным только для зарегистрированных пользователей

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

Используйте трекбэки

Введение URL-адресов, указывающих на ваш веб-сайт или контент, который вы можете отследить позже. Это помогает определить, кто является скраперами после того, как нанесен ущерб, но всегда полезно уметь определить нарушителя. Возможно, вам захочется быть немного хитрее с этим и вводить их случайным образом, чтобы избежать того, чтобы боты выполняли поиск и замену перед сохранением ваших собранных данных.

Некоторые заключительные мысли

Полностью блокировать парсеры невозможно. Если человек может найти и прочитать ваши данные, то и бот может. Вот почему я предлагаю использовать Captcha для проверки, что это реальный человек, получающий доступ к вашим данным. Во многих случаях боты могут так точно имитировать человека, что не так просто понять, что это бот. Даже с ограничением скорости, бот может иметь случайные задержки на каждый запрос, чтобы казаться человеком и пройти тест на ограничение скорости. Эти задания могут выполняться в фоновом режиме в течение нескольких дней; это все машинное время, и мы можем позволить им это делать. Если мы слишком сильно ужесточим безопасность, начнут возникать ложные срабатывания, и фактические пользователи начнут испытывать проблемы, поэтому это обычно не лучший вариант. Ключевое здесь - найти баланс и сделать атаки недостаточно привлекательными, чтобы собираемые данные просто не стоили затраченных усилий.