Не позволяя сценаристам захлопнуть ваш сайт

Поскольку я не нашел jQuery-бесплатный ответ, который я мог бы скопировать / вставить, вот решение, которое я использовал:

function clickEvent(e) {
  // e = Mouse click event.
  var rect = e.target.getBoundingClientRect();
  var x = e.clientX - rect.left; //x position within the element.
  var y = e.clientY - rect.top;  //y position within the element.
}

JSFiddle полного примера

486
задан 14 revs, 6 users 53% 4 May 2018 в 17:37
поделиться

125 ответов

Как насчет того, чтобы реализовать что-то как ТАК делает с КАПЧАМИ?

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

, Если они приводят проверку к сбою x времена подряд (говорят, 2 или 3), дайте тому IP тайм-аут или другую такую меру. Тогда в конце тайм-аута, выведите их назад к проверке снова.

<час>

, Так как у Вас есть незарегистрированные пользователи, получающие доступ к сайту, у Вас действительно есть только дюйм/с для продолжения. Можно выпустить сессии к каждому браузеру и отследить тот путь, если Вы желаете. И, конечно, подбросьте человеческую проверку, если слишком много сессий (пере-) созданы по очереди (в случае, если бот продолжает удалять cookie).

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

Кроме того, каковы разногласия, что X человек загружают ту же страницу (страницы) одновременно из одного IP? Если они высоки, возможно, Вам нужен различный триггерный механизм для Вашего предупреждения бота.

<час>

Редактирование: Другая опция состоит в том, если они перестали работать слишком много раз, и Вы уверены в требовании продукта, заблокировать их и заставить их лично ПОЗВОНИТЬ Вам для удаления блока.

люди Наличия звонят, действительно походит на глупую меру, но она удостоверяется, что существует человек где-нибудь позади компьютера . Ключ должен иметь блок только существовать для условия, которого никогда не должно почти происходить, если это не бот (например, приводят проверку к сбою многократно подряд). Тогда это ВЫНУЖДАЕТ человеческое взаимодействие - поднять трубку.

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

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

<час>

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

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

229
ответ дан 6 revs 4 May 2018 в 17:37
поделиться

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

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

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

6
ответ дан Paul Dixon 4 May 2018 в 17:37
поделиться

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

Поочередно, Вы могли попытаться создать способ "переставить" HTML pf страница в некотором роде, которая не влияет на рендеринг. Я не могу думать о хорошем примере первое, что пришло на ум, но я уверен, что это так или иначе выполнимо.

1
ответ дан Matt Boehm 4 May 2018 в 17:37
поделиться

Правовая оговорка: Этот ответ полностью non-programming-related. Это действительно, однако, пытается напасть на причину сценариев во-первых.

Другая идея состоит в том, если у Вас действительно есть ограниченное количество для продажи, почему Вы не изменяете ее от обслуживание в порядке поступления методология? Если, конечно, шумиха не является частью Вашей маркетинговой схемы.

существует много других опций, и я уверен, что другие могут думать о некоторых различных:

  • очередь упорядочивания (система предзаказа) - Некоторые сценарии могли бы все еще закончиться впереди очереди, но это, вероятно, быстрее только к, вручную вводят информацию

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

  • приоритетная очередь порыва - Если существует действительно высокое воспринятое значение, люди могут быть готовы заплатить больше. Реализуйте очередь упорядочивания, но позвольте людям платить больше, чтобы быть помещенными выше в очереди.

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

11
ответ дан 3 revs 4 May 2018 в 17:37
поделиться

Существуют некоторые другой / лучшие решения, уже отправленные, но для полноты, я полагал, что упомяну это:

, Если Ваше основное беспокойство является снижением производительности, и Вы смотрите верный стук , тогда Вы на самом деле имеете дело с DoS-атакой, и необходимо, вероятно, попытаться обработать его соответственно. Один общий подход должен просто отбросить пакеты от IP в брандмауэре после многих соединений во вторую/минуту/и т.д. Например, стандартный брандмауэр Linux, iptables, имеет стандартную операционную функцию соответствия 'hashlimit', который мог использоваться для корреляции запросов на установление соединения на единицу измерения времени к IP-адресу.

, Хотя, этот вопрос, вероятно, был бы более склонным для следующей ТАКИМ-ОБРАЗОМ-ПРОИЗВОДНОЙ, упомянутой на последнем ТАКИМ-ОБРАЗОМ-ПОДКАСТЕ, это еще не запустилось, таким образом, я предполагаю, что нормально отвечать:)

РЕДАКТИРОВАНИЕ:
, Как указано novatrust, существуют все еще ISPs на самом деле не присвоение дюйм/с их клиентам, так эффективно, клиент сценария такого ISP отключил бы все-клиентов от того ISP.

5
ответ дан 2 revs 4 May 2018 в 17:37
поделиться
  1. Обеспечивают канал RSS, таким образом, они не съедают Вашу пропускную способность.
  2. При покупке, заставьте всех ожидать случайный количество времени до 45 секунд или чего-то, в зависимости от того, что Вы ищете точно. Точно, каковы Ваши ограничения синхронизации?
  3. Дают всем 1 минуту, чтобы поставить их имя в для рисунка и затем случайным образом выбрать людей. Я думаю, что это - самый справедливый путь.
  4. Монитор учетные записи (включают несколько раз в сессию и хранят его?) и добавляют задержки с учетными записями, которые кажутся, что они ниже человеческого порога скорости. Это, по крайней мере, заставит ботов быть запрограммированными, чтобы замедлиться и конкурировать с людьми.
4
ответ дан 3 revs 4 May 2018 в 17:37
поделиться
  • 1
    У меня были эти ошибки очень часто, и сообщение является часто неправильным. Здесь случалось так, что, это не могло найти Интерфейс/Класс, который должен быть реализован, я вид наклона, это объясняет право, НО, где Вы получаете EventSubscriber от? Это от внешнего права библиотеки? – CodeNoob 8 February 2013 в 16:55

Я не вижу большой нагрузки, которой Вы требуете от проверки входящего дюйм/с Наоборот, я сделал проект для одного из моих клиентов, который анализирует журналы доступа HTTP каждые пять минут (это, возможно, было в реальном времени, но он не хотел это по некоторым причинам, что я никогда полностью понял), и создает правила брандмауэра заблокировать соединения от любых IP-адресов, которые генерируют чрезмерное количество запросов, если адрес не может быть подтвержден как принадлежащий законной поисковой системе (Google, Yahoo, и т.д.).

Этот клиент выполняет услугу веб-хостинга и запускает это приложение на трех серверах, которые обрабатывают в общей сложности 800-900 доменов. Пиковое действие находится в диапазоне thousand-hits-per-second и никогда не было проблемы производительности - брандмауэры очень эффективны при отбрасывании пакетов от помещенных в черный список адресов.

И, да, технология DDOS определенно существует, который победил бы эту схему, но он не видит, что происходят в реальном мире. Наоборот, он говорит, что это значительно уменьшило нагрузку на его серверы.

3
ответ дан Dave Sherohman 4 May 2018 в 17:37
поделиться
  • 1
    Это работает, только если я перемещаю банку в верхнюю часть списка. Большое спасибо @syp_dino! – Umberto 23 July 2013 в 15:41

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

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

существуют прокси и ботнеты для нанесения поражения проверкам IP. Существуют сценарии чтения капчи, которые чрезвычайно хороши. Существуют даже команды рабочих в Индии, которые побеждают капчи за маленькую цену. Любое решение, которое можно предложить, может быть обоснованно побеждено. Даже решения Ned Batchelder могут ступиться мимо при помощи управления WebBrowser или другого моделируемого браузера, объединенного с ботнетом или прокси-листом.

10
ответ дан 5 revs, 2 users 92% 4 May 2018 в 17:37
поделиться
  • 1
    Спасибо g-makulik и это точно, в чем я нуждаюсь. Его время для повторения моего знания C++:) – user2153006 19 September 2013 в 15:21

Предотвращение DoS победило бы № 2 целей @davebug, которые он обрисовал в общих чертах выше, "Сохраните сайт на скорости, которую не замедляют боты", но не был бы необходимый решать № 1, "Продайте товар к несценариям людей",

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

2
ответ дан Shawn Miller 4 May 2018 в 17:37
поделиться

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

, Если они инициировали предупреждение, перенаправьте каждый запрос к статической странице с как можно меньше DB-IO с сообщением, сообщающим им, на них позволят назад через X минут.

важно добавить, что необходимо, вероятно, только применить это на запросы на страницы и проигнорировать все запросы на медиа (js, изображения, и т.д.).

2
ответ дан Oli 4 May 2018 в 17:37
поделиться

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

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

Эта техника - то, как я предотвращаю спам-роботы на этом сайте. Это работает. Метод, описанный здесь, не смотрит на содержание вообще.

Некоторые другие идеи:

  • Создают , чиновник автоуведомляет механизм (канал RSS? Twitter?), что люди могут подписаться на то, когда Ваш продукт поступает в продажу. Это уменьшает потребность для людей для создания сценариев.
  • Изменение Ваш метод путаницы прямо прежде новый объект поступает в продажу. Таким образом, даже если сценаристы могут нарастить гонку вооружений, они всегда - день позади.
<час>

РЕДАКТИРОВАНИЕ: Чтобы быть полностью ясной, статья Ned выше описывает методы для предотвращения автоматизированной ПОКУПКИ объектов, препятствуя тому, чтобы BOT прошел формы для размещения заказа. Его методы не были бы полезны для предотвращения ботов от анализа экранных данных домашняя страница для определения, когда Нагрудный патронташ Моркови поступает в продажу. Я не уверен предотвращение, КОТОРОЕ действительно возможно.

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

счетчик является скрытым полем, используемым для нескольких вещей: это хеширует вместе много значений, которые предотвращают вмешательство и воспроизведения, и используется для затемнения имен полей. Счетчик является хешем MD5:

  • метка времени,
  • IP-адрес клиента,
  • идентификатор записи записи в блоге, прокомментированной, и
  • секрет А.

Вот то, как Вы могли реализовать это по WOOT.com:

Изменение "секретное" значение, которое используется в качестве части хеша каждый раз новый объект, поступает в продажу. Это означает, что, если бы кто-то собирается разработать BOT, чтобы автокупить объекты, , он только работал бы, пока следующий объект не прибывает в продаже !!

, Даже если кто-то в состоянии быстро восстановить их бота, все другие фактические пользователи уже купят BOC, и Ваша проблема решена!

другая стратегия, которую он обсуждает, к изменение метод ловушки время от времени (снова, измените его, когда новый объект поступает в продажу):

  • классы CSS Использования (рандомизированный, конечно) для установки полей или содержания элемента к display:none.
  • Цвет поля то же (или очень похожий на) фон страницы.
  • расположение Использования для перемещения поля прочь видимой области страницы.
  • Делают элемент слишком маленьким для показа содержавшего поля ловушки.
  • Отпуск видимые поля, но расположение использования для покрытия их элементом затемнения.
  • Использование JavaScript для осуществления любого из этих изменений, требуя, чтобы бот имел полный механизм JavaScript.
  • Отпуск ловушки, отображенные как другие поля, но, говорят людям не вводить что-либо в них.

я предполагаю, что моя полная идея состоит в том, чтобы ИЗМЕНИТЬ ДИЗАЙН ФОРМЫ, когда каждый новый объект поступает в продажу. Или ПО КРАЙНЕЙ МЕРЕ, изменение это, когда новый BOC поступает в продажу.

, Который является что, пара времен/месяц?

при принятии этого ответа Вы дадите мне предостережение на том, когда следующий будет должен?:)

54
ответ дан 2 revs 4 May 2018 в 17:37
поделиться

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

обработка может быть простым уравнением для решения сделанный в JavaScript, если Вы не хотите должными быть требовать JavaScript на своем сайте.

0
ответ дан DaveC 5 May 2018 в 03:37
поделиться

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

Отношения

0
ответ дан Friedrich 5 May 2018 в 03:37
поделиться
  • 1
    Это - то, что я искал. Также хороший пример того, что substitute() на самом деле делает. – shadowtalker 25 June 2014 в 05:40

Метод, который я опишу, имеет два требования. 1) JavaScript осуществляется 2) веб-браузер с допустимым http://msdn.microsoft.com/en-us/library/bb894287.aspx сеанс браузера.

С любым из них Вы "дизайном" не повезло. Интернет создается дизайном для разрешения анонимного клиентского содержания представления. Нет никакого пути вокруг этого с простым HTML. О, и я просто хотел сказать, что простая, основанная на изображении КАПЧА может быть побеждена легко, даже авторы признаются в этом.

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

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

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

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

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

0
ответ дан jwendl 5 May 2018 в 03:37
поделиться
  • 1
    @hadley I' ve обновил мой ответ так, чтобы это can' t использоваться в функциях. – Matthew Plourde 25 June 2014 в 06:57

Я думаю, что игру в песочнице определенного дюйм/с стоит изучить. После того как IP пробежался через порог, когда они поражают Ваш сайт, перенаправляют их к веб-серверу, который имеет мультивторую задержку перед раздаванием файла. Я записал серверы Linux, которые могут обработать открытые 50K соединения с едва любым ЦП, таким образом, не было бы слишком трудно замедлить очень большое количество ботов. Весь сервер должен был бы сделать, хранение соединение, открытое в течение секунд N прежде, чем действовать как прокси на Ваш обычный сайт. Это все еще позволило бы обычным пользователям использовать сайт, даже если бы они были действительно агрессивны, только в немного ухудшенном опыте.

можно использовать memcached, как описано здесь для дешевого отслеживания количества хитов на IP.

0
ответ дан twk 5 May 2018 в 03:37
поделиться
  • 1
    Поскольку я don' t хотят. См. мой комментарий к другому ответу; этому все еще не удается быть устойчивым общим решением. Однако I' m, не ища обходное решение. – shadowtalker 25 June 2014 в 04:10

Используйте JavaScript для динамичной записи информации в страницу. Без механизма визуализации JS, конечно, экранные скребки & боты не смогут считать информацию.

0
ответ дан Meff 5 May 2018 в 03:37
поделиться
  • 1
    Попытка волшебно выяснить, должен ли аргумент быть оценен или не является baaaaaaad идеей. – hadley 25 June 2014 в 06:31

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

0
ответ дан Phil 5 May 2018 в 03:37
поделиться

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

Для покрытия второго шага того, чтобы на самом деле покупать мешок дерьма добавьте простые вопросы. Я предпочитаю вопросы о здравом смысле вопросам о математике, предложенным выше. Вещи как, "Лед является горячим или холодным?" "Муравьи являются большими или маленькими"? Конечно, их должны были бы рандомизировать и вытянуть от бесконечного предоставления вопросов, еще боты могли быть запрограммированы для ответа на них. Этими вопросами, тем не менее, является все еще намного меньше раздражения, чем КАПЧИ.

0
ответ дан jasonkarns 5 May 2018 в 03:37
поделиться
  • 1
    Если it' s пунктуация в Вашем вызове функции, который Вы пропускаете, Вы могли пойти с h..suummarize <- Hmisc::summarize;) – Gregor 25 June 2014 в 04:13

Что относительно того, чтобы использовать Flash?

Да, я знаю издержки использования Flash плюс то, что некоторые пользователи будут заблокированы из покупки bag-o-crap (т.е.: пользователи iPhone), мог бы сделать это вредным, но мне кажется, что Flash предотвратил бы screenscraping или по крайней мере мешал бы.

я неправильно?

Отредактированный для добавления

Что относительно включения нескольких "скрытых" полей на представлениях формируются как то, что я нашел ниже:

На самом деле, лучшая практика, кажется, для использования двух скрытых полей, один с начальным значением, и один без. Это - редкий бот, который может проигнорировать оба поля. Проверьте на одно поле, чтобы быть пробелом и другим, чтобы иметь начальное значение. И скройте их использующий CSS, не путем создания их "скрытыми" полями:

.important {дисплей: ни один;}

не изменяйте следующие два поля.

Боты имеют тенденцию любить поля с именами как 'адрес'. Текст в абзаце для тех немногих редких людей, у которых есть не-CSS способный браузер. Если Вы не волнуетесь по поводу них, можно пропустить его.

В логике для обработки формы, Вы сделали бы что-то как:

, если (address2 == "xyzzy" и address3 =="") {/* хорошо еще для отправки /} {/, вероятно, имеют бота */}

0
ответ дан 4 revs 5 May 2018 в 03:37
поделиться

Мне нравится ответ BradC (использование предложений в статье Ned Batchelder), но я хочу добавить другой уровень к нему. Вы можете рандомизировать не только имена полей, но также и полевые положения и код, который делает их невидимыми .

Теперь, этот последний бит является твердой частью, и я не знаю точно, как сделать это, но кто-то с большим количеством JavaScript и опыта CSS смог понимать это. Конечно, Вы не можете только сохранить те же положения все время, потому что сценаристы просто выяснят, что элемент с положением (x, y) является реальным. У Вас должен был бы быть некоторый код, который изменяет расположение элементов формы относительно других элементов, чтобы переместить их от страницы, наложить их друг на друге, и т.д. Затем запутывают код, который делает это с некоторой случайностью, введенной в него. Автоматически изменяйте путаницу ежедневно, прежде чем новый объект будет сделан доступным. Идея состоит в том, что без надлежащего CSS и реализации JavaScript (и код для чтения расположения страницы, поскольку человек был бы) бот не сможет выяснить, какие элементы показывают пользователю. Ваш серверный код, конечно, знает, какие поля реальны и которые являются фальшивкой.

, Таким образом:

  • имена полей случайны
  • , полевой порядок случаен
  • , полевой код сокрытия сложен
  • , полевой код сокрытия запутывается - случайным образом
  • , случайные факторы автоматически изменяются каждый день серверным кодом

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

0
ответ дан 2 revs 5 May 2018 в 03:37
поделиться
  • 1
    Спасибо, но я предполагаю, что смысл этого вопроса обходит часть, где Вы имеете к , знают , который функционирует конфликт. Я знаю, что можно использовать conflicts, но это могло стать раздражающим, и это doesn' t приводят к устойчивому коду (предотвращение будущее перекрытия). И к вашему сведению это - то, где ... аргумент действительно удобен. – shadowtalker 25 June 2014 в 04:06

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

0
ответ дан user42092 5 May 2018 в 03:37
поделиться

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

первая вещь, которую я сделал бы, делают упорядочивание двух процессов шага. Первый шаг пасовал бы назад GUID при входе IP-адреса. Второй шаг получил бы GUID и сравнил бы его с IP-адресами, которые были зарегистрированы. В сочетании с блокированием IP-адресов, которые массово рассылают сайт (IE: быстрее, чем человек может нажать обновление), эта техника могла остановить спаммеров от успешного создания покупок, таким образом, решив 1 & 3.

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

0
ответ дан Spencer Ruport 5 May 2018 в 03:37
поделиться

Как насчет страницы задержки, где пользователь должен ожидать задержки, которую показывают в изображении?

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

, Если они переходят к странице деталей вне ограничения по времени, они видят дорогой объект, как обсуждено в предыдущих ответах.

0
ответ дан Andy Dent 5 May 2018 в 03:37
поделиться
  • 1
    Я пытаюсь понять Ваш ответ: Вы имеете в виду 2^ {64}-1 бит, или Вы имеете в виду 65 битов длиной? 2^64 довольно много битов. – Stefan 14 January 2014 в 21:53
  • Следуют за денежным потоком. Это намного легче, чем отслеживание стороны IP. Заставьте ботов заплатить слишком много несколько раз (объявление с белым текстом на белом фоне, и все варианты его) уничтожает их экономическую модель быстро. Необходимо подготовить это тщательно и хорошо использовать сильные стороны ботов: их скорость. Вы пробовали несколько тысяч поддельных объявлений на расстоянии в несколько секунд? Если они совершают нападки десять раз, можно пойти еще быстрее. Вы хотите продолжить это, пока они продолжают покупать, поэтому думайте тщательно о моменте дня/неделя, Вы хотите запустить это. Идеально, они прекратят платить, таким образом, можно будет передать случай банку.
  • Удостоверяются, что Ваш сайт полностью сгенерирован, и каждый доступ страницы возвращает различное содержание страницы (HTML, JavaScript и CSS). Парсинг является более трудным, чем генерация, и легко создать - в большем количестве изменения, чем разработчики бота могут обработать. Продолжите изменять содержание и как Вы генерируете его.
  • необходимо знать, как быстрые боты могут адаптироваться к изменениям, которые Вы вносите, и предпочтительно часовой пояс, в котором они находятся. Это - один ботнет или больше, является ими в том же часовом поясе, другом, или действительно ли это - глобальная сеть разработчиков? Вы хотите, чтобы Ваша контратака была синхронизирована право.
  • текущее состояние художественных ботов сделали, чтобы люди ввели капчу (предлагаемый против порно/игр).
  • Делают это непривлекательным для реакции очень быстро.
  • хеши Использования и ловушки, как Ned Batchelder объясняет.

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

0
ответ дан 2 revs 5 May 2018 в 03:37
поделиться

Принятый non-negotiables:

первым экраном должен быть очень простой низкий служебный HTML с легко identiable синглом (мудрый ботом или мудрый людьми) кнопка для нажатия или эквивалентный для указания однозначно, "Я хочу свое Дерьмо". Поскольку мы принимаем худший случай - у Вас есть эквивалент DoS-атаки от комбинации ботов и неботов, все сначала нажимают на сайт (до identfiability). Поэтому давайте раздадим их так быстро, как мы можем от кэшей, мягкого echobots, и т.д.

(Примечание: Что касается wooters, это - то, что происходит так или иначе; это столь же болезненно для пользователей что касается Woot, таким образом, что-либо, что помогает поглотить или смягчить первое экранное приобретение, в интересах всех этих 3 участвующих сторон.)

Затем процесс больше не должен ухудшать для неботов, чем это в настоящее время без дополнительных шагов (или боль) для legits. (Фоновое примечание по текущему дизайну: Текущий wooters обычно будет уже входиться в систему или может войти в систему во время процесса покупки. Новые покупатели должны зарегистрироваться во время покупки. Таким образом, это практически более быстро, чтобы быть уже зарегистрированным и более быстрое все же, чтобы уже быть зарегистрированным.)

Для завершения загаженной продажи по прогрессии экранов транзакции нужно переместиться (скажите 5, плюс или минус, в зависимости от обстоятельств). Победители являются первыми, кто завершает полную навигацию. Текущий процесс вознаграждает ботов (или кто-либо еще), кто завершает всю последовательность 5 экранов наиболее быстро; но вся прогрессия смещается к быстрым ответам (т.е. боты).

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

<час>

, Что, если Woot должны были намеренно отделить процесс организации очередей после первого экрана и подать каждую сессию от той точки в последовательность шагов fixed-minimum-time? Второй экран не был бы даже представлен, пока 30 секунд не передали; после того, как это было отправлено, то же для следующих экранов. Я держал пари, что wooters не имел бы никакой проблемы, если бы им сказали, что после первого экрана они будут ожидать в очереди (который уже верен), который распределил бы нагрузку со временем способом, которая должна взять не более, чем прежде, быть более устойчивой, и справка избавляются от ботов. В этой точке можно добавить часть бота speedbumps упомянутый выше (тонкие вариации в Объектах DOM, и т.д.) Просто преимущество от восприятия, что Woot немного больше контролирует вещи, помог бы.

, Если намного более высокая пропорция хитов начальной буквы BOC могла бы непосредственно перейти в неболее дружественный для бота нестрого ограниченный во времени процесс на их первом хите (или близко к нему) вместо повторения, то у настоящих людей, которые заканчивают ту точку, было бы больше уверенности. Наверняка это было бы менее враждебно, чем текущая ситуация. Это могло бы сократить background-noise-ambient-bot-rate, это идет все время даже под нормальным Woot-прочь на обстоятельства. И боты отложили бы основную страницу и находились бы в очереди друг с другом (и все остальные), где они имеют преимущество.

<час> Хм... "Поточное квартирой" понятие приходит на ум. Интересно, полезен ли шаблон приблизительно? <час> полезное базовое понятие здесь является способностью, после первого экрана, отследить время общей суммы в очереди и смочь корректироваться к стандарту. Как стратегия смягчения бота, у Вас была бы определенная гибкость, чтобы, возможно, уклониться от очень самых ранних сессий на, возможно, 5-10 секунд; выполнение так, вероятно, было бы необнаруживаемым, но приведет к более богатому соединению покупки небота. Я уверен, что у Вас есть статистика, чтобы помочь оценить материал как это после факта. <час> Только для забавы, Вы могли (по крайней мере, для одного wootoff), соединяет Вашего собственного бота, который сочетает лучшие функции, которые Вы видели и затем раздаете его всем накануне. Затем по крайней мере все были бы одинаково вооружены. (Затем утка... поступающая...)
0
ответ дан 6 revs 5 May 2018 в 03:37
поделиться

Почему Вы не блокируете кредитные карты пользователей, которых Вы идентифицируете как ботов?

  1. Публикуют то использование, боты недопустимы на Вашем веб-сайте
  2. , Находят определенную эвристику, которая определяет ботов (это может быть сделано, например, краткосрочным отслеживанием IP или к тому времени, когда это берет их для лапания формы)
  3. , Если кто-то, которого Вы отметили как бот, приобрел товар, заблокируйте его кредитную карту для будущего использования
  4. В следующий раз, когда он пытается сделать покупку, запретить ее, и возвратить объект запасу

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

Ваша загрузка сервера должна уменьшиться со временем, после того как botters разочаровываются в Вас. Другая идея состоит в том, чтобы разделить Ваши страницы между серверами - например, канал RSS на одном сервере, домашняя страница на другом, контроль на другом.

Удача.

0
ответ дан idophir 5 May 2018 в 03:37
поделиться

Я не знаю, насколько выполнимый это:... продолжите наступление.

Фигура, для чего сканируют данные боты. Подайте их данные, которые они ищут, когда Вы НЕ продаете дерьма. Сделайте это способом, которое не побеспокоит или смутит пользователей - людей. Когда боты инициируют фазу два, они войдут в систему и заполнят форму для покупки 100$ roombas вместо BOC. Конечно, это предполагает, что боты не особенно устойчивы.

Другая идея состоит в том, чтобы реализовать случайные снижения цен в течение сумки o загаженный период продаж. Кто купил бы случайную сумку o дерьмо за 150$, когда Вы ОЧЕВИДНО СОСТОЯНИЕ, что это только стоит 20$? Никто, но фанатичные боты. Но затем 9 минут спустя это - доллары за 35$... затем 17 минут спустя это - 9$.или что бы то ни было.

Несомненно, короли зомби смогли бы реагировать. Точка должна сделать их ошибки, становятся очень дорогостоящими для них (и заставить их заплатить Вам для борьбы с ними).

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

29
ответ дан 2 revs, 2 users 94% 5 May 2018 в 03:37
поделиться

Мое решение состояло бы в том, чтобы сделать анализ экранных данных бесполезным путем включения примерно 10-минутной задержки 'ботов и сценариев.

Вот то, как я сделал бы это:

  • Журнал и идентифицируют любых повторных нападающих.

Вы не должны регистрировать каждый IP-адрес в каждый хит. Только отследите один из каждых 20 хитов или около этого. Рецидивист все еще обнаружится в рандомизированном случайном отслеживании.

  • Сохраняют кэш Вашей страницы от приблизительно на 10 минут ранее.

  • , Когда repeat-hitter/bot поразит Ваш сайт, дайте им 10-минутную старую кэшируемую страницу.

Они не будут сразу знать, что получают старый сайт. Они смогут очистить его, и все, но они не будут больше выигрывать гонок, потому что "у настоящих людей" будет 10-минутное преимущество.

Преимущества:

  • Никакая стычка или проблемы для пользователей (как КАПЧИ).
  • Реализованный полностью на серверной стороне. (никакая уверенность в Javascript/Flash)
  • Подавание более старой, кэшируемой страницы должно быть меньшим количеством производительности, интенсивной, чем живая страница. Можно на самом деле уменьшить нагрузку на серверы этот путь!

Недостатки

  • Требуют, чтобы отслеживание некоторых IP-адресов
  • Потребовало хранения и поддержания кэша более старых страниц.

, Что Вы думаете?

159
ответ дан 5 revs 5 May 2018 в 03:37
поделиться

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

я думаю, что другое мышление требуется

  • , не пытаются мешать ботам использовать Ваш сайт
  • , не идут для фиксации, которая сразу работает, играйте в долгую игру

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

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

Это дает Вам запись того, как быстро клиент покупает материал.

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

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

Со временем изображение будет появляться.

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

02: можно также посмотреть на окно времени, используемого для предложений, если окно составит 1 час затем, то некоторые ранние покупатели будут людьми. Человеческая воля редко обновляется в течение 4 часов все же. Если прошедшее время довольно последовательно между, публикуют/купят независимо от продолжительности окна затем, это - бот. Если публиковать/купить время коротко для маленьких окон и становится дольше для больших окон, это - отшельник!

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

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

Обрабатывают заказы в очереди:

, Когда клиент размещает заказ, они сразу получают электронное письмо с подтверждением, говоря им, их заказ размещен в очереди и будет уведомлен, когда это было обработано. Я испытываю такого рода вещь с порядком/отправкой на Amazon, и это не беспокоит меня вообще, я не возражаю получать электронное письмо несколько дней, спустя говоря мне, мой порядок был диспетчеризирован, пока я сразу получаю электронное письмо, говоря мне, что Amazon знает, что я хочу книгу. В Вашем случае это было бы электронное письмо для [1 121]

  1. , Ваш заказ был размещен и находится в очереди.
  2. Ваш заказ был обработан.
  3. Ваш порядок был диспетчеризирован.

Пользователи думают, что они находятся в справедливой очереди. Обработайте свою очередь каждый 1 час так, чтобы обычные пользователи также испытали очередь, чтобы не пробудить подозрение. Только обработайте заказы от бота и учетных записей отшельника, после того как они были в очереди в течение "среднего человеческого времени упорядочивания + x часы". Эффективно уменьшающие боты людям.

11
ответ дан 2 revs 5 May 2018 в 03:37
поделиться

Мы в настоящее время используем последнее поколение подсистем балансировки нагрузки BigIP от F5, чтобы сделать это. BigIP усовершенствовал функции управления трафиком, которые могут определить scrapersand ботов на основе частоты и шаблонов использования даже от среди ряда источников позади единственного IP. Это может затем отрегулировать их, служить им альтернативное содержание или просто отметить их с заголовками или cookie, таким образом, можно определить их в коде приложения.

7
ответ дан ozy 5 May 2018 в 03:37
поделиться
Другие вопросы по тегам:

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