| |
| |
| 3.25, Michael Shigorin (ok), 12:20, 16/10/2014 [^] [^^] [^^^] [ответить] [↓] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +12 +/– |
 > Есть сервер с голой джумлой. Взламываешь? 100 баксов твои.
> Надо больше говори, не вопрос.
А теперь объясняю, как выглядит в жизни.
Некую CMS засунули на хостинг, активно залатывают, сайт наполняют контентом. Проходит год-два-три. Изначальные студент/фрилансер/студия вроде как уже и не нужны, всё устоялось, проблем особых нет. Латание плавно или скачком прекращается, продолжается наполнение. Проходит ещё какое-то время, за которое поддерживаемая ветка закрывается, переезд на следующую требует как минимум обращения к с/ф/с, подчас нетривиальной мороки (т.е. времени и денег), изредка существенной переработки части функциональности.
Так вот важно не то, сколько именно сейчас в условной "голой жумле", которая нафиг никому не упёрлась сама по себе, эксплуатируемых/известных уязвимостей. Важно то, сколько их вылезет к тем нескольким годам плюс какому-то времени, и сколько будет заткнуто за эти первые годы.
Я доступно излагаю?
| | |
|
|
| |
| 2.5, uldus (ok), 00:35, 16/10/2014 [^] [^^] [^^^] [ответить] [↓] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +/– |
 > .сколько еще таких сюрпризов на просторах любителей экономить на prepare-параметрах...
Вообще-то эта уязвимость как раз в коде обработки prepare-параметров :-)
Drupal uses prepared statements in all its SQL queries. To handle IN statements there is an expandArguments function to expand arrays.
...
The function assumes that it is called with an array which has no keys. Example:
db_query("SELECT * FROM {users} where name IN (:name)", array(':name'=>array('user1','user2')));
Which results in this SQL Statement
SELECT * from users where name IN (:name_0, :name_1)
with the parameters name_0 = user1 and name_1 = user2.
The Problem occurs, if the array has keys, which are no integers. Example:
db_query("SELECT * FROM {users} where name IN (:name)", array(':name'=>array('test -- ' => 'user1','test' => 'user2')));
this results in an exploitable SQL query:
SELECT * FROM users WHERE name = :name_test -- , :name_test AND status = 1
with parameters :name_test = user2.
Since Drupal uses PDO, multi-queries are allowed. So this SQL Injection can
be used to insert arbitrary data in the database, dump or modify existing data
or drop the whole database.
With the possibility to INSERT arbitrary data into the database an
attacker can execute any PHP code through Drupal features with callbacks.
| | |
| |
| 3.9, manster (ok), 01:16, 16/10/2014 [^] [^^] [^^^] [ответить] [↓] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +1 +/– |
 >[оверквотинг удален]
> with parameters :name_test = user2.
> Since Drupal uses PDO, multi-queries are allowed. So this SQL
> Injection can
> be used to insert arbitrary data
> in the database, dump or modify existing data
> or drop the whole database.
> With the possibility to INSERT arbitrary data into the database
> an
> attacker can execute any PHP code through Drupal features with
> callbacks.
Возможно, это предположение только. Надо смотреть код. Сейчас многие т.н. драйвера могут маскироваться под placeholders для prepare, но не отрабатывающие "честный биндинг", а просто выполняют замену значениями через search/replace
В случае, когда выполняется prepare+binding подстановка кода не очень возможна, если только как строковое значение поля, когда тип позволяет.
| | |
|
|
| |
| |
| |
| 4.31, Аноним (16), 15:01, 16/10/2014 [^] [^^] [^^^] [ответить] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +/– |
 > Ну алгоритм-то зачастую один и тот же - взять список чисел/строк и
> впихнуть в IN выражение.
> Не дело СУБД - ok, но почему в тех же PDO, JDBC
> и т.п. API не добавить соответствующий метод? В DQL (doctrine) и
> HQL (hybernate) к примеру такая возможность есть (я понимаю, что это
> несколько более высокоуровневые штуки, но не вижу причину чтобы не реализовать
> это уровнем ниже - ну ведь нужная же вещь).
вы же сами ответили - разный уровень.
Если вы пришете в запросе in ( :param ), то :param - это то что выдерается при подготовке запроса ( построении плана и т.д. ), по уму в том же drupal должно бы быть 2 варианта
in ( :param )
и
in ( #суперидентификатонедопустимыйдляsqlзапроса#paramscollection )
тут же в унификации можно зайти очень далеко, в некоторых системах применяют что то вроде "Select &fields from &table &whereparam", но в этом случае все понимают что нельзя просто так что угодно в параметры передавать, такой usecase вы тоже предлагаете в jdbc/pdo встроить?
| | |
|
|
|
|
