Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в ADOdb, допускающая подстановку SQL-запросов"	+/–
Сообщение от opennews (??), 05-Май-25, 08:47
В библиотеке ADOdb, применяемой во многих PHP-проектах для абстрагирования доступа к СУБД и насчитывающей около 3 млн установок из репозитория Packagist, выявлена уязвимость (CVE-2025-46337), позволяющая выполнить подстановку своего SQL-запроса. Проблеме присвоен критический уровень опасности (10 из 10). Уязвимость устранена в выпуске ADOdb 5.22.9... Подробнее: https://www.opennet.me/opennews/art.shtml?num=63186
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 05-Май-25, 08:47	+/–
Насколько я знаю, имена таблиц ни в одной базе не могут быть плейсхолдерами  в подготовленных запросах, поэтому добавление контроллируемых удаленной стороной данных в имя таблицы - это верный путь к RCE. Единственное нормальное решение в случае, если это 146% нужно и избежать этого нельзя - это сделать HMAC с секретным ключом.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #21

2. Сообщение от Аноним (1), 05-Май-25, 08:52	+/–
P.S. Подготовленные запросы - это фича самой базы, а не обвязки. Но без поддержки фичи в обвязке, разумеется, ничего не выйдет. И обвязка не должна скрывать недостатки самой базы. Если пользователь решает HMACать - то это его решение. В таких случаях может иметь смысл иметь отдельную таблицу, мапящую обратно HMAC на имена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

5. Сообщение от Gemorroj (ok), 05-Май-25, 09:23	+2 +/–
эта либа давно умерла уже. что-то из времен php 3-4
Ответить | Правка | Наверх | Cообщить модератору

8. Сообщение от Аноним (8), 05-Май-25, 10:25	+/–
Админы хостингов, которые обслуживают большинство этих php-проектов итак можут делать с бд всё что захотят. Зачем с либами морочиться.
Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от Аноним (10), 05-Май-25, 12:06	+1 +/–
по названию подумал, что это либа доступа к акцессовским базам :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18

16. Сообщение от Аноним (16), 05-Май-25, 18:03	+/–
Без ссылки на «PHP: a fractal of bad design» (2012 год) эта новость кажется неполной. Да и вообще любая новость про PHP.
Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от Аноним (-), 05-Май-25, 23:51	–2 +/–
Ну технологию ADO давно придумали и видимо это удобный способ написать дата провайдер в виде драйвера ADO чтобы программное обеспечение умеющее работать с ADO могло подключиться к твоему источнику данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

19. Сообщение от Аноним (19), 06-Май-25, 08:11	+2 +/–
Это что - php? Кто-то этим ещё пользуется?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #24, #29

20. Сообщение от Аноним (-), 06-Май-25, 08:55	–2 +/–
Знаешь такого Дурова? Вот он на том самом php никому не нужном и стал богатым и известным. Поэтому чушь не неси, это до сих пор один из самых популярных языков
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

21. Сообщение от Аноним (-), 06-Май-25, 17:30	+/–
> Единственное нормальное решение в случае, если это 146% нужно и избежать этого нельзя - это сделать HMAC с секретным ключом. > нормальное Каким определением "нормальности" ты пользуешься? Можно написать QueryBuilder, про который можно будет формально доказать, что использование имени таблицы взятого от пользователя без валидации не будет приводить к RCE. Оно всё же может приводить к обращению к таблице, к которой не хотелось бы обращаться (к таблице с ровно таким именем, который пользователь нам выдал, например, "; DROP TABLE users"), но это не RCE. На самом деле не только с именем таблицы так можно поступить, можно сделать так, что любые строки от пользователя переданные в любой метод QueryBuilder'а не приводили бы к RCE. QueryBuilder может позволить совать внешние данные в СУБД, которая не поддерживает prepared statements, и не иметь никаких RCE. Проблемы PHP проистекают из того, что он настаивает на том, что раз у программиста есть конкатентация строк, то больше ему ничего не нужно для построения SQL запросов. Но это проблемы PHP, и судя по возрасту PHP, который до сих пор ходит по граблям sql-injection, проблемы эти невозможно устранить без устранения PHP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #25, #26

24. Сообщение от Oleg (??), 07-Май-25, 08:02	+2 +/–
На самом деле не так уж много сайтов есть, которые обходятся без PHP. Почти весь интернет на этом языке работает ¯\_(ツ)_/¯
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

25. Сообщение от Аноним (25), 07-Май-25, 08:39	+/–
Никакая санитизация в принципе не является нормальным решением, так каксанитизация - это в принципе чёрный список, а для безопасности нужен белый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #27

26. Сообщение от Аноним (25), 07-Май-25, 08:40	+/–
>Проблемы PHP проистекают из того, что он настаивает на том, что раз у программиста есть конкатентация строк, то больше ему ничего не нужно для построения SQL Это не так, PHP прекрасно поддерживает подготовленные запросы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

27. Сообщение от Аноним (-), 07-Май-25, 16:05	+/–
Ты чего-то не понял. QueryBuilder не является ни белым, ни чёрным списком. Он позволяет передавать любые строки в запросы. Единственное о чём он заботится, это о том, чтобы запросы при этом составлялись бы правильно, чтобы передаваемые строки не смогли бы сломать структуру запроса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

29. Сообщение от еропка (?), 07-Май-25, 21:36	+/–
Ага. Это как с Макдаком. Кого ни спроси - никто там не ест. А приди в любой ресторан - народищу не протолкнуться. Также и с РНР
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема