В этой статье обсуждаются вопросы безопасности на примере веб-входа в систему.Вход в систему — это не просто выражение отправки и написания записи, но вопросы безопасности являются главным приоритетом.
1. Простой пример HTML, чтобы увидеть безопасность информации пользователя
В стандартном синтаксисе HTML поддерживается использование в формах форм.тег для создания атрибута отправки HTTP. В современных веб-логинах распространена форма, подобная следующей:
<form action= "Application/login" method = "POST">
用户名：<input id="username" name="username" type="text"/>
密码：<input id="password" name="password" type="password" />
<button type="submit">登陆</button>
</form>
Когда форма формы отправляет запрос, она получает атрибут имени входного тега в форме и передает его в фоновый режим в качестве параметра в теле HTTP-запроса для проверки входа.
Например, моя учетная запись user1 и пароль 123456, затем, когда я отправлю логин, я отправлю следующий HTTP-запрос в фоновый режим (захваченный инструментами разработчика Chrome или FireFox, необходимо открыть журнал Preserve):
Можно обнаружить, что даже несмотря на то, что поле пароля представляет собой черную точку, машина все равно перехватывает запрос в открытом виде.
2. Передача протокола HTTP напрямую раскрывает поле пароля пользователя.
В процессе сетевой передачи, если он будет перехвачен, это напрямую поставит под угрозу безопасность пользовательской информации.Взяв Fiddler или Wireshark в качестве примера, обнаружено, что захваченные HTTP-пакеты содержат конфиденциальную информацию.
3. Можно ли использовать алгоритм шифрования для обеспечения безопасности пароля?
Веб-интерфейс может зашифровать поле пароля с помощью определенного алгоритма, а затем отправить пароль в качестве содержимого HTTP-запроса.Обычные включают симметричное и асимметричное шифрование.
Симметричное шифрование. Используя технологию кодирования симметричного шифра, оно обеспечивает шифрование и дешифрование файлов с использованием одного и того же ключа шифрования.
Асимметричное шифрование: требуется два ключа, открытый ключ и закрытый ключ. Открытый ключ и закрытый ключ представляют собой пару.Если данные зашифрованы открытым ключом, для их расшифровки можно использовать только соответствующий закрытый ключ; если данные зашифрованы закрытым ключом, может быть использован только соответствующий открытый ключ. используется для расшифровки данных.
3.1 Использование симметричного шифрования
После согласования front-end и back-end шифрование и дешифрование кажутся хорошим методом.Например, front-end использует простой метод смещения строки + инверсии строки (например, так конечно не может быть просто). Затем, если исходный пароль 123456 будет изменен первым:
123456-->456123
Снова инвертировать:
456123-->321654
Тогда такой простой метод, кажется, запутывает исходный пароль и легко восстанавливает его с помощью обратной операции в фоновом режиме. Но у этого есть два недостатка:
1. Внешнее и внутреннее шифрование и дешифрование требуют одновременного изменения кода 2. Внешнее шифрование — это не что иное, как написанное на JS, но JS может быть взломан напрямую для идентификации метод шифрования.
3.2 Обязательно ли безопасно асимметричное шифрование HTTPS?
Асимметричное шифрование предполагает наличие открытого ключа и закрытого ключа.Открытый ключ можно получить по желанию.Закрытый ключ — это локальное хранилище, используемое для расшифровки открытого ключа.Похоже, что шифрование передачи может быть гарантировано с помощью открытого и закрытого ключа механизм, этот принцип.
Но обязательно ли HTTPS безопасен? В HTTP есть два возможных риска: 1. HTTPS может гарантировать, что информация в процессе передачи не будет перехвачена другими, но после тщательного рассмотрения HTTPS является протоколом прикладного уровня, а нижний уровень использует SSL для обеспечения информационной безопасности, но на стороне клиента и сервера зашифрованный текст также может быть перехвачен; 2. Во время передачи HTTPS-пакетов, если клиент злонамеренно направлен на установку веб-сертификата доверия «человек посередине», «атака посередине» в HTTPS также приведет к утечке открытого текста пароля другим пользователям.
4. Вывод такой, что независимо от HTTP или HTTPS пароль должен передаваться в зашифрованном виде
Учитывая, что HTTPS не может обязательно гарантировать информацию о паролях пользователей, вам следует подумать о том, чтобы продолжать защищать пароли поверх прикладного уровня, то есть писать код для управления, не полагаясь на конкретные протоколы.Легче думать об использовании необратимого шифрования и хеширования. Функция столбца MD5 (строка), когда пользователь регистрируется и вводит пароль, значение MD5 (пароль) сохраняется, и MD5 (пароль) сначала выполняется на стороне WEB, а затем пароль передается в фоновом режиме и по сравнению с зашифрованным текстом в базе данных ( PS: функция MD5 имеет такое же значение операции для той же строки, когда указано количество цифр). Преимущества очевидны: 1. Обеспечить безопасность информации о пароле внутри пользовательской базы данных 2. В любом случае в процессе передачи шифротекст пользователя не будет взломан до исходного пароля 3. Простота и эффективность исполнения и кодирования не сложны, различные языки обеспечивают поддержку MD5 для быстрой разработки.
5. Это здорово! Это экономит деньги на HTTPS, верно?
Возвращаясь к примеру в начале: имя пользователя, введенное пользователем: user1, а пароль: 123456, то независимо от того, какой протокол, вы можете видеть, что фактически отправленное сообщение HTTP/HTTPS выглядит следующим образом: Обработка MD5:
Правильно, зашифрованный логин удался. Но пока мы праздновали безопасность пароля, деньги на счету внезапно пропали. Почему это? Хакеры радостно засмеялись: поскольку им не обязательно получать ваш пароль в открытом виде, если вы перехватите зашифрованный текст вашего пароля напрямую и отправите его на сервер, разве не будет то же самое, что войти в систему? Потому что зашифрованный текст в базе данных не совпадает с MD5 (пароль)? Если HTTP-запрос подделан, вход в систему все равно может быть успешным, чтобы получить другие данные или перевести баланс.
Как это сделать?Это не сложно,решений много? На самом деле принципы аналогичны: то есть кеш сервера генерирует случайное поле проверки и отправляет его клиенту, когда клиент входит в систему, это поле передается на сервер для проверки.
5.1 Вариант 1: Код подтверждения
MVC-сцена. Контроллер будет инкапсулировать модель данных в представление.Этот метод подключения существует в сеансе, что позволяет получить доступ к информации в сеансе. Затем мы можем использовать некоторые инструменты генерации проверочного кода с открытым исходным кодом, такие как Kaptcha в JAVA, для хранения и генерации значения проверочного кода и сгенерированного изображения проверочного кода на стороне сервера, закодировать изображение в Base64 и вернуть его на сервер. Просмотрите и декодируйте его в View Base64, загрузите изображение и сравните его при следующем входе пользователя в систему.
5.2 Вариант 2: Токен Токен
Сцены разделения фронтенда и бекенда. Очень популярный режим разработки с разделением интерфейса и сервера значительно повысил эффективность разработки проекта. Обязанности и разделение труда понятны, но поскольку HTTP не имеет состояния (то есть этот запрос не знает содержимого предыдущего запроса), при входе пользователя в систему в качестве кеша значений генерируется случайный токен (например, UUID). в соответствии с именем пользователя в качестве ключа.В Redis, и токен возвращается клиенту, когда клиент входит в систему, проверка будет завершена, а запись кеша в Redis будет удалена. Затем каждый раз, когда токен аутентификации получается с сервера, он действительно может гарантировать, что HTTP-запрос будет отправлен обратно с внешнего интерфейса, потому что токен будет удаляться и сбрасываться после каждого входа в систему, что заставит хакеров попытаться воспроизвести учетную запись. информация о пароле для входа в систему. Если не удается успешно войти в систему.
В общем, даже если я получу зашифрованный текст учетной записи и пароль, я не могу войти в систему, потому что, если запрос не содержит токен фоновой аутентификации, это незаконный запрос.
6. Это непросто! Но не слишком радуйтесь, остерегайтесь подделки данных
Пароль также зашифрован, поэтому хакеры не могут увидеть открытый текст. С добавлением токена процесс входа в систему больше нельзя перехватить и воспроизвести. Но подумайте об этой ситуации, вы делаете онлайн-платеж за определенное сокровище, вам нужны четыре поля учетной записи, пароль, сумма и токен для работы, а затем, когда вы платите, вы платите 1 юань, чтобы купить пакет маленьких сумок с Бесплатная доставка Raccoon просто лапша, после урегулирования определенного сокровища, вы обнаружите, что баланс вашего счета был вычтен на 10000 юаней. Что тут происходит? Потому что даже если хакер не войдет в систему или не будет действовать, он все равно будет уничтожен: при маршрутизации запроса к хакеру пакет данных перехватывается, и тогда нет необходимости входить в систему. В любом случае, пароль учетной записи правильный. , и токен тоже правильный, то данные Изменить поле пакета и уничтожить его, поэтому я изменил деньги на 10 000, а затем передал их на сервер.Как жертва, я наступил на эту яму необъяснимым образом. Но как это решить? По сути принцип аналогичен механизму ЭЦП в HTTPS Прежде всего, что такое цифровой дайджест и цифровая подпись:
6.1 Что такое «цифровой дайджест»
Когда мы загружаем файл, мы часто видим, что некоторые сайты загрузки также предоставляют «цифровой дайджест» загруженного файла, чтобы загрузчик мог проверить, является ли загруженный файл полным или он «точно такой же», как файл на веб-сайте. сервер. Фактически, цифровой дайджест заключается в использовании одной хеш-функции для «переваривания» открытого текста, подлежащего шифрованию, в строку зашифрованных текстов фиксированной длины (128 бит). Эта строка зашифрованных текстов также называется цифровыми отпечатками пальцев. Она имеет фиксированную длину. и разные открытые тексты.Дайджест в зашифрованный текст, результат всегда разный, и одна и та же информация о содержании должна иметь один и тот же дайджест. Следовательно, «цифровой дайджест» может быть более уместно называть «цифровой отпечаток пальца». «Цифровой дайджест» — это фундаментальная причина, по которой HTTPS может гарантировать целостность данных и защиту от несанкционированного доступа.
6.2 Цифровая подпись — естественная технология
Если отправитель хочет отправить сообщение получателю, перед отправкой сообщения отправитель использует хеш-функцию для создания дайджеста сообщения из текста сообщения, а затем шифрует дайджест своим собственным закрытым ключом.Этот зашифрованный дайджест будет использоваться в качестве «подписи» сообщения и отправляется получателю вместе с сообщением.Получатель сначала использует ту же хеш-функцию, что и отправитель, для вычисления дайджеста сообщения из полученного исходного сообщения, а затем использует открытый ключ отправителя для расшифровки цифровая подпись, прикрепленная к сообщению.Если два дайджеста совпадают, то получатель может подтвердить, что сообщение было отправлено отправителем и не было пропущено или изменено!
Это то, что может сделать комбинация «шифрования и дешифрования с асимметричным ключом» и технологии «цифрового дайджеста», которую люди называют технологией «цифровой подписи». В этом процессе процесс создания дайджеста передаваемых данных и его шифрования с помощью закрытого ключа является процессом создания «цифровой подписи», а зашифрованный цифровой дайджест является «цифровой подписью». Таким образом, мы можем подписать логин+MD5(пароль)+токен, упомянутый в предыдущем случае, на стороне WEB, получить поле checkCode и отправить checkCode на сервер, который выполняет исходную подпись данных в соответствии с checkCode, отправленным пользователь и сам. Сравнение выполняется, чтобы подтвердить, были ли данные подделаны в середине, чтобы сохранить целостность данных.
7. Резюме
Казалось бы, простой ВЕБ-вход, на самом деле, также сопряжен с множеством угроз безопасности. Эти процессы улучшения безопасности встречаются в реальном веб-проекте.Вышеприведенный анализ и эволюция - это решения, предложенные при проверке безопасности проекта.Будет много недостатков.Я надеюсь общаться и обсуждать вместе и вместе добиваться прогресса!
Дополнение 1: Существование функций шифрования JS взломано
Спасибо моему другу по саду mysgk за указание на то, что функция шифрования JS была взломана при проверке целостности: описание проблемы:
Если хакер находит алгоритм шифрования, читая исходный код внешнего интерфейса js, означает ли это, что он может создать
А как насчет checkCode, расшифрованного сервером, чтобы обмануть сервер?
Я думал об этом, и это должна быть стратегия, которую используют многие веб-сайты:
Дайджест или зашифрованный алгоритм JS не хранится напрямую в браузере в виде статического файла, но сторона WEB запрашивает сервер, и сервер может решить вернуть соответствующую случайную стратегию шифрования в соответствии со значением случайного токена. и верните его в виде ответа кода JS, в ответе на асинхронный запрос загрузите алгоритм дайджеста JS, чтобы клиент мог динамически загружать стратегию цифрового дайджеста, чтобы гарантировать, что ее нельзя имитировать.
Дополнение 2: MD5 имеет скрытые проблемы
Спасибо садовнику EtherDream за предположение, что MD5 устарел и имеет небезопасные проблемы: Описание проблемы:
Использование MD5, SHA256 для обработки паролей устарело. . . Теперь PBKDF и bcrypt устарели.
1. В этой статье основное внимание уделяется внедрению идей метода.Не обязательно использовать функцию MD5, но можно использовать другие методы. 2. MD5 таит в себе скрытые опасности.Я действительно не особо задумывалась об этом раньше, но очень благодарна садоводам за то, что они указали, что это действительно так. Основная мысль такова:
Для взлома MD5 это на самом деле принадлежит [столкновению]. Например, исходный текст A может генерировать сводку M через MD5. Нам не нужно восстанавливать M до A, а нужно только найти исходный текст B и сгенерировать такую же сводку M.
Пусть хэш-функция MD5 будет MD5(), тогда:
MD5(A) = M
MD5(B) = M
Любой B является результатом взлома.
B может быть или не быть равным A.
Это, вероятно, означает, что если вы перехватите зашифрованный текст, зашифрованный с помощью MD5, вы можете найти «псевдотекст», который не является исходным паролем, но вы сможете успешно войти в систему после шифрования. На CSDN есть очень хороший блог о рисках MD5. Я рекомендую его: Как взломан алгоритм MD5. Из него видно, что функцию MD5 действительно можно «взломать» в обратном порядке, но этот «взлом» только для того, чтобы найти решение после операции MD5 Исходный текст, который дает тот же результат, не является открытым текстовым паролем пользователя. Однако не исключено, что логин будет взломан.Действительно необходимо использовать более полный алгоритм шифрования.Еще раз спасибо.
оригинал:www.cnblogs.com/letcafe
Автор | letcafe Источник | Блог Park
Рекомендуются два оригинальных проекта Springboot+Vue с полными видеообъяснениями, документацией и исходным кодом:
[VueAdmin] Научит вас разрабатывать систему управления разделением интерфейсов и серверов SpringBoot+Jwt+Vue.
- Видео объяснение:woohooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo close непосредственно пропорционально.com/video/bv1afan...
- Полный интерфейс документации по разработке:www.zhuawaba.com/post/18
- Полная документация по разработке:www.zhuawaba.com/post/19
[VueBlog] Полное обучение блог-проекту разделения интерфейса и сервера на основе разработки SpringBoot + Vue.
- Видео объяснение:woohooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo close непосредственно пропорционально.com/video/bv1afan...
- Полная документация по разработке:www.zhuawaba.com/post/17
Если у вас есть какие-либо вопросы, заходите в мой официальный аккаунт【Вопросы и ответы по Java】спросите меня