Даже если приложение безопасно обрабатывает SQL-запросы и предпринимаются меры для защиты от SQL-инъекций, использование уязвимой сторонней библиотеки всё равно может свести защиту на нет.
Чаще всего всё ломается на строковых параметрах — если они плохо экранируются, можно сломать синтаксис запроса. Но что если сломать запрос можно не только строками? Например — комментариями.
MySQL требует пробел после
--, чтобы строка была интерпретирована как комментарий. А вот PostgreSQL — нет. И тут всё зависит от режима работы:#️⃣Простой (simple query) — SQL-строка уходит целиком, а параметры клиент подставляет сам.
#️⃣Расширенный (extended query) — SQL и параметры передаются отдельно, что исключает любые синтаксические фокусы.
Но многие клиенты PostgreSQL по умолчанию работают в простом режиме. А иногда расширенный вообще отключён — как, например, в старом
PgBouncer или в некоторых конфигах Datadog.В простом режиме все зависит от того, как библиотека вставит параметры. Например,
PgJDBC при запросе SELECT 1-? и значении параметра -1 сгенерирует:SELECT 1--1
PostgreSQL воспримет
-- как комментарий и просто проигнорирует 1. Такая же история — в pg-promise, pgx, pg, pgdriver.Но можно зайти ещё дальше. Если параметр — многострочная строка, можно внедрить свой код. Комментарий завершится на символе перевода строки, и остальная часть кода будет исполнена. Это даёт возможность внедрить произвольный SQL-код, если вы контролируете параметры.
🔗 Пруфы — в исследовании команды Sonar