Код
"SELECT * FROM users WHERE login = '" + login + "' AND pass = '" + pass + "';"
имеет сразу несколько серьёзных проблем безопасности и делает приложение уязвимым для множества атак. Ниже — обзор того, какие категории атак он допускает (в понятном, но не эксплуатативном виде), какие последствия это даёт, а также практические безопасные способы переписать аутентификацию.

1) Что конкретно опасно в этом коде

Конкатенация пользовательского ввода в SQL — классическая уязвимость SQL-инъекции.Вероятно, пароли хранятся в БД в открытом виде (поскольку сравнивают поле pass напрямую) — это критично.SELECT * — может возвращать больше данных, чем требуется.Скорее всего, отсутствуют: проверка/ограничение ошибок, ограничение прав БД-пользователя, защита от брутфорса.

2) Типы атак, которые допускает такой код (высокоуровнево, без пошаговых эксплойтов)

SQL-инъекция (в целом). Позволяет манипулировать SQL-запросом, изменить логику WHERE, прочитать/изменить/удалить данные, выполнять нежелательные запросы.
Подвиды SQL-инъекции:Тавтологические/авторизационные обходы: злоумышленник может изменить условие так, чтобы оно всегда было истинно (что позволяет обходить аутентификацию).Выборочные (UNION-подобные) и ошибка-ориентированные инъекции: используются для вытаскивания данных из других таблиц.Слепая (boolean-based / time-based) инъекция: когда сервер не выдаёт прямой результат, атакующий получает информацию побитово по ответам сервера/времени ответа.Множественные/стековые запросы (если СУБД/драйвер разрешают) — позволяют выполнить несколько операторов.Перехват и брутфорс паролей
Если пароли хранятся в открытом виде, компрометация БД = компрометация всех паролей.Отсутствие ограничений на число попыток позволяет брутфорс и credential stuffing.Информационное раскрытие / разведка
Ошибки SQL и подробные сообщения могут раскрывать схему БД, имена таблиц/полей, признаки используемой СУБД.Вторичные уязвимости
Если полученные из БД данные потом выводятся в HTML без экранирования — возможен XSS.Если входные данные используются в shell-командах или LDAP/OS-командах — возможны другие инъекции.Тайминговые/криптографические атаки
Если сравнение паролей выполняется небезопасно (не-константное время), возможны утечки информации через тайминговые атаки.

3) Влияние / последствия успешной атаки

Полный компромисс БД: чтение всех пользователей и паролей, персональных данных и т. п.Аутентификация обходится — злоумышленник получает доступ к аккаунтам.Модификация данных, создание/удаление записей.Утечка резервных данных и последующие массовые взломы (если пароли не хешированы).Возможный RCE/эскалация привилегий (в зависимости от окружения).

4) Как защищать — общие принципы

Никогда не конкатенировать пользовательский ввод в SQL.Хранить пароли только в виде криптографически безопасных хэшей (Argon2id / bcrypt / scrypt), с уникальной солью для каждой записи.Использовать параметризованные запросы (prepared statements) или ORM с безопасной привязкой параметров.Минимизировать привилегии учётной записи БД, которую использует приложение (только SELECT/UPDATE/INSERT для нужных таблиц).Ограничивать выдачу подробных SQL-ошибок пользователю — логировать их на сервер.Вводить защиту от брутфорса: rate limiting, задержки, блокировка аккаунта, CAPTCHA.Использовать HTTPS, HSTS, безопасные cookie (HttpOnly, Secure, SameSite), и многофакторную аутентификацию (MFA).Включить мониторинг, WAF и аудит запросов/логов.Проводить проверку и тестирование на уязвимости (SAST/DAST/пентест).

5) Практические безопасные варианты реализации аутентификации
Ниже — безопасная логика в общем виде:

На этапе регистрации: хешировать пароль безопасным алгоритмом и сохранять только хэш и соль (если алгоритм требует), НЕ хранить plain.На этапе логина:
Получить запись пользователя по логину (параметризованный запрос).Если запись есть — проверить введённый пароль с сохранённым хэшем с помощью безопасной функции верификации (которая делает внутренний соль/итерации).Выполнить проверку учёта блокировок/locked/disabled и, при успехе, создать сессию/токен.

Примеры безопасного подхода (псевдо/безопасный код):

PHP (PDO) + хэширование (password_hash / password_verify):

Подготовленный запрос: SELECT id, password_hash FROM users WHERE login = :loginЗатем password_verify($pass, $row['password_hash'])Библиотека password_hash поддерживает bcrypt / Argon2 на современных PHP.

Python (psycopg2) + argon2:

cursor.execute("SELECT id, password_hash FROM users WHERE login = %s", (login,))Использовать библиотеку argon2-cffi для сравнения: argon2.PasswordHasher().verify(hash, password)

Java (JDBC) + PreparedStatement:

PreparedStatement stmt = conn.prepareStatement("SELECT id, password_hash FROM users WHERE login = ?");stmt.setString(1, login);Результат -> проверка хеша с библиотекой BCrypt/Argon2.

Node.js (pg/mysql2) + bcrypt/argon2:

client.query('SELECT id, password_hash FROM users WHERE login = $1', [login])await argon2.verify(hash, password)

(в каждом примере важны подготовленные запросы и отдельная проверка хеша на сервере — никогда не включайте пароль в SQL для сравнения)

6) Дополнительные меры и хорошие практики

Не показывайте детальные ошибки аутентификации («internal error», «SQL error»). Для пользователя — общие сообщения («неверные учётные данные»).Логируйте подозрительную активность и включите алерты.Применяйте принцип наименьших привилегий для БД-пользователя (нет прав DROP/SHOW/CREATE, если не нужны).Отключите возможность выполнения нескольких SQL-операторов одним запросом, если драйвер/СУБД позволяет.Внедрите MFA и защищённые сессионные токены (JWT с коротким сроком или серверные сессии).Регулярно обновляйте зависимости, СУБД и используемые библиотеки хеширования.Рассмотрите использование специализированных провайдеров аутентификации (OAuth/OpenID Connect, внешние Identity-платформы) при необходимости.

7) Заключение — конкретные шаги, которые нужно выполнить прямо сейчас

Перейти на параметризованные запросы (prepared statements) для любых SQL-запросов с вводом пользователей.Пересмотреть хранение паролей — если пароли в БД не хешированы, срочно потребовать смены пароля и заменить хранение на Argon2/bcrypt.Отключить показ SQL-ошибок пользователям; добавить логирование.Ввести защиту от брутфорса (rate-limiting, блокировки, CAPTCHA) и MFA.Провести аудит привилегий БД и ограничить права приложения.Выполнить тестирование безопасности (сканирование/пентест).

Если хотите, могу:

Показать конкретные безопасные примеры кода для языка/стека, который вы используете (PHP/Java/Python/Node/C#).Сформулировать чек-лист по исправлению уязвимости и по hardening-аутентификации.