В библиотеке ADOdb, применяемой во многих PHP-проектах для абстрагирования доступа к СУБД и насчитывающей около 3 млн установок из репозитория Packagist, выявлена уязвимость (CVE-2025-46337), позволяющая выполнить подстановку своего SQL-запроса. Проблеме присвоен критический уровень опасности (10 из 10). Уязвимость устранена в выпуске ADOdb 5.22.9...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63186
Насколько я знаю, имена таблиц ни в одной базе не могут быть плейсхолдерами в подготовленных запросах, поэтому добавление контроллируемых удаленной стороной данных в имя таблицы - это верный путь к RCE. Единственное нормальное решение в случае, если это 146% нужно и избежать этого нельзя - это сделать HMAC с секретным ключом.
P.S. Подготовленные запросы - это фича самой базы, а не обвязки. Но без поддержки фичи в обвязке, разумеется, ничего не выйдет. И обвязка не должна скрывать недостатки самой базы. Если пользователь решает HMACать - то это его решение. В таких случаях может иметь смысл иметь отдельную таблицу, мапящую обратно HMAC на имена.
> Единственное нормальное решение в случае, если это 146% нужно и избежать этого нельзя - это сделать HMAC с секретным ключом.
> нормальноеКаким определением "нормальности" ты пользуешься?
Можно написать QueryBuilder, про который можно будет формально доказать, что использование имени таблицы взятого от пользователя без валидации не будет приводить к RCE. Оно всё же может приводить к обращению к таблице, к которой не хотелось бы обращаться (к таблице с ровно таким именем, который пользователь нам выдал, например, "; DROP TABLE users"), но это не RCE. На самом деле не только с именем таблицы так можно поступить, можно сделать так, что любые строки от пользователя переданные в любой метод QueryBuilder'а не приводили бы к RCE.
QueryBuilder может позволить совать внешние данные в СУБД, которая не поддерживает prepared statements, и не иметь никаких RCE. Проблемы PHP проистекают из того, что он настаивает на том, что раз у программиста есть конкатентация строк, то больше ему ничего не нужно для построения SQL запросов. Но это проблемы PHP, и судя по возрасту PHP, который до сих пор ходит по граблям sql-injection, проблемы эти невозможно устранить без устранения PHP.
Никакая санитизация в принципе не является нормальным решением, так каксанитизация - это в принципе чёрный список, а для безопасности нужен белый.
Ты чего-то не понял. QueryBuilder не является ни белым, ни чёрным списком. Он позволяет передавать любые строки в запросы. Единственное о чём он заботится, это о том, чтобы запросы при этом составлялись бы правильно, чтобы передаваемые строки не смогли бы сломать структуру запроса.
>Проблемы PHP проистекают из того, что он настаивает на том, что раз у программиста есть конкатентация строк, то больше ему ничего не нужно для построения SQLЭто не так, PHP прекрасно поддерживает подготовленные запросы.
эта либа давно умерла уже. что-то из времен php 3-4
Админы хостингов, которые обслуживают большинство этих php-проектов итак можут делать с бд всё что захотят. Зачем с либами морочиться.
по названию подумал, что это либа доступа к акцессовским базам :)
Ну технологию ADO давно придумали и видимо это удобный способ написать дата провайдер в виде драйвера ADO чтобы программное обеспечение умеющее работать с ADO могло подключиться к твоему источнику данных.
Без ссылки на «PHP: a fractal of bad design» (2012 год) эта новость кажется неполной. Да и вообще любая новость про PHP.
Это что - php? Кто-то этим ещё пользуется?
Знаешь такого Дурова? Вот он на том самом php никому не нужном и стал богатым и известным. Поэтому чушь не неси, это до сих пор один из самых популярных языков
На самом деле не так уж много сайтов есть, которые обходятся без PHP. Почти весь интернет на этом языке работает ¯\_(ツ)_/¯
Ага.
Это как с Макдаком. Кого ни спроси - никто там не ест. А приди в любой ресторан - народищу не протолкнуться. Также и с РНР