SQL-инъекции
Прямые SQL-запросы требуют обязательного экранирования строковых данных через SqlHelper::forSql() и явного приведения чисел к (int). В ORM D7 значения фильтров экранируются автоматически, однако динамическая подстановка пользовательских полей или использование SqlExpression без плейсхолдеров создают риски инъекций и требуют жесткой валидации по белому списку.
Прогресс хранится в этом браузере. Войдите, чтобы сохранить его в аккаунте.
Что нужно понимать
-
1
Параметризованные запросы
-
2
Экранирование через SqlHelper
-
3
ORM как защита
Материалы
Официальная документация
-
Формирование запросов Новая дока
Проверь себя
Разработчик уверен, что раз getList, то инъекция невозможна. Где он ошибается?
В SqlExpression и ExpressionField: их аргументы — сырой SQL, ORM их не экранирует. И в ключах select, filter и order из запроса: это не инъекция, а доступ к связанным таблицам через ReferenceField.
Заказчик жалуется, что через фильтр в личном кабинете кто-то узнал email другого пользователя. Как это могло произойти?
Ключи фильтра собирались из запроса, и условие вроде %=EMAIL со значением A% позволило перебрать email по символу, ориентируясь на пустой или непустой ответ. Нужен белый список полей фильтра.
Чем плейсхолдер ?# в SqlExpression отличается от ?s?
?# — имя столбца или таблицы, экранируется как идентификатор. ?s — строковое значение в кавычках с экранированием. Для чисел есть ?i и ?f.
Почему ключи с тильдой в prepareInsert() опасны?
Их значение уходит в SQL без экранирования — так передают выражения вроде NOW(). Пользовательские данные в такие ключи класть нельзя.
Не сходится?
Спросите Домового: он знает документацию и материалы сайта по этой теме. Ответит сразу.
Нужен живой разбор?
Консультация автора BXMax: созвон один на один, 90 минут на вашу задачу по теме «SQL-инъекции».
Знаете материал лучше? Предложите ссылку: после проверки она появится в этом разделе.
Войти, чтобы предложить