🗄️ SQL и базы данных · 20 вопросов · ~38 мин · ⏱ Таймер 38:00 · Средний ·

SQL-инъекции и безопасные запросы

Задания разбирают не страшилки, а точные границы защиты: параметры отделяют значение от SQL-кода, но не подставляют имена столбцов; экранирование вручную ломается на кодировках и контексте; динамический ORDER BY строится через белый список; хранимая процедура безопасна лишь пока внутри неё не склеивается непроверенный SQL. Отдельно проверяются последствия чрезмерных прав.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. В тесте 20 вопросов и 38 минут. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и разбор каждого задания.

Вопрос 1 из 20

Где возникает инъекция в этом коде?

sql = "SELECT * FROM users WHERE name = '" + user_input + "'"

Только если в таблице нет индекса При вызове fetchAll после выполнения При склейке user_input с текстом SQL Уязвимость возникает из-за имени таблицы users, которое нельзя использовать с параметрами

Вопрос 2 из 20

Почему ввод ' OR '1'='1 способен изменить смысл уязвимого WHERE?

SELECT * FROM users WHERE name = '' OR '1'='1';

Ввод меняет формат результата, потому что строковый литерал становится JSON-объектом Он закрывает строку и добавляет своё условие Сравнение автоматически меняет тип столбца name на boolean Ввод завершает текущее сетевое соединение до выполнения WHERE

Вопрос 3 из 20

Возможна ли инъекция в числовой параметр без кавычек?

sql = "SELECT * FROM orders WHERE id = " + request.query.id

Да, если ввод также склеивается в текст команды Нет, числовая позиция безопасна сама по себе даже при склейке необработанного ввода Нет, если поле имеет PRIMARY KEY: ограничение не даст изменить синтаксис Только в PostgreSQL до версии 9

Вопрос 4 из 20

Что такое слепая SQL-инъекция?

Инъекция, возможная лишь в таблице с именем blind или скрытым столбцом Инъекция, при которой запрос не содержит SELECT * и поэтому результат не виден Уязвимость, где данные напрямую не выводятся, но ответы или время позволяют выяснять истинность условий Ошибка драйвера, возникающая только при передаче пустой строки в параметр

Вопрос 5 из 20

Почему сохранённая в базе строка может вызвать вторичную инъекцию позже?

Если другой код извлечёт её и небезопасно вставит в новый SQL-текст Потому что COMMIT повторяет запрос INSERT сразу выполняет любой SQL-текст, помещённый в строковый столбец Опасная строка выполнится при чтении, если её столбец имеет тип text, даже без новой конкатенации

Вопрос 6 из 20

Как правильно передать email?

SELECT * FROM users WHERE email = ${email} SELECT * FROM users WHERE email = $1 sql = base_sql + escape(email) sql = base_sql + email

Вопрос 7 из 20

Почему ручная замена одинарной кавычки не является хорошей заменой параметрам?

Замены кавычек достаточно, если одинаковая функция обработки вызывается во всех местах приложения Она зависит от контекста, настроек и полноты обработки, тогда как параметры вообще не смешивают данные с кодом Параметры нужны преимущественно для кеширования плана, а безопасность одинакова Замена кавычки достаточна, если поле похоже на email и проходит проверку формата

Вопрос 8 из 20

Можно ли одним параметром $1 подставить имя столбца в ORDER BY?

SELECT * FROM products ORDER BY $1;

Нет, параметр представляет значение, а не синтаксический идентификатор Да, если перед именем столбца добавить ключевое слово IDENTIFIER Нет: ORDER BY разрешает параметры только для числовых выражений, но не для текста Да: драйвер подставит имя столбца как идентификатор на этапе разбора SQL

Вопрос 9 из 20

Как безопасно передать список идентификаторов в PostgreSQL?

WHERE id = $1,$2,$3 WHERE id = ANY($1::bigint[]) WHERE id LIKE $1 WHERE id IN (...строка из ввода...)

Вопрос 10 из 20

Почему prepared statement безопасен только при корректном связывании значений?

sql = "SELECT * FROM logs WHERE level=$1 ORDER BY " + user_sort

Склеенный фрагмент ввода остаётся уязвимым Связывание параметра отключает проверку типов, поэтому защищает лишь строковые поля Prepared statement безопасен только без WHERE и других условий по вводу После подготовки запроса любые склеенные фрагменты автоматически экранируются драйвером

Вопрос 11 из 20

Как безопасно реализовать sort=price или sort=name?

sort_sql = {'price': 'price ASC', 'name': 'name ASC'}[user_sort]

Удалить только пробелы из ввода Передать всю строку ORDER BY одним значением $1 Добавить ввод после ORDER BY без проверки Выбрать один из двух заранее заданных фрагментов

Вопрос 12 из 20

Как поступить с направлением сортировки asc/desc?

direction = 'DESC' if requested == 'desc' else 'ASC'

Передавать направление как обычное значение параметра внутри одинарных кавычек Выбрать ASC или DESC строгим сравнением с двумя разрешёнными значениями Добавлять пользовательскую строку после проверки, что она не содержит пробелов Экранировать ASC или DESC как строковый литерал и оставить в позиции ключевого слова

Вопрос 13 из 20

Что безопаснее при динамическом имени таблицы в административной функции PostgreSQL?

EXECUTE format('ANALYZE %I', allowed_table);

Использовать format с %s для любого ввода Склеить строку после удаления точки с запятой Белый список таблиц и format с %I Передать имя через quote_literal

Вопрос 14 из 20

Почему хранимая процедура не гарантирует защиту от инъекции?

EXECUTE 'SELECT * FROM users WHERE name = ''' || p_name || '''';

Внутри процедуры тоже возможна опасная склейка Любая процедура выполняется с правами суперпользователя независимо от настроек Вызов через CALL безопасен сам по себе, даже если внутри строится динамический SQL Хранимая процедура не принимает параметры и поэтому вынуждена склеивать строки

Вопрос 15 из 20

Как безопасно добавить необязательный фильтр status?

WHERE ($1::text IS NULL OR status = $1) WHERE status IN ($1 as sql) WHERE status = /* строка пользователя */ WHERE 1=1 /* затем склейка status */

Вопрос 16 из 20

Почему минимальные права уменьшают ущерб даже при найденной инъекции?

GRANT скрывает сообщения об ошибках Ограничение роли помогает только для UPDATE и DELETE, но не уменьшает ущерб от чтения данных Права автоматически исправляют конкатенацию Уязвимый запрос не сможет выполнять действия, на которые у роли нет привилегий

Вопрос 17 из 20

Стоит ли показывать пользователю полный текст ошибки базы?

Нет, подробные ошибки нельзя сохранять даже во внутреннем журнале Да, полный текст полезен пользователю, если из него заранее удалить пароль Нет, внешний ответ должен быть нейтральным, а подробность — в защищённом внутреннем журнале Да, если вместе с ошибкой показать строку подключения для воспроизведения

Вопрос 18 из 20

Заменяет ли WAF параметризованные запросы?

Нет, фильтр может снизить шум, но код приложения всё равно обязан отделять данные от SQL Да, после установки фильтра динамический SQL можно собирать из любых строк Нет, потому что WAF работает только после выполнения запроса базой Да, если фильтр анализирует расшифрованный HTTPS-трафик и знает сигнатуры атак

Вопрос 19 из 20

Какой автоматический тест полезен для обработчика поиска?

search("O'Reilly")
search("%' OR 1=1 --")

Проверять только обычное имя без кавычек: опасные строки относятся к ручному тестированию Запускать те же проверки от роли владельца схемы, чтобы увидеть больше ошибок Проверять лишь отображение результатов, не контролируя запрос и число найденных строк Опасные строки должны обрабатываться как обычные данные

Вопрос 20 из 20

Что ещё проверить после замены конкатенации на параметры?

Считать все динамические имена и направления безопасными после параметризации значений Оставить прежние широкие права роли: устранение одной инъекции делает их безвредными Все ветви динамического SQL, права роли, журналы, сообщения ошибок и места повторного использования данных Проверить только форматирование и отступы в исправленной строке кода

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу