Проанализируйте следующий SQL-запрос: SELECT * FROM users WHERE username = 'admin' OR '1'='1'; — объясните уязвимость, способы её эксплуатации и рекомендации по защите от SQL-инъекций

26 Июн в 09:21
34 +1
0
Ответы
1
Кратко — это классический пример SQL-инъекции. Разбор, эксплуатация и защита.
Что происходит
- Запрос: SELECT * FROM users WHERE username = 'admin' OR ′1′=′1′'1'='1'1=1;
Выражение ′1′=′1′'1'='1'1=1 всегда истинно, значит WHERE всегда выполняется и СУБД вернёт все/первую запись(и). Если приложение считает "нашли строку — авторизация успешна", обход аутентификации происходит.
Способы эксплуатации
- Прямой обход логина: в поле username вставить payload типа
' OR ′1′=′1′'1'='1'1=1 --
(двоеточие/комментарий зависит от СУБД: `--`, `#`, `/* ... */`). Это заставит WHERE быть всегда истинным и часто даст доступ.
- Получение данных (UNION): если результат выводится пользователю, можно добавить `UNION SELECT ...` для чтения других таблиц.
- Извлечение через ошибки: подставить выражения, вызывающие ошибку с содержимым полей (error-based).
- Байн/временные атаки: использовать `SLEEP()`/`WAITFOR DELAY` для поразрядного/побитового извлечения (blind SQLi).
- Деструктивные команды: в СУБД, допускающих несколько команд, можно вставить `; DROP TABLE users;` и т.п. (редко, если разрешены множественные запросы).
Риски
- Обход аутентификации, кража/изменение/удаление данных, получение привилегий, длительные утечки данных, компрометация сервера.
Рекомендации по защите (в порядке приоритетности)
- Использовать параметризованные запросы / подготовленные выражения (prepared statements). Пример (PHP PDO):
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$username]);
- Использовать ORM или API, которые сами параметризуют запросы.
- Белый список и валидация входа: проверять формат и длину полей (например, допустимые символы для username).
- Экранирование — только как запасной вариант; предпочтительнее параметризация.
- Ограничение прав БД: аккаунт приложения — минимальные привилегии (только SELECT/INSERT/UPDATE, если нужно).
- Не показывать подробные ошибки SQL пользователям; логировать их в безопасном месте.
- Ограничение результата: явно перечислять нужные столбцы вместо `SELECT *`.
- Использовать WAF/IDS для блокировки известных payload’ов и аномалий в запросах.
- Мониторинг и аудиты: лог запросов, поиск шаблонов вроде `' OR '1'='1'`.
Как проверить наличие уязвимости
- Попробовать безопасные тестовые payload’ы в контролируемой среде: ' OR ′1′=′1′'1'='1'1=1 --
- Использовать автоматические сканеры/фреймворки (sqlmap, Burp Suite) в соответствии с политикой тестирования.
Коротко: никогда не формируйте SQL конкатенацией строк из входных данных — используйте параметры, ограничьте права и валидируйте вход.
26 Июн в 09:26
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Прямой эфир