Статьи

Автоматический спам в комментариях к блогам?

Через СаймонаMT Plus Комментарий Спам равно мертвого сайта . Тема спама в комментариях к блогу беспокоит меня не столько как проблема сама по себе, сколько потому, что об этом говорят многие (и страдают от этого) люди, и в то же время мало реального технического анализа.

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

Во-первых, мне еще предстоит полностью ответить на вопрос, является ли проблема главным образом людьми, ручным размещением спама или автоматизированными процессами (сценариями)? Я предполагаю, что ответом является и то и другое, но большая проблема заключается в последнем, учитывая объемы, генерируемые в некоторых местах, вплоть до отказа в обслуживании по сравнению с Movable Type.

В первом случае; армиям грустных гномов, которым платят за публикацию ссылок для pagerank, единственное приличное техническое решение может показаться «внесением в черный список» — ведение списков шаблонов (URL / слов), которые следует блокировать от сообщений.

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

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

Наиболее вероятные инструменты для написания сценариев спама: Perl плюс LWP :: UserAgent (или аналогичный, например, LWP :: Simple), PHP плюс PEAR :: HTTP_Request (или, возможно, Snoopy ) и Python плюс httplib . Возможно, используется Intenet Explorer через COM?

Чтобы иметь возможность написать спам-скрипт с использованием этих инструментов, требуется, по крайней мере, некоторое знание программирования и протокола HTTP плюс время для его написания. Конечно, вам не нужно быть гением, и написание простого сценария не займет много времени, но все же требует немного больше таланта и усилий, чем «Hello World».

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

Стоит также отметить, что спамеры сосредотачиваются на блогах, в которых работают такие приложения, как Moveable Type, которые предлагают стандартный HTTP API для публикации комментариев. Что мне подсказывает, так это то, что спам-скрипты примитивны, возможно, содержат жестко закодированные имена полей формы и, возможно, жестко закодированные (относительные) URL-адреса для POST. Другими словами, изменение URL-адресов / полей формы на сервере нарушит работу сценариев.

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

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

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

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

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

Сценарий теперь должен анализировать как HTML, так и CSS, а затем выяснить, как CSS соотносится с HTML — это не то, что вы можете сделать за 5 минут взлома.

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

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

Мне кажется, что более простой путь — просто вступить в гонку вооружений со спамерами, которая будет «невидимой» для обычного посетителя с браузером. Возьмите его до такой степени, что для написания спам-инструмента требуется столько времени и навыков разработки, что оно уже не стоит усилий. Если кому-то удастся написать спам-инструмент для вашего блога, по крайней мере, вы будете знать, что он был одним из основных разработчиков Mozilla.

Во всяком случае — это вид, как я вижу это издалека. Скажи слово, если это не так.