Зависит от того, что такое $this->my_canal и где меняется, а так же от самого $this->connection - вы не написали что это.

andrewkard, благодарю

Мелкий, благодарю
$this->my_canal это protected алиас для переменной $canal, а $canal - это $_GET['canal'], которая устанавливается пользователем. Попадет в класс через метод и там выполняется вышеуказанный код.
Если такого канала нет, то устанавливается $this->my_canal = 'first_canal'

Могу показать весь листинг.

Суть в том, что пользователь может ввести любые значения в input canal
(Вывод и внедрение данных в данном случае не страшно) ... Главное DROP

Теоретически ничто не мешает.
Например для pdo_pgsql проверил - можно и drop table сделать, были бы права у пользователя.

Это в целом плохая мысль использовать пользовательские данные в качестве имени таблицы.

Там суть в том, что кроме каналов нет ничего в БД.
userlogin - только имя отправленное пользователем - произвольное.

Да, проверил просто DROP из php, похоже, можно DROP.

Мдя, тогда придется на хостинге закрыть DROP


P.S.
Благодарю! Вопрос решен!

с подготовленным запросом можно выполнить drop table ? Вернее втыкнуть инъекцию?

У меня prepared statement только на данные, но переменная для выбора таблицы не вписывается в модель prepared statement.

Это динамический выбор таблицы

Проверить по белому списку

А что вас собственно удивляет?
Если продолжать конкатенировать запрос с данными - то ничего не изменится. prepared statement не серебряная пуля, а лишь транспорт.

Я отдельно уточнил где проверял, потому что на сколько помню в pdo_mysql намеренно отломаны мультизапросы. При том именно из-за безалаберного отношения авторов кода (не могу назвать разработчиками) к sql инъекциям. А про другие драйвера вовсе ничего сказать не могу.


Этот мой комментарий относился именно к вашей модели данных.
Использовать пользовательский ввод в качестве имени объекта - идея плохая и так быть не должно.

Это есть, но для снижения нагрузки хотелось бы отключить эту опцию
(Добавление)




Делать отдельную таблицу сопоставления?
Дело в том, что сейчас так удобно создавать новые каналы ...

Вообще тогда исходя из сказанного Мелким, получается на выбор таблицы надо делать
switch

Гипотеза: у вас некоторое число таблиц идентичной структуры.
Почему я так подумал: если бы структуры были различны - у вас бы не стояло вопроса как проверять имя таблицы, а выбор был бы детерминирован.
Вывод: это должна быть одна таблица. Имя искусственного водного пути (хотя при чём тут водные пути? Но canal это именно оно) - такой же параметр запроса, а не имя таблицы.
В итоге вы ищите проблему там где её нет, просто соорудив странную схему базы.

Да.