Защита от парсинга сайта

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

В первую очередь необходимо решить, от чего защищаемся, но сначала две строчки о кухне:

1. Парсер (робот, паук, вотэва) умеет находить новые документы для исследования.

2. Парсер умеет выдирать из документа искомую информацию.

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

Далее, условно делим парсинг на два направления:

1. Слепой сбор

2. Таргетированный

Между двумя этими категориями существуют градации, но тем не менее.

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

Второе направление характеризуется четкой ориентацией на узкую группу сайтов, объединенную, как правило, одним шаблоном, либо форматом представления данных (rss). Часто парсер изготавливается/настраивается на конкретный ресурс (например парсинг статистики ключевиков liveinternet.ru). В случае "таргетированного" сбора, в подавляющем большинстве случаев парсер очень щепетильно отбирает документы для обработки, и точно так же щепетильно работает с контентом (много узконаправленных сигнатур, выщемляющих данные с гм.. высокой степенью формализации).

Ну и соответственно, как защититься.

От первой группы существует весьма действенный метод с ханипотом. Поскольку парсер первого типа, образно говоря, сам не знает, что ищет, он следует по всем обнаруженным линкам на документы. В темном углу сайта админом вставляется ссылка с текстом "Для роботов", или вроде того. Люди не кликнут. Если кликнут - большинство можно отфильтровать техническими методами. Ну в крайнем случае схватят ненадолго бан. Тут рабочих вариантов множество. От пс закрываем. Левые роботы обязательно заглянут. Тут к ним и применяем меры.

К сожалению, чем семантичнее вы верстаете свои документы, тем проще роботу вырвать "правильный" контент (в основном парсеры первого типа используются либо поисковиками/кешерами, либо собирателями статей и относительно больших корпусов текста). Чем чище будет контент, выдранный с вашего сайта с использованием весьма общих сигнатур, тем больше вероятность, что контент будет "оприходован" вебмастером, запустившим кравлер - ему потребуется меньше времени и усилий для очистки полученных данных.

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

Такой парсер редко ловится на ханипот. И по сути вам уже ответили, что необходимо сделать, а именно избавиться от статичных сигнатур. Однако, это не так просто, как может показаться, и чем проще по структуре ваш контент, тем сложнее вам его защитить. Скажем так, если вы хотите укрыть от скачивания свой блог, где всего-то что есть у каждого документа, это заголовок, дата, описание краткое да описание полное, то можно особо и не париться - при наличии у автора парсера должного инструментария, его задачу вы особо не усложните. Если речь идет о каталоге, вроде Маркета, вот там можно развернуться, ибо есть простор для игры с кодом, да и типов полей достаточно (а каждый универсальный тип поля подразумевает свой зоопарк сигнатур). Тут сборщику придется повозиться, анализируя все возможные варианты, и определяя либо одну универсальную, но относительно сложную, сигнатуру, либо множество узких. Есть способы, как сделать так, чтобы только весьма продвинутый сборщик смог подобрать универсальную сигнатуру, но это скорее для технарей. Поэксперементируйте сами, поймете после некоторого погружения в предметную область. Стремитесь к результату, когда для парсинга вашего сайта придется сделать множество "узких", "маленьких" сигнатур. Так вы отвадите от своего контента большинство неискушенных сборщиков, а искушенные будут оправданно задирать цены на ваш контент, соотв. контент попадет в меньшее количество рук ;)

Кстати, тот же маркет парсится на раз-два, поскольку все поля всех объектов выводятся так, что с легкостью влазят в простенькую сигнатуру. Спасибо верстальщикам Яшкиным. Не зря они впоследствии евангелистами Оперы становятся ;)

В общем, если вариантов с динамическими сигнатурами не очень много, есть смысл оттолкнуться от таймлайна. Скажем, у вас 10к документов. Это, условно говоря, час парсинга (ооочень усредняю, сами понимаете). Меняйте сигнатуры в зависимости от астрономического времени. Скажем, раз в пятнадцать минут на всем сайте происходит смена всех шаблонов всех постов, и вместо тега <p>, они получают обрамление в виде "тега" <table><tr><td>. Колхозно, да, но действенно. Особенно если парсит человек, не успевший съесть собаку. Ваша задача - максимально усложнить ему жизнь. Если за первый час, трижды перенастроив парсер, человек так и не получит готового массива данных (ведь пока он будет выкачивать ваш сайт, там уже трижды сигнатуры поменяются), он скорее всего просто плюнет, и уйдет парсить что-нибудь еще. Иногда можно где-то позабыть подзакрыть тот же параграф. Тут есть, тут нет. А хоба, через пятнадцать минут везде есть. Поверьте, такая чехарда измотает любого. Главное тут не просто менять сигнатуру, а следить за тем, чтобы вас не могли обойти с фланга, просто включив в сигнатуру какие-то элементы, на которые вы не обращаете внимания, но которые все-таки позволяют в обход ваших игрищ установить, где в пределах документа находится искомый контент. И маленький хинт: бесполезно разбавлять сигнатуры "левыми" аттрибутами в тегах. Только новички пишут сигнатуры вроде <a href=\"(http://.?*)\">(.?*)</a>. Любой уважающий себя сборщик обязательно автоматом добавит всюду внутри каждого тега [^<>]*?, а ленивый научит свой софт, чтобы тот сам так делал, пока оператор сигнатуры вбивает 🚬

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

Вот как-то так. Сорри за сумбурность и вялый слог, утро воскресенья все-таки :) Не уверен, что буду следить за топиком, так что если будут вопросы, пишите в личку :)

кешировть надо документы, и "перезапуск парсера будет секунды занимать, и от проблем таких спасает"

не спасает. в кеше будет множество документов с разными сигнатурами. не каждый парсер, если речь не идет о полностью самопальном, который представляет собою фреймворк кода, а не гуево-конфиговое решение, позволяет задать несколько сигнатур для одной и той же сущности. более того, не забывайте, что есть высокая вероятность того, что сигнатуры начнут перехлестываться. т.е. есть сигнатура А, есть Б. Они используются в рамках одного шаблона, для разметки одной и той же сущности, будучи применимыми по очереди, с некоторым временным лагом. Мы закешировали 100 документов, где искомые данные обернуты в А. Потом увидели Б. Добавили сигнатуру. Закешировали еще 100 с сигнатурой Б. Итого имеем в кеше 100 документов с А, и 100 с Б.

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

На самом деле без кеша, естественно, никуда, но в решении вопроса с плавающими сигнатурами он не на первых ролях.

response, да все это фигня, у вас не "промышленное решение", а "нахальчик чтото придумал". под таких нахальчиков все равно кому надо будет, напишут парсер, а если промышленное, то в какой нить х*умер попадет такое решение да и все. от парсинга нельзя защититься, можно только сделать его более сложным чем он есть

не уверен что поможет, но ряду парсеров данный вариант доставляет проблемы:

делайте сертификаты на сайты и пусть они работают на хттпс.

kapow_expert добавил 25.01.2010 в 00:25

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

вы к чему вообще столь безаппеляционно пересказываете уже сказанное?

еще одно весьма весомое замечание, в корне меняющее суть сказанного.

Можно смешивать div и таблицы, будет сложнее

2. Перемещаем ява скрипт по документу или любой другой массив данных, можно в том же невидмом виде.

3. Защититься от парсера не возможно на данном этапе, это и так понятно. Но усложнить можно всегда. Решение по времени самое удобное.

Вопрос только в том, реально ли нужно усложнять? Думаю стандартный сайт в 200-500 страниц можно и в ручную за час скопировать.

Напишут, как только засечем, придется переписывать. Сколько затрат. За эти деньги можно чернорабочего нанять, гораздо эффективнее будет.

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