Это всё решается:
— неактивированные аккаунты удаляются раз в N дней;
— ограничение на кол-во регистраций с одного IP в день.
И тогда можно будет написать бота, который целенаправленно будет засорять базу.
Форма регистрации тут самая большая проблема? Тогда уж можно написать бота, который будет создавать какие то блоги или загружать файлы или что-то еще, зависит от вашего проекта.
А через форму регистрации, очень сомневаюсь, что кто-то серьезно засорит вашу базу :)
«Не думаю, что Capcha — хороший способ отсеивать ботов. Если быть точным, то я не против её применения, однако только после того, как пользователь ввел неправильно свой пароль несколько раз.»
Капча — не самое плохое решение против отсеивания ботов. Но я поддерживаю, что на этапе регистрации ей не место. Капчу можно вынести на этап активации аккаунта:
— человек регистрируется с минимальным набором полей;
— ему приходит сообщение на e-mail про активацию аккаунта;
— проходит по ссылке из письма и уже на этом этапе вводит капчу чтобы завершить активацию.
Таким образом убираем лишнее поле при регистрации и защищаемся от ботов не жертвуем капчей.
Я вам честно скажу, что если бы такое предложение было, то оно исходило бы от меня.
И я бы об этом знал :) Поэтому в данном случае вы сделали выводы из воздуха.
Для подтверждения моих слов достаточно запросить скриншот письма у того человека. Я совершенно точно уверен, что он разрушит все ваши подозрения.
Причину спама нужно искать в другом месте. Скорее всего, вам приходило письмо от спам-бота, а вы приняли его за письмо от работодателя и ответили на него.
После этого, ваш e-mail автоматически попал в спам-лист.
Это очень популярная практика для того чтобы собрать актуальную спам-базу с определенного ресурса.
Не хотелось отвечать на вашу провокацию. Но всё таки напишу комментарий чтобы развеять данные слухи.
Мы никому вчера не предлагали у нас заниматься ИБ за «20 тыщ».
Человек написал, что ему приходило предложение о работе в котором было сказано, что его профиль нашли на нашем сайте.
Какое отношение администрация сайта имеет к данному предложению — вообще загадка.
Кроме того, вы ещё и от себя добавили: «что человеку из каталога специалистов по ИБ».
Судя по профилю, человек не занимается ИБ и вы это придумали для полноты картины.
А про «20 тыщ» вообще ниже написал другой человек.
>Я бы не стал пренебрежительно относиться к безопасности, информация пользователей — самое ценное,
Вы не верно поняли мои слова. Я не сказал, что он не нужен. Я сказал, что в данном случае в данном конкретном баге конфига сервера, этот пункт не сыграл бы большой роли.
Естественно, аудит безопасности нужен. И его нужно проводить периодически, иначе никакого смысла от него нет.
В целом, я согласен что лучше пароль не отправлять в открытом виде даже при регистрации. Думаю, мы поправим этот момент.
Но:
>Очень-очень-очень плохо. Ломаешь мыло и всё, на руках пароли от чего только можно.
Если ломанут ваше мыло. То злоумышленнику достаточно пройтись по вашим письмам, узнать где вы регистрировались, а затем тупо по всем сайтам пройтись и сделать ретрив пароля на сломанное мыло.
Уверен, что фэйк или человек приравнивает продажу БД к продаже отдельных аккаунтов (о чём я писал выше). Кстати, по вашему первому линку уже ничего не доступно, там как раз был блог о продаже аккаунта.
И если взглянуть на ситуацию с другой стороны и чисто теоретически предположить, что это не фэйк. То мне было бы непонятно зачем и кто её купит.
Так как:
— пароли все шифрованы с солью;
— у нас доступен публичный каталог, из которого можно «выдрать» ФИО и логин юзеров;
— почта юзера, как правило, указана в аккаунте самого же человека и доступна для просмотра;
— мы только вчера меняли пароли всем юзерам без исключения и для профилактики, изменили соль. Данную профилактику смены паролей и алгоритма хранения паролей мы планируем проводить ежегодно.
В этом году прошло не всё гладко. Мы поняли свои ошибки и больше их не повторим. В будущем, пользователи всегда будут проинформированы заранее и схему смены паролей мы доработаем.
Ну и самое простое — это уголовное преступление. Умный человек палиться не стал бы и уж тем более писать об этом на публичных форумах.
Хочу ещё отметить, что мы очень тесно сотрудничаем с отделом К и в случае чего, очень быстро решили бы данную проблему.
Если поискать по лучше, то будет видно, что продажей аккаунтов на нашем сайте злоумышленники промышляют уже давно (как только сайт стал достаточно популярным).
Схема простая: ломают почту у человека, делает ретрив на неё, получают новый пароль и всё.
Иногда просто регистрируют аккаунты, заполняют всю информацию, получают отзывы и потом уже пробуют продать.
Но такие аккаунты мы всегда блокируем, как только узнаем об этом.
Поэтому мы и сделали возможность привязки аккаунта к мобильному телефону и возможность восстановления пароля только на телефон.
Я не говорил «nginx неверно работал, директива internal глючит». Давайте не будем слова перефразировать — это всегда неприятно. Нам некого винить, кроме самих себя.
Не вижу смысла сейчас ещё раз обсуждать, что мы не правильно использовали данную директиву и какой у нас был конфиг месяц назад. В данном случае это не изменит ситуацию.
Спасибо за советы.
К сожалению, в данном случае пункт 1 большой погоды не сделал бы. А так всё верно.
На будущее мы сделали для себя выводы и выписали необходимые меры, которые постепенно будем реализовывать.
Я постарался в первом сообщении более поверхностно дать ответ и не вдаваться в детали. Так как на хабре есть люди различных профессий и в этом блоге в том числе.
У нас есть определенные требования для всех сотрудников. Если возникает критическая ошибка, то первым делом нужно в любое время дня донести её до меня.
И все критические ошибки мы исправляем сразу же, бросаем все силы на это.
Кроме того, с заявками на ошибки у нас работают тестировщики. Которые должны быть в состоянии отличить критическую ошибку от не критической.
Поэтому не беспокойтесь, сгоряча никто не рубил головы.
— неактивированные аккаунты удаляются раз в N дней;
— ограничение на кол-во регистраций с одного IP в день.
И тогда можно будет написать бота, который целенаправленно будет засорять базу.
Форма регистрации тут самая большая проблема? Тогда уж можно написать бота, который будет создавать какие то блоги или загружать файлы или что-то еще, зависит от вашего проекта.
А через форму регистрации, очень сомневаюсь, что кто-то серьезно засорит вашу базу :)
Капча — не самое плохое решение против отсеивания ботов. Но я поддерживаю, что на этапе регистрации ей не место. Капчу можно вынести на этап активации аккаунта:
— человек регистрируется с минимальным набором полей;
— ему приходит сообщение на e-mail про активацию аккаунта;
— проходит по ссылке из письма и уже на этом этапе вводит капчу чтобы завершить активацию.
Таким образом убираем лишнее поле при регистрации и защищаемся от ботов не жертвуем капчей.
И я бы об этом знал :) Поэтому в данном случае вы сделали выводы из воздуха.
Для подтверждения моих слов достаточно запросить скриншот письма у того человека. Я совершенно точно уверен, что он разрушит все ваши подозрения.
habrahabr.ru/blogs/infosecurity/112237/#comment_3591958
Причину спама нужно искать в другом месте. Скорее всего, вам приходило письмо от спам-бота, а вы приняли его за письмо от работодателя и ответили на него.
После этого, ваш e-mail автоматически попал в спам-лист.
Это очень популярная практика для того чтобы собрать актуальную спам-базу с определенного ресурса.
habrahabr.ru/blogs/infosecurity/112237/#comment_3591958
Пароли всем пользователям менять из-за этого бага смысла не было. Абсолютно.
Мы никому вчера не предлагали у нас заниматься ИБ за «20 тыщ».
Я прекрасно видел из чего вы высосали данную «информацию».
Пруф линк на ваш же блог:
habrahabr.ru/blogs/infosecurity/112173/#comment_3588736
Человек написал, что ему приходило предложение о работе в котором было сказано, что его профиль нашли на нашем сайте.
Какое отношение администрация сайта имеет к данному предложению — вообще загадка.
Кроме того, вы ещё и от себя добавили: «что человеку из каталога специалистов по ИБ».
Судя по профилю, человек не занимается ИБ и вы это придумали для полноты картины.
А про «20 тыщ» вообще ниже написал другой человек.
yellowpress, мечтает о вас )
Вы не верно поняли мои слова. Я не сказал, что он не нужен. Я сказал, что в данном случае в данном конкретном баге конфига сервера, этот пункт не сыграл бы большой роли.
Естественно, аудит безопасности нужен. И его нужно проводить периодически, иначе никакого смысла от него нет.
Но:
>Очень-очень-очень плохо. Ломаешь мыло и всё, на руках пароли от чего только можно.
Если ломанут ваше мыло. То злоумышленнику достаточно пройтись по вашим письмам, узнать где вы регистрировались, а затем тупо по всем сайтам пройтись и сделать ретрив пароля на сломанное мыло.
Итог: сильно легче вам от этого не будет.
И если взглянуть на ситуацию с другой стороны и чисто теоретически предположить, что это не фэйк. То мне было бы непонятно зачем и кто её купит.
Так как:
— пароли все шифрованы с солью;
— у нас доступен публичный каталог, из которого можно «выдрать» ФИО и логин юзеров;
— почта юзера, как правило, указана в аккаунте самого же человека и доступна для просмотра;
— мы только вчера меняли пароли всем юзерам без исключения и для профилактики, изменили соль. Данную профилактику смены паролей и алгоритма хранения паролей мы планируем проводить ежегодно.
В этом году прошло не всё гладко. Мы поняли свои ошибки и больше их не повторим. В будущем, пользователи всегда будут проинформированы заранее и схему смены паролей мы доработаем.
Ну и самое простое — это уголовное преступление. Умный человек палиться не стал бы и уж тем более писать об этом на публичных форумах.
Хочу ещё отметить, что мы очень тесно сотрудничаем с отделом К и в случае чего, очень быстро решили бы данную проблему.
Схема простая: ломают почту у человека, делает ретрив на неё, получают новый пароль и всё.
Иногда просто регистрируют аккаунты, заполняют всю информацию, получают отзывы и потом уже пробуют продать.
Но такие аккаунты мы всегда блокируем, как только узнаем об этом.
Поэтому мы и сделали возможность привязки аккаунта к мобильному телефону и возможность восстановления пароля только на телефон.
>habrahabr.ru/blogs/infosecurity/112237/#comment_3592170
В теории — да. На практике получилось не совсем так.
>Как вы решили эту проблему?
Отказались от internal, заменили на deny. По крайней мере до тех пор, пока полностью не разберемся. Всё таки проблема была срочная.
>при каких же ситуациях internal работал не так, как вам хотелось (т.е. вместо 404 отдавал код?)
Процитирую ответ системного администратора: «При ситуации с internal, прописанном root на фронте + наличие того самого кода на фронтенде.»
habrahabr.ru/blogs/infosecurity/112237/#comment_3592122
Не вижу смысла сейчас ещё раз обсуждать, что мы не правильно использовали данную директиву и какой у нас был конфиг месяц назад. В данном случае это не изменит ситуацию.
У нас всё было примерно так:
location ~* ^/(classes|бла-бла) {
internal;
}
Уточнил только что у системного администратора.
К сожалению, в данном случае пункт 1 большой погоды не сделал бы. А так всё верно.
На будущее мы сделали для себя выводы и выписали необходимые меры, которые постепенно будем реализовывать.
Это верно. Поэтому я и написал «срабатывали не так, как нам хотелось».
>Да ладно вам, покажите часть условия, которое было написано не верно ) людям интересно.
К сожалению, нет такой возможности. В данный момент мы её не используем.
habrahabr.ru/blogs/infosecurity/112237/#comment_3592082
тут больше технических подробностей. Причина только в кривых настройках сервера.
Извиняюсь, если запутал.
Ошибка действительно у нас повторялась только в определенной версии Opera.
Но как я уже сказал, причина одна — криво настроенный сервер. Видимо, я совсем корректно написал про оперу в своем первом сообщении. Извиняюсь за это.
Если дальше вдаваться в детали, то баг был связан с:
sysoev.ru/nginx/docs/http/ngx_http_core_module.html#internal
Директивы nginx при определенной ситуации срабатывали не так, как нам хотелось.
Дальше раскрыть подробности я не могу. Конфиг сервера я показать не могу.
Ошибка была исправлена в декабре месяце.
Подробнее написал тут причину такой задержки:
habrahabr.ru/blogs/infosecurity/112237/#comment_3591958
И все критические ошибки мы исправляем сразу же, бросаем все силы на это.
Кроме того, с заявками на ошибки у нас работают тестировщики. Которые должны быть в состоянии отличить критическую ошибку от не критической.
Поэтому не беспокойтесь, сгоряча никто не рубил головы.