Брутфорс cookies, забыли?

    Практически на всех более менее крупных проектах имеется система авторизации пользователей по введенному логину и паролю. Человек вводит логин и пароль и если они соответствуют данным в базе, то человек считается авторизованным, для него генерируется сессия и записывается в кукис. Наверное все вы слышали про брутфорс. Многие помнят о нем и реализуют защиту в виде ограниченных попыток ввода логина/пароля с некоторым интервалом. Но практически все забывают о том, что сессию, запрятанную в кукисе можно также брутфорсить. Более того, при аутентификации вы должны знать логин и пароль, а тут только сессию. Да и шаблон сессии (количество символов, какие символы) злоумышленник может посмотреть, зарегистрировавшись на портале.

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

    1) Поставьте обязательную привязку к IP.
    Если значение сессии из кукиса равно значению сессии из базы, но IP пользователя отличается от IP пользователя записанного в базе (при удачной авторизации), то выводите авторизационную форму с запросом логина и пароля.
    Разумеется нужно дать пользователям возможность эту опцию отключить, т.к. иногда провайдеры меняют внешние IP (при натинге) и за полчаса пользователя может несколько раз кикнуть по такому алгоритму. Но по умолчанию опция должна быть включена! Это сильно ограничит взломщика.

    2) Сессия должна быть как можно больше, ее длина должна варьироваться и состоять она должна из всех возможных символов.
    Чем короче сессия, тем меньше возможных ее вариаций и тем больше вероятность подбора существующей сессии.
    При постоянной длине, взломщик, зарегистрировав себе аккаунт, легко определит под какую длину нужно настроить программу — брутфорс, что минимизирует его время.
    Т.к. взломщик может зарегистрироваться на портале, он может и собрать статистику по сессиям, из каких символов она состоит. Если он видит, что сессия состоит только из строчной латиницы, то внеся эти правила в свою программу он существенно сэкономит время подбора. Добавив только один дополнительный символ вы существенно увеличиваете время взлома!

    3) Подумайте об использовании переменной окружения HTTP_USER_AGENT.
    Если вы запишите в базу информацию о браузере и системе авторизированного пользователя и будете делать проверку на это условие при принятии сессии, то как минимум увеличите время взлома в несколько раз.

    Итог: обнаружить попытку брутфорса сессий разумеется можно, а вот заблокировать IP с которого производится брутфорс нельзя, т.к. этим вы лишите возможности нормально пользоваться сессиями настоящих пользователей с этого IP. Поэтому нам остается только увеличить время брутфорса. При использовании трех моментов указанных выше, вы легко можете увеличить время настолько, что взломщик просто откажется от этой идеи.

    Надеюсь, что эта информация будет полезна веб разработчикам.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +2
      Ага. Удачи вам. А я пока подожду, пока вы 16-32 символьный ключ сессии будете брутать :)
        0
        Знал проекты где использовалась 8-символьная сессия состоящая из одних цифр. Алгоритмы ведь разные бывают. В своей статье я и сказал, что длина сессии не должна быть малой.
        0
        Идентификатор сессии записываемый в куки обычно представляет из себя хеш (md5 например).

        Как вы будете его брутфорсить?
          +2
          Наверное подставляя поочередно символы.
          +3
          думается пока вы будете брутфорсить сессию она устареет и система ее почистит, а вы все так и будете сидеть и брутфорсить и сидеть и сЕдеть
            0
            Обычно сессия меняется при авторизации пользователя через логин и пароль. Я на некоторых форумах не ввожу его месяцами, храня сессию в браузере. Другие думаю также. Если на портале 10 миллионов пользователей, длина сессии не меняется и у взломщика какой-нибудь ботнет, то вероятность подобрать какие-нибудь существующие сессии достаточно велика.
              0
              Насколько я помню, там хранятся печеньки с авторизационной информацией, а не с ID сессии.
                +1
                именно
                +1
                эвы вы не сессию храните на remeber-me куку которая сама по себе должна быть секурной и каждый ее делает по своему и если она легко брутфорсится то это банальный эксплоит конкретной реализации, дефолтное время жизни сессии например для php — 1440 секунд, ну вернее там сложнее но порядок чисел такой
                  0
                  Я сам Perl'щик и не пользуюсь PHP для разработки своих проектов, как и многие другие. В PHP имеется свой метод реализации сессии, но кто запрещает сделать свой метод? При этом и стоит учитывать указанные в статье вещи.
              0
              >Поставьте обязательную привязку к IP.
              Вы забыли, что у более 80% пользователей дома, динамический IP.
                0
                Я указал это в статье и заметил также, что нужно обязательно сделать возможность отключить эту функцию.
                +2
                имхо
                1. менять куку при успешном заходе ( спаролем или без ), обновляя срок жизни
                2. использовать md5(uniqid()) — это 32 символа или 128 бит и 2^128 ~10^38 вариантов

                добавление пары порядков картину не изменит.
                IP может быть динамический или прокси/NAT.
                  0
                  Не обязательно использовать хэш для идентификации юзера. Можно нужную информацию (user id, время, IP, http_user_agent и тд.) зашифровать обычным симметричным шифром, и это сохранить в кукис. Такую печеньку брутфорсить вообще смысла нет.

                  Использовать md5(uid) без соли — грех.
                    0
                    Проблема высосана из пальца, более-менее длинный идентификатор — и всё. Никаких ip, переменной длины, user_agent'ов и прочего не надо — не забивайте голову чушью.
                      0
                      Привязывать сессию к ip | user_agent пользователю надо!
                      Опишу случай есть одно социальное сеть connect, в один прекрасный день смотрел чей то профиль,
                      и выскочил javascript alert('Приветик') я сразу нашел не фильтруемое поле и через 10 минут куки всех
                      кто заходил на мою страницу уже были на моем сервере. Там хранился e-mail, md5(password), PHPSESSIONID
                      в опере поддела куки и вуаля захожу под логином и паролем пользователя. В роди бы и ничего я же не знаю
                      пароль но как бы так нельзя. Мне тогда фантазии не хватило что с этим делать и я просто написал в аську
                      владельцу, он долго морозился и я ему позвонил и сказал где уязвимость. Больше всего поразило то что им
                      понадобилось 4 дня чтобы поставить htmlspecialchars() на то поле.

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

                      Самое читаемое