Ошибка твиттера в IP-адресации и аутентификации - PullRequest
3 голосов
/ 26 февраля 2010

Я создаю веб-приложение, в которое попал в модуль входа. Я собирался реализовать функцию блокировки, используя IP-адрес компьютера, но для динамического IP-маршрутизатора его можно было перезапустить, поэтому я думал сохранить MAC-адрес, который невозможно было найти в Интернете. Тогда я попытался узнать функциональность на GMAIL и Twitter

Случаи, которые я проверял

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

Теперь я пробовал такую ​​функциональность в твиттере, как они это реализовали.

Когда я пытался войти в свою учетную запись Twitter из моего браузера Mozilla примерно 18-20 раз, я был заблокирован на 60 минут. Теперь я попытался проверить, зависит ли эта блокировка от браузера или от сервера. Поэтому я попытался войти из IE, и в первой же попытке я был заблокирован.

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

Затем я, наконец, вернулся к своему ПК и попытался войти в систему с Tweet Deck, то есть со стороннего программного обеспечения, затем получил доступ, затем снова попытался войти в систему из браузера, после чего он все еще показывал меня заблокированным на 60 минут.

ЧИСТАЯ ПАЛУБА ДЕЙСТВУЕТ КАК ПРОКСИ?

Что происходит за сценой, ЭТО ПРОВЕРЯЕТ MAC-адрес, IP-адрес ИЛИ ЧТО ? ХРАНИТСЯ ИНФОРМАЦИЯ О БАЗЕ ДАННЫХ

Ответы [ 2 ]

1 голос
/ 26 февраля 2010

Судя по описанию, приведенному в вопросе, логика блокировки привязана к:

  • IP-адрес или, возможно, его часть, например, его класс C (первые 3 байта IP-адреса.
  • [относительно большое] количество неудачных попыток

Я сомневаюсь, что кто-либо использует MAC-адрес, так как к нему относительно трудно / невозможно добраться, и он предлагает относительно немного преимуществ по сравнению с «идентификацией» IP-адреса (как IP-адреса, так и MAC-адреса могут быть подделаны в любом случае ...)

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

Проблема этого подхода, однако, заключается в том, что он дает «плохим парням» больше шансов в конечном итоге войти; Чтобы снизить этот риск, логика входа в систему также может включать подсчет количества различных IP-адресов, заблокированных в данный момент для данной учетной записи, что позволяет полностью отключить учетную запись, когда это количество достигает порогового значения: «Человек, пять разных IP-адресов несколько раз пытались получить доступ к этой учетной записи ... Давайте заблокируем ее и отправим ее владельцу по электронной почте! ".

Тип логики входа, которую вы должны реализовать для своего веб-приложения, во многом зависит от характера сайта, количества пользователей и т. Д.
Нет ничего плохого в том, чтобы подражать тому, что делают сайты первого уровня, такие как Google и Twitter, но ваша индивидуальная ситуация может предоставить альтернативные возможности или требования.
Например, имея намного меньшее число входов в секунду, вы можете реализовать более изящный набор правил (скажем, правил, которые сопоставляют текущий IP-адрес с IP-адресами, которые ранее / недавно использовались для учетной записи, и в этих случаях будут более терпимыми). Другой пример: если ваши клиенты платят за услугу и / или если их конфиденциальность рассматривается с наценкой, может быть предпочтительнее ошибиться из-за осторожности, то есть [иногда] блокировать законных пользователей, а не разрешать [потенциально] хакеры.

0 голосов
/ 26 февраля 2010

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

Большинство систем входа в систему используют комбинацию функций, все / большинство из которых, конечно, известны злоумышленникам. Некоторые методы включают в себя использование неудачных попыток входа в систему по имени пользователя, паролю, даже если они принадлежат разным пользователям, возрасту файлов cookie, разнообразию файлов cookie, IP-адресу и определению того, используются ли SOCKS или другие прокси. Некоторые даже пытаются использовать какую-либо форму отпечатков пальцев пользователя или устройства, которая поднимает планку для злоумышленников. Обнаружение сопровождается попытками замедления с использованием CAPTCHA или временной блокировки.

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

Google и другие сайты также имеют дело с атаками, проводимыми параллельно на географически распределенных серверах.

...