Исходное положение: Сбор логинов подвергает пользователей многочисленным попыткам взлома.
Угроза: Подбор пароля методом лобовой атаки, «социальная инженерия», спамминг.
Несколько лет назад мне позвонили. Мужчина на другом конце провода назвал меня по имени и сказал, что он из моего банка и ему необходимо сверить информацию о моем счете со своими записями. Это сразу же показалось мне подозрительным, но я даже не успел ничего ответить, как он зачитал мне моё полное имя и почтовый адрес. Адрес, который он назвал, был ошибочным, но именно в таком виде он был записан в телефонной книге, что натолкнуло меня на мысль, что он использует общедоступную информацию для того, чтобы выудить из меня другие личные данные. Этот человек просто собирал имена из телефонной книги в целях мошенничества. Следующий пример продемонстрирует риск подобного сбора личной информации.
Сценарий: Проверка аккаунта пользователем
- Эллис подписалась на аккаунт на банковском счете, прошла регистрацию и обнаружила следующий URL:
http://bank.example.com/userid = 2184&account = checking - Сомневаясь, насколько в действительности это приложение банка безопасно, Эллис изменила параметр userid:
http://bank.example.com/userid = 2000&account = checking - Теперь она обнаружила, что видит еще чей-то бухгалтерский реестр аккаунта. Сделав ещё один шаг вперед, она попробовала следующее:
http://bank.example.com/userid = l&account = checking - Она поняла, что это тестовый аккаунт, поэтому попробовала userid = 2, который оказался аккаунтом члена совета директоров банка. В данном примере Эллис обнаружила дефект в приложении и воспользовалась предсказуемой последовательностью идентификатора пользователя для перехода на другие аккаунты.
Сценарий: Король СПАМа
Боб, хорошо известный снаммер, написал программу для ежедневного просмотра тысяч web-страниц всех популярных web-сайтов. На каждой странице его скрипт выделяет имя каждого обнаруженного пользователя аукциона. После сбора нескольких миллионов имен аккаунтов он составляет список и сравнивает каждое имя пользователя с каждым из наиболее распространенных Интернет-провайдеров: hoimail.com, msn.com.juno.com, aol.com, earthlink.net, yahoo.com и так далее.
Затем Боб рассылает электронную почту по всем выбранным адресам и отслеживает, какие из аккаунтов действительны. По завершении он получает более миллиона действительных аккаунтов электронных адресов. Конечно, первое электронное спамерское сообщение, которое он отсылает, - это сообщение с предложением о продаже миллиона реальных электронных адресов всего за $99.
Сценарий: Хакер
Чак - хакер. Он похищает идентификационную и финансовую информацию у ничего не подозревающих людей, пользующихся услугами электронной коммерции. Ему известно, что один web-сайт розничной торговли предоставляет возможность покупателям хранить информацию об их кредитных карточках для упрощения дальнейших покупок. Чак рассчитывает взломать аккаунт одного из клиентов данного сервиса и похитить хранящуюся там информацию о кредитной карточке.
Для этого Чак составляет небольшой список распространенных имен пользователей и паролей и подбирает пароль методом лобовой атаки. Очень скоро выясняется, что web-сайт блокирует доступ к аккаунту, если пользователь допускает ошибку при наборе пароля пять раз подряд. Но существует другой способ выяснения пароля: Вместо подбора множества паролей к одному аккаунту он может попробовать один или два распространенных пароля к многим различным аккаунтам пользователя. Из статистики Чак знает, что, если попробовать подобрать несколько распространенных паролей к достаточному количеству аккаунтов, он получит совпадение.
Теперь единственной проблемой остается сбор имен пользователей. Для этого он пишет скрипт для подписки на аккаунты, используя случайные, но распространенные имена пользователей. Скрипт заполняется, и подается форма подписки, появляется надпись «Извините, этот логин уже используется». Если он получает такое сообщение, скрипт сохраняет данное имя пользователя. Если нет, он заканчивает сеанс связи и пробует зайти под новым именем пользователя.
Через несколько часов скрипт собирает несколько тысяч имен пользователей с этого web-сайта. Данные из составленного списка вводятся в скрипт подбора пароля методом лобовой атаки, который обнаруживает три аккаунта с паролем: asdf. Разумеется, три аккаунта - это не самый большой успех, но теперь у него есть скрипты, он может пользоваться ими каждый день, внося небольшие изменения для достижения лучшего результата.
Контроль над информацией, удостоверяющей личность
Собрав имена пользователей, взломщик сможет собирать электронные адреса для спамминга, пытаться выяснить обманным путем пароли у других пользователей, используя методы «социальной инженерии», метод прямого подбора пароля многочисленных аккаунтов, или обнаружить другие слабые места приложения. Для остановки сбора информации, удостоверяющей личность нужно не показывать имена пользователей и не использовать предсказуемых логинов. Однако работа некоторых web-сайтов полностью основана на личных данных, поэтому вам необходимо использовать многочисленные и разнообразные методы для решения проблемы незащищенности идентификационной информации.
Разрабатывайте систему таким образом, чтобы имя пользователя не являлось первичным ключом к базе данных. Это даст пользователям возможность изменять свои имена без потери важной информации об аккаунте или истории. Одним из методов защиты имен пользователей является создание одного и более вымышленных имен, не использующихся при получении доступа к электронной ячейке. Избегайте последовательных (нумерационных) или шаблонных имен пользователей. При соединении клиентов с внешними (например, проверяющими) аккаунтами не используйте текущие номера аккаунтов в качестве ID пользователя, потому что они часто составляют последовательность, следовательно, взломщик легко может получить доступ к информации.
Внимание: Изменение или использование вымышленных имен пользователей в некоторых случаях может привести к злоупотреблениям. Прежде чем сделать подобную функцию доступной, нужно убедиться, что это подходит для вашего приложения. Например, один web-сайт позволяет изменять имя пользователя, но только один раз в месяц. Это делается, чтобы предотвратить неправильное использование электронной ячейки. Однако ничто не помешает злоумышленникам просто создать новые аккаунты.
Лучший способ предотвратить сбор имен пользователей - просто не показывать их на web-сайте. В случае если это нецелесообразно в вашем конкретном случае, можно попробовать обмануть некоторые скрипты автоматического сбора, изменив шифрование, используемое для написания имен пользователей.
Ещё один важный принцип - это избежание передачи имени пользователя как параметра запроса строки для того, чтобы избежать его появления в истории обозревателя Интернет, в журнале регистрации и заголовках других web-сайтов, ссылающихся на протокол передачи гипертекста (HTTP). Рассмотрите следующие URL, которые могут появляться в web-регистрациях других web-сайтов.
Вот первый пример: www.example.com/inbox.sapx?userid=mburnett&folder=inbox
Второй пример: www.example.com/inbox.aspx?session=3FAC-FF2E-8B10722F-391D
Второй пример лучше, поскольку URL не содержит идентификационной информации.
Способы защиты
- Никогда не используйте электронный адрес в качестве имени пользователя и избегайте любого иного упоминания E-mail.
- Не работайте с директориями общего доступа и «белыми страницами».
- Разрешите пользователям менять имя пользователя, когда необходимо.
- Позвольте клиентам присваивать одно и более вымышленных «ников» для своих аккаунтов.
