Методы для сокращения сбора урожая данных от сервисов AJAX/JSON

Связанный с расстоянием Levenstein: Вы могли бы хотеть нормализовать его путем деления результата с длиной более длинной строки, так, чтобы Вы всегда получили число между 0 и 1 и так, чтобы можно было сравнить расстояние пары строк значимым способом (выражение L (A, B)> L (A, C) - например - бессмысленно, если Вы не нормализуете расстояние).

11
задан Ned Batchelder 17 July 2010 в 16:13
поделиться

7 ответов

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

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

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

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

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

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

7
ответ дан 3 December 2019 в 06:46
поделиться

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

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

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

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

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

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

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

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

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

7
ответ дан 3 December 2019 в 06:46
поделиться

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

1
ответ дан 3 December 2019 в 06:46
поделиться

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

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

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

1
ответ дан 3 December 2019 в 06:46
поделиться

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

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

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

1
ответ дан 3 December 2019 в 06:46
поделиться

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

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

0
ответ дан 3 December 2019 в 06:46
поделиться

Вот несколько предложений:

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

Похожие вопросы: