Действительно ли ваш интерфейс входа в систему безопасен?

Java

предисловие

Когда все учатся писать программу, первая строка кодаhello world. Но когда вы начинаете изучать фоновую WEB-технологию, первая функция многих людей — написать логин(Шепотом: не знаю, как другие, во всяком случае я).
Однако, когда я проводил собеседования или общался со многими одноклассниками с небольшим опытом работы, я обнаружил, что хотя многие однокурсники писали в своих резюме:负责项目的登录/注册功能模块的开发和设计工作, но они просто реализуют функциональную логику и не считают слишком много с точки зрения безопасности. Эта статья предназначена в основном для того, чтобы пообщаться с вами.При проектировании интерфейса входа в систему важна не только функциональная реализация, но и то, что нам нужно учитывать с точки зрения безопасности.

Риск безопасности

Взлом грубой силы!

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

Псевдокод выглядит следующим образом:

# 密码字典
password_dict = []
# 登录接口
login_url = ''
def attack(username):
 for password in password_dict:
     data = {'username': username, 'password': password}
       content = requests.post(login_url, data).content.decode('utf-8')
       if 'login success' in content:
           print('got it! password is : %s' % password)

Итак, как мы можем предотвратить эту ситуацию?

код верификации

Некоторые умные студенты подумали об этом, я могу увеличить проверку кода проверки, когда ошибка пароля достигает определенного количества раз! Например, мы установили, что когда пароль пользователя неверен 3 раза, пользователю необходимо ввести код подтверждения изображения, чтобы продолжить операцию входа в систему:

Псевдокод выглядит следующим образом:

fail_count = get_from_redis(fail_username)
if fail_count >= 3:
 if captcha is None:
  return error('需要验证码')
    check_captcha(captcha)
success = do_login(username, password)
if not success:
 set_redis(fail_username, fail_count + 1)

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

Это действительно может отфильтровать некоторые незаконные атаки, но с точки зрения текущей технологии OCR обычным кодам проверки изображений действительно сложно эффективно предотвращать роботов (Мы много страдали от этого). Конечно, мы также можем потратить деньги на покупку схем проверки, таких как скользящая проверка, предоставляемых сторонними компаниями, но они не на 100% безопасны и могут быть взломаны (тяжелый урок).

Ограничения входа

В это время другой одноклассник сказал, что тогда я могу напрямую ограничить операцию входа в систему ненормальных пользователей.Когда ошибка пароля достигает определенного количества раз, вход пользователя будет отклонен напрямую, и пользователь будет восстановлен через определенный период времени. . Например, когда мы настраиваем учетную запись для входа в систему при 10 ошибках, все операции входа в учетную запись будут отклонены в течение 5 минут.

Псевдокод выглядит следующим образом:

fail_count = get_from_redis(fail_username)
locked = get_from_redis(lock_username)

if locked:
 return error('拒绝登录')
if fail_count >= 3:
 if captcha is None:
  return error('需要验证码')
    check_captcha(captcha) 
success = do_login(username, password)
if not success:
 set_redis(fail_username, fail_count + 1)
    if fail_count + 1 >= 10:
     # 失败超过10次，设置锁定标记
     set_redis(lock_username, true, 300s)

гм, это действительно может решить проблему взлома пароля пользователя. Однако это повлечет за собой еще один риск: хотя злоумышленник не может получить информацию о пользователе веб-сайта, это может привести к тому, что все пользователи нашего веб-сайта не смогут войти в систему!
Злоумышленнику просто нужно перебрать все имена пользователей в бесконечном цикле (Даже если нет, случайный выбор в порядке) для входа в систему, то эти пользователи будут заблокированы навсегда, что не позволит обычным пользователям войти на веб-сайт!

Ограничение IP

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

Псевдокод выглядит следующим образом:

ip = request['IP']
fail_count = get_from_redis(fail_ip)
if fail_count > 10:
 return error('拒绝登录')
# 其它逻辑
# do something()
success = do_login(username, password)
if not success:
 set_redis(fail_ip, true, 300s)

Это тоже может в какой-то степени решить проблему.На самом деле многие операции по ограничению тока выполняются для IP.Например,модуль ограничения тока niginx может ограничивать количество посещений IP в единицу времени.
Но здесь еще есть проблема:

  • Например, многие школы и компании теперь используют один и тот же экспортный IP-адрес.Если вы напрямую ограничиваете IP-адрес, другие обычные пользователи могут быть убиты по ошибке.
  • Теперь, когда существует так много VPN, злоумышленники могут переключать VPN для атаки после того, как IP-адрес заблокирован.

Проверка телефона

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

  1. Когда пользователь вводит пароль более 3 раз, от пользователя требуется ввести проверочный код (Лучше использовать проверку свайпом)
  2. Когда пользователь вводит пароль более 10 раз, появляется всплывающее окно подтверждения мобильного телефона, и пользователю необходимо использовать код подтверждения мобильного телефона и двухфакторную аутентификацию пароля для входа в систему.

Защита кода подтверждения мобильного телефона — это еще одна проблема, которая не будет здесь подробно раскрываться Я расскажу о том, что мы сделали для защиты кода подтверждения, когда у нас будет время в будущем.

Псевдокод выглядит следующим образом:

fail_count = get_from_redis(fail_username)

if fail_count > 3:
 if captcha is None:
  return error('需要验证码')
    check_captcha(captcha) 
    
if fail_count > 10:
 # 大于10次，使用验证码和密码登录
 if dynamic_code is None:
     return error('请输入手机验证码')
    if not validate_dynamic_code(username, dynamic_code):
     delete_dynamic_code(username)
     return error('手机验证码错误')

 success = do_login(username, password, dynamic_code)
    
 if not success:
     set_redis(fail_username, fail_count + 1)

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

Атака «человек посередине»?

Что такое атака «человек посередине»

***Атака «человек посередине» (сокращенно MITM)***, проще говоря, в процессе коммуникации между A и B злоумышленник получает или модифицирует A посредством прослушивания, перехвата и т. д. Связь с B.

Возьмите каштан:小白давать小黄Чтобы отправить экспресс, по пути нужно пройти через пункт А экспресса.小黑Просто спрячьтесь в курьерской точке А или просто откройте курьерскую точку Б, чтобы притвориться курьерской точкой А. Потом украдкой разобрали小白давать小黄курьер, чтобы увидеть, что там. можно даже поставить小白Курьер останется, а я упакую коробку, как волосы, и отправлю小黄.

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

HTTPS

Самая простая и эффективная операция по предотвращению атак «человек посередине» — заменить HTTPS и изменить все HTTP-запросы на веб-сайте, чтобы принудительно использовать HTTPS.

***Почему HTTPS защищает от атак типа «человек посередине»? ***
HTTPS фактически добавляет протокол SSL/TLS к протоколам HTTP и TCP для обеспечения безопасной передачи данных. По сравнению с HTTP, HTTPS в основном имеет следующие характеристики:

  • Шифрование контента
  • целостность данных
  • Аутентификация

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

зашифрованная передача

В дополнение к HTTPS мы также можем вручную зашифровать передачу конфиденциальных данных:

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

разное

В дополнение к тем, о которых мы говорили выше, на самом деле есть много других рабочих мест, которые можно рассмотреть, например:

  • Журнал операций, пользователю необходимо записывать журналы для каждого входа в систему и конфиденциальных операций (включая IP-адрес, устройство и т. д.).
  • Ненормальная работа или напоминание о входе в систему, С помощью приведенного выше журнала операций мы можем создавать напоминания о рисках на основе журнала.Например, когда пользователь ненормально входит в систему, меняет свой пароль или ненормально входит в систему, он может отправить текстовое сообщение, чтобы напомнить пользователю.
  • отклонять слабые паролиПри регистрации или смене паролей пользователям не разрешается устанавливать слабые пароли
  • Предотвращение обхода имен пользователейНекоторые веб-сайты запрашивают, существует ли имя пользователя после ввода имени пользователя во время регистрации. Существует риск утечки всех имен пользователей сайта (пройти через интерфейс), который должен быть ограничен во взаимодействии или логике
  • ...

постскриптум

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

Статьи по Теме

Ваш SMS-интерфейс действительно безопасен?

Расширенное чтение

Графический протокол SSL/TLS — веб-журнал Жуана Ифэна
HTTPS - Wikipedia
Man-in-the-middle attack - Wikipedia

[Важно] Пожалуйста, укажите источник для перепечатки: https://juejin.cn/post/6859214952704999438

- END -
Категории