"Уязвимость в ADOdb, допускающая подстановку SQL-запросов"
 Вариант для распечатки |
Пред. тема | След. тема | ||
| Форум Разговоры, обсуждение новостей | |||
|---|---|---|---|
| Изначальное сообщение | [ Отслеживать ] | ||
| "Уязвимость в ADOdb, допускающая подстановку SQL-запросов" | +/– |  |
| Сообщение от opennews (??), 05-Май-25, 08:47 | ||
В библиотеке ADOdb, применяемой во многих PHP-проектах для абстрагирования доступа к СУБД и насчитывающей около 3 млн установок из репозитория Packagist, выявлена уязвимость (CVE-2025-46337), позволяющая выполнить подстановку своего SQL-запроса. Проблеме присвоен критический уровень опасности (10 из 10). Уязвимость устранена в выпуске ADOdb 5.22.9... | ||
| Ответить | Правка | Cообщить модератору | ||
| Оглавление |
| Сообщения | [Сортировка по ответам | RSS] |
| 1. Сообщение от Аноним (1), 05-Май-25, 08:47 | +/– | |
Насколько я знаю, имена таблиц ни в одной базе не могут быть плейсхолдерами в подготовленных запросах, поэтому добавление контроллируемых удаленной стороной данных в имя таблицы - это верный путь к RCE. Единственное нормальное решение в случае, если это 146% нужно и избежать этого нельзя - это сделать HMAC с секретным ключом. | ||
| Ответить | Правка | Наверх | Cообщить модератору | ||
| Ответы: #2 | ||
| 2. Сообщение от Аноним (1), 05-Май-25, 08:52 | +/– | |
P.S. Подготовленные запросы - это фича самой базы, а не обвязки. Но без поддержки фичи в обвязке, разумеется, ничего не выйдет. И обвязка не должна скрывать недостатки самой базы. Если пользователь решает HMACать - то это его решение. В таких случаях может иметь смысл иметь отдельную таблицу, мапящую обратно HMAC на имена. | ||
| Ответить | Правка | Наверх | Cообщить модератору | ||
| Родитель: #1 | ||
| 5. Сообщение от Gemorroj (ok), 05-Май-25, 09:23 | +1 +/– |  |
эта либа давно умерла уже. что-то из времен php 3-4 | ||
| Ответить | Правка | Наверх | Cообщить модератору | ||
| 8. Сообщение от Аноним (8), 05-Май-25, 10:25 | +/– | |
Админы хостингов, которые обслуживают большинство этих php-проектов итак можут делать с бд всё что захотят. Зачем с либами морочиться. | ||
| Ответить | Правка | Наверх | Cообщить модератору | ||
| 9. Сообщение от epw (?), 05-Май-25, 12:02 Скрыто ботом-модератором | +2 +/– | |
| Ответить | Правка | Наверх | Cообщить модератору | ||
| 10. Сообщение от Аноним (10), 05-Май-25, 12:06 | +1 +/– | |
по названию подумал, что это либа доступа к акцессовским базам :) | ||
| Ответить | Правка | Наверх | Cообщить модератору | ||
| 12. Сообщение от Омарним (?), 05-Май-25, 12:25 | +2 +/– | |
типичная сишная ды... ой | ||
| Ответить | Правка | Наверх | Cообщить модератору | ||
| Ответы: #14 | ||
| 14. Сообщение от onanim (?), 05-Май-25, 14:23 | +/– | |
PHP написан на С, так что всё верно. | ||
| Ответить | Правка | Наверх | Cообщить модератору | ||
| Родитель: #12 Ответы: #15 | ||
| 15. Сообщение от Прохожий (??), 05-Май-25, 14:33 | +/– | |
Предлагаете переписать уязвимость на другом? Ну ОК. Это подход новых апологетов. | ||
| Ответить | Правка | Наверх | Cообщить модератору | ||
| Родитель: #14 Ответы: #17 | ||
| 16. Сообщение от Аноним (16), 05-Май-25, 18:03 | +/– | |
Без ссылки на «PHP: a fractal of bad design» (2012 год) эта новость кажется неполной. Да и вообще любая новость про PHP. | ||
| Ответить | Правка | Наверх | Cообщить модератору | ||
| 17. Сообщение от Седой гном (?), 05-Май-25, 18:53 | +/– | |
Предлагаю использовать пистон | ||
| Ответить | Правка | Наверх | Cообщить модератору | ||
| Родитель: #15 | ||
|
Архив | Удалить |
Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема |
