Вообщем от всего что подключаеться через сокеты либо с curlом, отсылает запросы и т.д.
Понимаю что 100% метода не существует.
Кто какие методы использует, что бы уберечь свой проект от подобных вещей?
P.S. Лично мне очень понравился способ авторизации на livejournal. Я его так и не реализовал на php. Благо для автопостинга у них есть API=)
Спустя 4 минуты, 14 секунд (17.11.2009 - 13:21) Gabriel написал(а):
see_man
а что скрытых полей и каптч мало?
а что скрытых полей и каптч мало?
Спустя 3 минуты (17.11.2009 - 13:24) krasilich написал(а):
Как показывает практика, скрытые поля и капчи вообще не влияют на защиту от авторизациии. Максимум защита от дурака.
Спустя 7 минут, 38 секунд (17.11.2009 - 13:32) krasilich написал(а):
Вот примерный алгоритм работы с ЖЖ.
В форме ввода пароля есть скрытое поле, которое генерируеться для каждой авторизации.
Дальше яваскриптом генерируеться определенный хеш на основе пароля и строки из скрытого поля. Этот хеш и передаеться серверу.
(понравилось что серверу не передаеться пароль в открытом виде)
Дальше для каждого действия авторизованого пользователя генерируеться такая же строка запроса, и каждое действие, должно быть подтверждено хешем на основе этой строки и еще чего-то, так и не разобрался чего...
В форме ввода пароля есть скрытое поле, которое генерируеться для каждой авторизации.
Дальше яваскриптом генерируеться определенный хеш на основе пароля и строки из скрытого поля. Этот хеш и передаеться серверу.
(понравилось что серверу не передаеться пароль в открытом виде)
Дальше для каждого действия авторизованого пользователя генерируеться такая же строка запроса, и каждое действие, должно быть подтверждено хешем на основе этой строки и еще чего-то, так и не разобрался чего...
Спустя 23 минуты, 59 секунд (17.11.2009 - 13:56) glock18 написал(а):
Цитата |
В форме ввода пароля есть скрытое поле, которое генерируеться для каждой авторизации. |
такая штука называется CSRF токен обычно.
Цитата |
Дальше яваскриптом генерируеться определенный хеш на основе пароля и строки из скрытого поля. Этот хеш и передаеться серверу. (понравилось что серверу не передаеться пароль в открытом виде) Дальше для каждого действия авторизованого пользователя генерируеться такая же строка запроса, и каждое действие, должно быть подтверждено хешем на основе этой строки и еще чего-то, так и не разобрался чего... |
пароль не передается в открытом виде, зато шифруется с использованием открытого ключем. чуть больше проблем при его определении после перехвата, и всего. ну если это шифрование, конечно. если это именно хэширование, то все гораздо сложнее будет злодею
Спустя 48 минут, 18 секунд (17.11.2009 - 14:44) krasilich написал(а):
Цитата (glock18 @ 17.11.2009 - 12:56) |
пароль не передается в открытом виде, зато шифруется с использованием открытого ключем. чуть больше проблем при его определении после перехвата, и всего. ну если это шифрование, конечно. если это именно хэширование, то все гораздо сложнее будет злодею |
Хеширование, формула md5($auth_str.md5($pass))
glock18, как ты защищаешься от доступа к ресурсу "не из браузера"?
Спустя 53 минуты, 35 секунд (17.11.2009 - 15:38) FatCat написал(а):
Цитата (see_man @ 17.11.2009 - 14:32) |
Вот примерный алгоритм работы с ЖЖ. |
У нас здесь проще и эффективнее. И никаких ботов. Причем не только для авторизованных, алгоритм позволяет писать гостям без каптч и прочих глупостей.
Задавайте правильные вопросы - будут правильные ответы.
Не надо задавать вопрос как защититься от ботов.
Задай вопрос: какие уязвимости есть у ботов. Тогда не будет стоять вопроса защиты, будет стоять вопрос как нанести боту больший ущерб.
Спустя 4 часа, 53 минуты, 8 секунд (17.11.2009 - 20:31) ИНСИ написал(а):
FatCat какие уязвимости есть у ботов?
Спустя 2 минуты, 37 секунд (17.11.2009 - 20:33) twin написал(а):
Тупость.
Спустя 17 минут, 13 секунд (17.11.2009 - 20:51) FatCat написал(а):
Цитата (welbox2 @ 17.11.2009 - 21:31) |
какие уязвимости есть у ботов? |
Десятки мелких и две крупных.
Назову крупные.
Бот - это серверный сценарий. То есть, в интернете на хостинге запускается сценарий. Не с домашнего же тазика хрума гонять, он же стократ медленнее работать будет с домашнего...
Первая уязвимость: бот не может совершать действий с оборудованием - нажимать клавиши на клавиатуре или кнопки мыши. А значит, onclick и подобные обработчики событий бот может только парсить, но не выполнять.
Вторая уязвимость: не может любить входящий трафик. А значит, имеет смысл не банить ботов, а отдавать им десятимеговые страницы сообщений об ошибке.
Спустя 25 минут, 28 секунд (17.11.2009 - 21:16) glock18 написал(а):
Цитата |
Первая уязвимость: бот не может совершать действий с оборудованием - нажимать клавиши на клавиатуре или кнопки мыши. А значит, onclick и подобные обработчики событий бот может только парсить, но не выполнять. |
это самая большая уязвимость - отсутствие js. одно "но" - если кто-то хочет дать пользователям без него пользоваться основными фичами сайта.
вообще достаточно глупо отказываться от жс. я скорее использую его для защиты от ботов, чем буду делать чисто пыховый сайт (как неинтересно).
Спустя 6 часов, 36 минут, 30 секунд (18.11.2009 - 03:53) FatCat написал(а):
Цитата (glock18 @ 17.11.2009 - 22:16) |
одно "но" - если кто-то хочет дать пользователям без него пользоваться основными фичами сайта |
Это частично решаемо: успешно прошедшие проверку (у нас в форуме двойная перекрестная проверка) больше не проверяются, и могут спокойно работать и с отключенным джаваскриптом.
Можно понаблюдать за статусами под аватарками: группа "пользователи" прошла одну проверку, и перешла на проверку вторым алгоритмом; группа "пользователь" прошла обе проверки и больше не проверяется.
Дальше по набору количества сообщений или вручную администратором переходят в другие группы, которые тоже не нуждаются в проверке.