Методы сокращения сбора данных от сервисов AJAX / JSON - PullRequest
11 голосов
/ 19 ноября 2009

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

Мне кажется, что проблема не так сложна, если бы вы сказали, что Flash-клиент потребляет данные. Затем вы можете отправить зашифрованные данные клиенту, который будет знать, как их расшифровать. Однако тот же метод кажется невозможным в AJAX из-за открытого характера исходного кода Javascript.

Кто-нибудь реализовал здесь умную технику?

Каким бы ни был метод, он все же должен позволять подлинной функции AJAX потреблять данные.

Обратите внимание, что я не говорю о защите «конфиденциальной» информации, странная утечка записей не является проблемой. Скорее, я думаю о том, чтобы остановить ситуацию, когда вся БД копится ботами (либо за один раз, либо постепенно с течением времени).

Спасибо.

Ответы [ 7 ]

7 голосов
/ 23 ноября 2009

Во-первых, я хотел бы прояснить это:

Мне кажется, что проблема не в так сложно, если бы ты сказал Flash клиент потребляет данные. Затем вы может отправлять зашифрованные данные на клиент, который бы знал, как расшифровать это. Кажется, тот же метод невозможно с AJAX, хотя, из-за открытая природа Javascrip источник.

Будет совершенно очевидно, что информация отправляется во флэш-клиент в зашифрованном виде, и злоумышленнику не составит труда узнать из вашей программы, скомпилированной во флэш-памяти, что используется для этого - реплицировать и получить все эти данные.

Если данные действительно имеют значение, о котором вы думаете, вы можете рассчитывать на вышесказанное.

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

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

7 голосов
/ 22 ноября 2009

Первое, что мешает ботам украсть ваши данные, это не технология, это законно. Во-первых, убедитесь, что у вас есть правильный язык в Условиях использования вашего сайта, что то, что вы пытаетесь предотвратить, фактически запрещено и оправдано с юридической точки зрения. Во-вторых, убедитесь, что вы разрабатываете свою техническую стратегию с учетом правовых вопросов. Например, в США, если вы помещаете данные за барьер аутентификации и злоумышленник крадет их, это, вероятно, является нарушением закона DMCA . В-третьих, найдите адвоката, который может проконсультировать вас по вопросам ИС и DMCA ... приятных людей в StackOverflow недостаточно. : -)

Теперь о технологии:

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

Этот подход, конечно, уязвим для опытных ботов, которые автоматически регистрируют новых «пользователей», но с достаточно хорошей реализацией CAPTCHA довольно сложно создать такого рода бота. (см. раздел «Обход» в http://en.wikipedia.org/wiki/CAPTCHA)

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

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

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

Это очевидно, но если ваши данные доступны для публичного поиска поисковыми системами, вам обоим понадобится решение, отличное от AJAX (Google не будет читать ваши данные ajax!), И вы захотите пометить эти страницы NOARCHIVE , поэтому ваши данные не отображаются в кэше Google. Вам также, вероятно, понадобится белый список IP-адресов искателей поисковых систем, которые вы разрешаете размещать на страницах, которые можно сканировать в поисковых системах (вы можете работать с Google, Bing, Yahoo и т. Д., Чтобы получить их), иначе злоумышленники могут просто выдать себя за другого Google и получите ваши данные.

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

P.S. - другой способ думать об этой проблеме, которая может или не может применяться в вашем случае. Иногда легче изменить работу ваших данных, что устраняет необходимость их защиты. Например, можете ли вы каким-либо образом связать свои данные со службой на вашем сайте, чтобы данные не были очень полезны, если они не используются в сочетании с вашим кодом. Или вы можете встроить в нее рекламу, чтобы везде, где она показывается, вам платили? И так далее. Я не знаю, применимо ли какое-либо из этих смягчающих мер к вашему делу, но многие компании нашли способы бесплатно раздавать вещи в Интернете (и поощрять, а не предотвращать широкое перераспределение) и по-прежнему зарабатывать деньги, так что гибридный бесплатный / Платежная стратегия может (или не может) быть возможной в вашем случае.

1 голос
/ 27 ноября 2009

Вот множество предложений:

  1. Выпуск токенов, необходимых для выкупа, вместе с каждым запросом AJAX. Срок действия жетонов.
  2. Отслеживание количества запросов от каждого клиента и ограничение чрезмерного использования в зависимости от ожидаемого нормального использования вашего сайта.
  3. Ищите используемые шаблоны, такие как последовательные запросы, всплески запросов или запросы, которые выполняются быстрее, чем может выполнить человек.
  4. Проверка пользовательских агентов. Многие боты не полностью копируют информацию о пользовательском агенте браузера, и вы можете устранить программную очистку ваших данных, используя этот метод.
  5. Измените интерфейсный компонент вашего веб-сайта, чтобы он переадресовывал на капчу (или какой-либо другой механизм проверки человеком) после превышения порога запроса.
  6. Измените свою логику, чтобы ответные данные возвращались несколькими различными способами, чтобы усложнить код, необходимый для анализа.
  7. Obsfucate ваш клиентский JavaScript.
  8. Блокировка IP-адресов клиентов-нарушителей.
1 голос
/ 27 ноября 2009

Некоторые методы перечислены в Дальнейшие размышления о том, как помешать очистке экрана .

Если вы используете PHP, Плохое поведение - хороший инструмент для помощи. Если вы не используете PHP, он может дать некоторые идеи о том, как фильтровать (см. Как это работает страница).

Блог Incredibill дает хорошие советы, списки пользовательских агентов / диапазоны IP-адресов, которые нужно заблокировать, и т. Д. *

1 голос
/ 22 ноября 2009

Это не конкретный ответ с подтверждением концепции, но, возможно, отправная точка для вас. Вы можете создать функцию JavaScript, которая обеспечивает функции шифрования / дешифрования. Javascript должен быть построен динамически, и вы бы включили ключ шифрования, который является уникальным для сеанса. На стороне сервера у вас будет служба шифрования, которая использует ключ сеанса для шифрования вашего JSON перед его доставкой.

Это, по крайней мере, помешает кому-либо прослушивать ваш веб-трафик и извлекать информацию из вашей базы данных.

Я с kdgergory, похоже, ваши данные слишком открыты.

1 голос
/ 22 ноября 2009

Если у вас есть внутренняя ячейка Memcached, вы можете рассмотреть возможность использования метода, при котором вы создаете запись для каждого IP-адреса, который попадает на ваш сервер с истечением часа. Затем увеличивайте это значение каждый раз, когда IP-адрес достигает вашей конечной точки AJAX. Если значение превышает определенный порог, поджарьте соединение. Если значение истекает в Memcached, вы знаете, что оно не «копчится».

0 голосов
/ 28 ноября 2009

Боты обычно не анализируют Javascript, поэтому ваш ajax-код не будет немедленно выполнен. И если они даже делают, боты, как правило, также не поддерживают сессии / куки. Зная это, вы можете отклонить запрос, если он вызывается без действительного сеанса / файла cookie (который, очевидно, предварительно установлен на стороне сервера запросом на родительской странице).

Это не защищает вас от опасности для человека. Самый безопасный способ - ограничить доступ пользователей с помощью логина / пароля. Если это не ваше намерение, тогда вы должны согласиться с тем фактом, что это публичное приложение. Конечно, вы можете сканировать журналы и основные списки с IP-адресами и именами пользователей, но это очень важно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...