Как стать автором
Обновить

Комментарии 16

AnyEvent::HTTP мне кажется очень достойная замена LWP, думаю ускорит перебор в десятки раз.
Согласен. Потому я ради интереса и запускал обе этих методики.
AnyEvent лично мне действительно как-то удобнее показалась. Но это вопрос вкуса
В посте мельком упомянуто, были и другие уязвимости? То что расписано, имеет отношение только к брутфорсу паролей.
Мне кажется, основной идеей статьи как раз является получение списка логинов без привлечения к себе лишнего внимания со стороны владельцев сайта.
И уязвимость дополнительного модуля, которая выводила логин по id — это как раз и есть то самое, что и искалось.
использовать отдельные логин и ник — не слишком удобно

Вот никто и не использует. Есть статистика корреляции логина и ника по сайту? Я уверен, что ~65%.

удивительно, что пароль и подтверждение дополнительно проверяются на совпадение еще и на сервере

Действительно, зачем бы? Да и от SQL инъекций можно JavaScript'ом обезопаситься.

Что же касается капчи — она достаточно простая, чтобы не быть помехой.

А что, уже придумали достаточно сложную капчу, чтобы она была помехой?

Я уверен, в этом аудите вы ещё очень-очень много чего упустили.
Значительная часть ников — реальные ФИО.
Отчасти, поскольку так написано в форме регистрации, отчасти, поскольку эта система использовалась в различных официальных и полуофициальных мероприятиях.

SQL-инъекция к сверке пары «пароль-подтверждение» отношения не имеет.
Основная задача этой пары — защитить пользователя от ошибки.
Если человек ввёл данные вручную в форму, JavaScript замечательно справится с валидацией, а если злобный хакер отправляет хитрые запросы, то как-то обрабатывать подтверждение пароля на сервере вообще бессмысленно.

Существование капчи, по моему опыту, замедляет перебор процентов на 30, в зависимости от сложности распознавания, за счёт ошибок ввода. Эта капча же настолько проста, что распознаётся с вероятностью 99,9% довольно быстрыми алгоритмами.
JavaScript может быть отключен или вообще отсутствовать. А иной раз просто не хочется вводить хоть строчку JS на страницу.
Может быть.
Но в конкретном случае проверка была двойная: и на клиентской, и на серверной стороне.
Что и удивляет.
Тоже нормально, если и другие проверки проводятся дважды. Вообще многие некоторые фреймворки так делают по умолчанию — задаёшь одно правило валидации, а обрабатывается оно даже трижды: у клиента (по возможности) — чтобы избежать лишних запросов на сервер и получить моментальный отклик, в приложении — проверить типы, форматы и т. п., при записи в БД — проверка уникальности (при необходимости) или триггерами (редко).
>Слабая политика паролей (нужно запрещать пользователям вводить цифровые пароли)

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

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

Но больше всего я не понимаю «чудиков», которые ограничивают сложность пароля. Чуть ли не саботажем выглядит. А когда при вводе пароля при логине они пишут только, что пароль неверный, но не пишут, что использованы недопустимые символы в нём и какие допустимы — убить карму заминусовать хочется. Например я использую «дежурный» пароль для неважных регистраций, содержащий не только буквенно-цифровые символы. Ладно когда при регистрации мне пишут [a-zA-Z0-9]{3,8}, я их просто опускаю, но когда при логине этого же не пишут, я раза три пробую ввести «дежурный» пароль, тщательно проверяя нажатия, регистр и раскладку, и уж потом думаю: «а может туту дважды „чудики“, попробуюка без „спецсимволов“».
Ни разу не встречал таких чудиков. И это хорошо.
Возможно они это делают на самописных движках, потому как пароли с различными спецсимволами у них не очень хорошо обрабатываются (например с кодировками не сумели разобраться или еще что...). И они придумали «выход» просто не разрешать вводить такие данные
rambler.ru до сих пор (только что проверил) не разрешает использовать спецсимволы в паролях и не сообщает о «запрещенных» символах в пароле при попытке логина.

Движок, конечно, самописный у них :)
А кодировка, по идее, ASCII
— (нужно запрещать пользователям вводить цифровые пароли) — за такое разработчиков обычных сайтов (не связаных с финансами) надо убивать. Пусть пользователь сам решает какой пароль использовать
Среди пользователей слишком много людей, которые не понимают разницы между «123» и «123!»
Обычные сайты в этом не нуждаются, но в этой статье я говорю про довольно крупные сайты с репутацией.
Пароли на почтовый ящик, к которому привязана регистрация на нескольких сервисах, и на каком-нибудь форуме отличаются по критичности. Если я знаю, что туда больше не приду или не вижу смысла скрывать защищенное паролем содержимое, я как пользователь хочу иметь возможность установить такой пароль, который посчитаю нужным. Сайту и другим пользователям от моего слабого пароля вреда не должно быть никакого.

За пост спасибо, но все же — в чем состоял аудит? Насколько этично и, что важнее, правомерно в данном случае проводить аудит (читай, взлом) паролей без ведома и согласия их владельцев?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории