Что такое SQL Injection через параметры ORDER BY и почему использование байндинга переменных здесь не всегда помогает?

SQL Injection через параметры ORDER BY — это особый и нередко недооцениваемый вид атаки на базы данных. Чтобы понять, почему он опасен и почему стандартные методы защиты здесь не работают, нужно разобраться в механике SQL-запросов.

## Как работает ORDER BY и в чём проблема

Клауза ORDER BY используется для сортировки результатов запроса. Типичный пример:

sql
SELECT * FROM products ORDER BY price ASC;

Когда разработчик позволяет пользователю выбирать столбец или направление сортировки, возникает соблазн подставить это значение напрямую в запрос:

sql
SELECT * FROM products ORDER BY {user_input};

Если злоумышленник передаст вместо `price` строку вроде `price DESC, (SELECT 1 FROM users WHERE username=’admin’ AND SLEEP(5))`, запрос выполнит произвольный код. Это классическая SQL-инъекция через ORDER BY.

## Почему байндинг переменных (prepared statements) не помогает

Параметризованные запросы (prepared statements) — основной инструмент защиты от SQL-инъекций. Они работают так: значение передаётся отдельно от структуры запроса, и СУБД воспринимает его исключительно как данные, а не как часть SQL-синтаксиса.

Однако здесь кроется ключевое ограничение: **байндинг работает только для значений данных, но не для идентификаторов и ключевых слов SQL**. Имена столбцов, направление сортировки (ASC/DESC), названия таблиц — всё это структурные элементы запроса, а не данные. Большинство СУБД и драйверов не позволяют параметризовать такие элементы.

Если попытаться написать:
sql
SELECT * FROM products ORDER BY ?;

и передать `price`, многие СУБД либо выдадут ошибку, либо обернут значение в кавычки, превратив его в строковый литерал — и сортировка просто не будет работать корректно.

## Как правильно защититься

1. **Белый список (whitelist)**: самый надёжный способ. Заранее определить допустимые значения для сортировки и сверять пользовательский ввод с этим списком.
python
allowed_columns = [‘price’, ‘name’, ‘date’]
if user_column not in allowed_columns:
raise ValueError(‘Недопустимый столбец’)
query = f’SELECT * FROM products ORDER BY {user_column}’

2. **Маппинг значений**: использовать словарь, где ключи — безопасные псевдонимы, значения — реальные имена столбцов. Пользователь передаёт ключ, а в запрос подставляется значение из словаря.

3. **Отказ от динамической сортировки**: если бизнес-логика позволяет, жёстко задать порядок сортировки на стороне сервера.

4. **Экранирование идентификаторов**: некоторые ORM и библиотеки предоставляют функции для безопасного экранирования имён столбцов (например, обёртка в backticks для MySQL), но это менее надёжно, чем белый список.

## Итог

SQL Injection через ORDER BY опасна именно своей «невидимостью» — разработчики часто думают, что параметризация решает все проблемы. Понимание ограничений prepared statements и применение белых списков — обязательная практика для любого приложения, работающего с динамической сортировкой.