🗄️ 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

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

Вопрос 4 из 20

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

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

Вопрос 5 из 20

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

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

Вопрос 6 из 20

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

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

Вопрос 7 из 20

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

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

Вопрос 8 из 20

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

SELECT * FROM products ORDER BY $1;

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

Вопрос 9 из 20

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

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

Вопрос 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);

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

Вопрос 14 из 20

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

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

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

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

Вопрос 17 из 20

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

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

Вопрос 18 из 20

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

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

Вопрос 19 из 20

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

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

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

Вопрос 20 из 20

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

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

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

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

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

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