Замість капч від ботів є й інші засоби захисту, наприклад "приховані поля" - поля, які не відображаються користувачу і повинні приходити порожніми. Робот ж може їх заповнити і форма не пройде перевірку.
Цей захист обходиться елементарно - треба один раз налаштувати робота на заповнення потрібних полів і все.
Мені придумав новий спосіб захисту, заснований на тому, що роботи не можуть виконувати жаваскріпт.
Суть в наступному:
одне з полів робиться прихованим і в нього пишеться якесь сміття. На сторінку поміщається жаваскріпт, який підміняє це сміття в якийсь момент - можна по таймаут.
В результаті за значенням цього поля можна буде визначити, робот чи заповнював сторінку.
Як можна обійти запропонований спосіб захисту? І які у нього є недоліки?
Оновлення: В результаті жвавої дискусії стають зрозумілими такі особливості підходу:
1. Якщо у користувача відключений жаваскріпт - то все погано (предлгаю тоді користувачеві видавати капчу)
2. Бот, що обходить дану захист повинен бути вбудований в браузер і емулювати дії користувача - в тому числі робити затримку перед відправкою
Обновленіе2:
Ще одна ідея, яка може ускладнити ботам життя - динамічна генерація імен полів. Як можна обійти її?
Думаєте налаштувати робота підміняти сміття набагато складніше чим не запонлять приховані поля?
Для цього йому буде необхідно виконати жабаскріпт.
Можна зробити такий скрипт, який буде формувати ключ для перевірки динамічно + в виконання скрипта можна вставити затримку секунд 5.
Бот, що виконує жабаскріпт - це зовсім нетривіальний бот.
тема про альтернативу капчі настільки древня, що вже нудно в ній брати участь. всі варіанти вже придумані, випробувані і відкинуті. капча в загальному випадку - ідеальний варіант, тому що користувач до неї звик, вона дає відносно низький рівень збоїв і досить високий рівень захисту.
треба розуміти, що від бота, який націлений на конкретно ваш сайт, ви таким чином (і ніяким іншим, в загальному) на 100% не захиститеся. будь-яка капча може бути пробита за участю людини, а погана капча може бути пробита просто на автоматі. будь яваскрипт, як і будь-який інший не міняється в часі алгоритм, може бути легко розібраний нападаючим і семуліровать. у нормального користувача яваскрипт може бути відключений.
>> як і будь-який інший не міняється в часі алгоритм
У підсумку для роботи боту доведеться відкривати браузер, емулювати всі натискання, та ще й робити затримку перед відправкою.
>> треба розуміти, що від бота, який націлений на конкретно ваш сайт, ви таким чином (і ніяким іншим, в загальному) на 100% не захиститеся
З цим згоден. Але можна зробити розробку такого бота занадто дорогий.
>> капча в загальному випадку - ідеальний варіант
Капча завжди напружує. Ну, по крайней мере, особисто мене - всі форми капчі захистити не можна - користувач просто втече з сайту.
Алгоритм зміни поля може постійно змінюватися за рахунок динамічної генерації.
Ось приклад: Алгоритм представимо у вигляді потоку управління + граф залежностей за даними. У межах цих двох обмежень можна перемішувати команди, імена змінних та інше. При цьому в цей код додані деякі контрольні змінні, з яких обчислюється результуючий ключ.
Щоб витягнути правильно все потрібні значення - потрібно практично повністю написати інтерпретатор.
Якщо в цей код додати деякі додаткові функції, пов'язані з обчисленням часу або чогось такого. (Аж до Аякса, який буде тягнути щось ще) - залишиться тільки один размуний варіант злому - виконати js в браузері
Значить будуть виконувати в браузері. Це не така вже й велика проблема, якщо треба.
Яка різниця, у вигляді чого представляти алгоритм і що куди заважати? Якщо алгоритм реалізований і знаходиться перед очима - його не викликає особливих проблем скопіювати на будь-яку мову. Контрольні змінні виймаються тупим парсинга без проблем. "Час і чогось таке" теж можна обчислювати на будь-якій мові - сервер же якось обчислює те ж саме для перевірки. Завантаження псевдослучайного JS-коду Аяксом вже ближче до теми; але по суті, це та ж капча, тільки не для людини, а для інтерпретатора JS. І перемогти її нітрохи не складніше, ніж капчу звичайну, скоріше навіть навпаки.
>> Якщо алгоритм реалізований і знаходиться перед очима - його не викликає особливих проблем скопіювати на будь-яку мову. Контрольні змінні виймаються тупим парсинга без проблем.
Суть того, що я привів в тому. що контрольні змінні замішані разом зі сміттєвими, следуюі в довільній послідовності і мають довільні імена.
Це неможливо розпарсити.
>> це та ж капча, тільки не для людини, а для інтерпретатора JS.
В тому-то і справа - нехай бот бореться із захистом, а не користувач сайту
Ну задіє ботопісатель JS, матюгнувшісь, далі-то що? Хакан це буде набагато швидше, ніж капча через сервіс. Капча Хакан близько 30 сек. в середньому, ця штука буде Хакан за частки секунди. Один раз буде написана бібліотека, яка буде розпродана всім спамерам - і все.