Практически на всех более менее крупных проектах имеется система авторизации пользователей по введенному логину и паролю. Человек вводит логин и пароль и если они соответствуют данным в базе, то человек считается авторизованным, для него генерируется сессия и записывается в кукис. Наверное все вы слышали про брутфорс. Многие помнят о нем и реализуют защиту в виде ограниченных попыток ввода логина/пароля с некоторым интервалом. Но практически все забывают о том, что сессию, запрятанную в кукисе можно также брутфорсить. Более того, при аутентификации вы должны знать логин и пароль, а тут только сессию. Да и шаблон сессии (количество символов, какие символы) злоумышленник может посмотреть, зарегистрировавшись на портале.
Хочу поделиться своими мыслями по поводу того, как организовать защиту.
Сразу оговорюсь, что под словом сессия я буду понимать не процесс, а набор символов, который сохраняют в кукисе для идентификации пользователя в дальнейшем.
1) Поставьте обязательную привязку к IP.
Если значение сессии из кукиса равно значению сессии из базы, но IP пользователя отличается от IP пользователя записанного в базе (при удачной авторизации), то выводите авторизационную форму с запросом логина и пароля.
Разумеется нужно дать пользователям возможность эту опцию отключить, т.к. иногда провайдеры меняют внешние IP (при натинге) и за полчаса пользователя может несколько раз кикнуть по такому алгоритму. Но по умолчанию опция должна быть включена! Это сильно ограничит взломщика.
2) Сессия должна быть как можно больше, ее длина должна варьироваться и состоять она должна из всех возможных символов.
Чем короче сессия, тем меньше возможных ее вариаций и тем больше вероятность подбора существующей сессии.
При постоянной длине, взломщик, зарегистрировав себе аккаунт, легко определит под какую длину нужно настроить программу — брутфорс, что минимизирует его время.
Т.к. взломщик может зарегистрироваться на портале, он может и собрать статистику по сессиям, из каких символов она состоит. Если он видит, что сессия состоит только из строчной латиницы, то внеся эти правила в свою программу он существенно сэкономит время подбора. Добавив только один дополнительный символ вы существенно увеличиваете время взлома!
3) Подумайте об использовании переменной окружения HTTP_USER_AGENT.
Если вы запишите в базу информацию о браузере и системе авторизированного пользователя и будете делать проверку на это условие при принятии сессии, то как минимум увеличите время взлома в несколько раз.
Итог: обнаружить попытку брутфорса сессий разумеется можно, а вот заблокировать IP с которого производится брутфорс нельзя, т.к. этим вы лишите возможности нормально пользоваться сессиями настоящих пользователей с этого IP. Поэтому нам остается только увеличить время брутфорса. При использовании трех моментов указанных выше, вы легко можете увеличить время настолько, что взломщик просто откажется от этой идеи.
Надеюсь, что эта информация будет полезна веб разработчикам.
Хочу поделиться своими мыслями по поводу того, как организовать защиту.
Сразу оговорюсь, что под словом сессия я буду понимать не процесс, а набор символов, который сохраняют в кукисе для идентификации пользователя в дальнейшем.
1) Поставьте обязательную привязку к IP.
Если значение сессии из кукиса равно значению сессии из базы, но IP пользователя отличается от IP пользователя записанного в базе (при удачной авторизации), то выводите авторизационную форму с запросом логина и пароля.
Разумеется нужно дать пользователям возможность эту опцию отключить, т.к. иногда провайдеры меняют внешние IP (при натинге) и за полчаса пользователя может несколько раз кикнуть по такому алгоритму. Но по умолчанию опция должна быть включена! Это сильно ограничит взломщика.
2) Сессия должна быть как можно больше, ее длина должна варьироваться и состоять она должна из всех возможных символов.
Чем короче сессия, тем меньше возможных ее вариаций и тем больше вероятность подбора существующей сессии.
При постоянной длине, взломщик, зарегистрировав себе аккаунт, легко определит под какую длину нужно настроить программу — брутфорс, что минимизирует его время.
Т.к. взломщик может зарегистрироваться на портале, он может и собрать статистику по сессиям, из каких символов она состоит. Если он видит, что сессия состоит только из строчной латиницы, то внеся эти правила в свою программу он существенно сэкономит время подбора. Добавив только один дополнительный символ вы существенно увеличиваете время взлома!
3) Подумайте об использовании переменной окружения HTTP_USER_AGENT.
Если вы запишите в базу информацию о браузере и системе авторизированного пользователя и будете делать проверку на это условие при принятии сессии, то как минимум увеличите время взлома в несколько раз.
Итог: обнаружить попытку брутфорса сессий разумеется можно, а вот заблокировать IP с которого производится брутфорс нельзя, т.к. этим вы лишите возможности нормально пользоваться сессиями настоящих пользователей с этого IP. Поэтому нам остается только увеличить время брутфорса. При использовании трех моментов указанных выше, вы легко можете увеличить время настолько, что взломщик просто откажется от этой идеи.
Надеюсь, что эта информация будет полезна веб разработчикам.