Способы предупреждения угроз по классам атак

1 Аутентификация (Authentication)

1.1 Подбор (Brute Force)

Подбор паролей работает по алгоритму: задали вариант комбинации логин+пароль => ждем ответ => если не получилось, то пробуем другой вариант, иначе ответ найден. Способы задания комбинаций различны – от использования словарей до простого перебора все вариантов. В любом из случаев всё упирается во время подбора. Если подбор можно осуществить за сутки-другие, то его используют, а если на это уйдет не одна неделя, то за этот период кто-нибудь обязательно заметит такую нездоровую активность относительно объекта атаки. Значит решение должно быть в замедлении скорости подбора. Тут возможны следующие варианты: Искусственно замедлять ответ сервера при проведении аутентификации. Если сервер может провести эту операцию за пару миллисекунд, то следует добавить задержку в 1-2 секунды. Минусом такого подхода является то, что пользователям могут быть неприятны подобные задержки.

Другой вариант ориентирован на «прозрачность» защиты для обычных пользователей. Он заключается в том, что пользователю дается ограниченное число попыток ввода неверных данных для аутентификации, после этого учетная запись и / или компьютер пользователя блокируются от проведения процедуры аутентификации. Блокировка может накладываться как на постоянное время (до анализа ситуации обслуживающим персоналом), так и на некий интервал времени 5-10-30-60 минут. Второй способ более предпочтителен из-за своей «прозрачности», а так же тем, что для системы атаки потребуется более интеллектуальный механизм, который будет анализировать ситуацию блокировки. Минусом этого способа является то, что он может быть использован для атаки вида DoS – таким образом можно заблокировать либо всех пользователей от входа в систему, либо часть компьютеров.

1.2 Недостаточная аутентификация (Insufficient Authentication)

При разработке / настройке / установке систем не следует полагаться на принцип «никто же кроме меня этого не знает». Следует использовать блокировку файлов / каталогов от просмотра как правами на файлы (тогда никто не сможет через браузер увидеть эти объекты), так и требованием прохождения процедуры аутентификации (настраивать веб-сервер на подобное требование или же систему). В скриптовых системах (на базе PHP/Perl и т.п.) это можно решить созданием подключаемой функции( или внешнего модуля), которая будет обязательно запускаться перед выполнением каждого скрипта и проверять доступность ресурса для текущего пользователя.

1.3 Небезопасное восстановление паролей (Weak Password Recovery Validation)

Так как зачастую нельзя полностью отказаться от функции восстановления паролей, то тут надо искать компромисс между возможной кражей учетной записи и удобством для конечного пользователя, который не приучен запоминать пароли. На данный момент нет ни одного хорошего варианта решения, кроме как требования использовать в качестве почтового адреса в системе почтовый адрес, который не располагается на бесплатных почтовых системах. Иначе нет никакой уверенности в том, что такой ящик через месяц, год не будет зарегистрирован / украден другим человеком. Если же рассматривать вариант, что атакующий может прослушивать трафик сервера, тогда не спасут и подобные почтовые адреса.

2 Авторизация (Authorization)

2.1 Предсказуемое значение идентификатора сессии (Credential/Session Prediction)

На заре использования сессий зачастую в качестве идентификатора использовали некие элементарные функции от времени или чего-нибудь подобного. На данный момент в механизмах организации сессий существуют нормальные методики формирования уникального идентификатора сессии. Эти методики (функции) и следует использовать при разработке. Свои механизмы следует создавать только в том случает, если у вас есть аппаратный генератор случайных чисел (ГСЧ). Если я верно помню курс теории случайных процессов и методики построения программных ГСЧ, то они не смогут обеспечить «хорошую случайность». Вариант, когда разработчик подобной системы может самостоятельно провести анализ надежности используемого программного ГСЧ не рассматриваю. Так же следует в сессии обязательно запоминать адрес пользователя и периодически сравнивать его с текущим. В случае обнаружения несоответствия такой сеанс следует уничтожать, а пользователя отключать от системы. В журнале следует делать запись об обоих адресатах и пользователе.

2.2 Недостаточная авторизация (Insufficient Authorization)

См. решение для 1.2. С учетом того, что могут использоваться роли, следует заметить, что нельзя хранить на стороне пользователя какие-либо данные в cookie, кроме как номера сессии. Все данные от пользователя в первую очередь следует воспринимать критично. Особенно идентификатор сессии.

2.3 Отсутствие таймаута сессии (Insufficient Session Expiration).

Тут говорить не о чем. Разработчику надо знать про таймауты и выбирать нужный режим работы сессии исходя из целей системы.

2.4 Фиксация сессии (Session Fixation)

См. решение для 2.2.