Забавно, как эти два факта склеились в один у The Register: по их версии, "Google is dropping encryption into MariaDB, the fork of Oracle’s MySQL, to help shut out SQL injection attacks" ("Google встраивает шифрование в MariaDB, чтобы помочь бороться с SQL-инъекциями") - что, конечно, является полным бредом.

Источник: ZDNet

теги: google  |  предложить новость  |  обсудить  |  все отзывы (4)

[3954]

назад «  » вперед

аналогичные материалы Google Drive находит файлы // 07.12.23 01:46 Google Drive теряет файлы // 27.11.23 20:02 Google начинает платить за найденные уязвимости // 31.08.22 20:16 Google окончательно прикрывает бесплатный G Suite // 28.01.22 16:48 Apple, Google, Microsoft и Mozilla забанили казахстанский сертификат // 19.12.20 03:13 Google закрывает безлимитные Photos // 11.11.20 22:12 Google постепенно отключит доступ к G Suite сторонним приложениям, использующим простой пароль // 17.12.19 17:18

последние новостиBugTraq.Ru: последние новости Бэкдор в xz/liblzma, предназначенный для атаки ssh-серверов // 30.03.24 17:23 Три миллиона электронных замков готовы открыть свои двери // 22.03.24 20:22 Doom на газонокосилках // 28.02.24 17:19 Умер Никлаус Вирт // 04.01.24 14:05 С наступающим // 31.12.23 23:59 Четверть приложений, использующих Log4j, до сих пор уязвима // 11.12.23 18:29 Google Drive находит файлы // 07.12.23 01:46

Комментарии: От прочтения новости испытывал когнитивный диссонанс, пока... 10.04.15 13:33   Автор: Den <Denis> Статус: The Elderman <"чистая" ссылка> От прочтения новости испытывал когнитивный диссонанс, пока не прочел твою ремарку. Даже если отделить новость о шифровании таблиц от новости про встроенный фильтр для борьбы с SQL-инъекциями, то последняя также вызывает недоумение. Ведь для того, чтобы некий фильтр SQL сервера мог отличить полученный от клиента запрос с SQL инъекцией от штатного запроса, он должен обладать каким-то шаблоном штатного запроса или же иметь информацию о том, какие действия ожидаемы и позволены данному запросу. В обоих случаях, это совсем не очевидное решение проблемы SQL инъекций. от простых инъекций защититься можно 10.04.15 19:03   Автор: dl <Dmitry Leonov> <"чистая" ссылка> Если совсем навскидку, типовая инъекция - втыкание кавычки, после которой либо через ; свою команду, либо какой-нибудь OR, фактически убирающий проверку. В первом случае нужно отслеживать запросы с несколькими командами и либо отсекать все, что идет после ;, либо отсекать там потенциально опасные запросы. Во втором - проверять логические операции, способные сводить все выражение к безусловному true/false. Естественно, не панацея, но какую-то часть проблем уберет. В первом случае, если фильтр не имеет шаблона исходного... 13.04.15 10:56   Автор: Den <Denis> Статус: The Elderman <"чистая" ссылка> > Если совсем навскидку, типовая инъекция - втыкание кавычки, > после которой либо через ; свою команду, либо какой-нибудь > OR, фактически убирающий проверку. В первом случае нужно > отслеживать запросы с несколькими командами и либо отсекать > все, что идет после ;, либо отсекать там потенциально > опасные запросы. Во втором - проверять логические операции, > способные сводить все выражение к безусловному true/false. > > Естественно, не панацея, но какую-то часть проблем уберет. В первом случае, если фильтр не имеет шаблона исходного запроса, безосновательно делать предположения о том, какие именно SQL операторы инжектированы. Даже если фильтр будет знать о количестве SQL операторов в исходном запросе, этих данных не достаточно, чтобы принять решение об исполнении или неисполнении запроса целиком (атомарно), так как такой подход не защищает от инжектирования подзапросов или UNION операторов к исходному SQL оператору, позволяющего неавторизованно выдергивать данные из других таблиц и помещать их в выходные данные исходного запроса. Во втором случае, чтобы отсечь потенциально опасные запросы, фильтру необходимо знать, какие именно действия разрешены для каждого SQL оператора полученного запроса, что весьма нетривиально в реализации и влечет за собой необходимость передачи в фильтр всё тогоже шаблона исходного запроса, к примеру, в формате функции c++ - "printf". ИМХО, проблема решается тривиально - корректными клиентскими библиотеками доступа к данным SQL сервера и использованием параметризованных запросов. В общем, я так и не понял, зачем MariaDB нагородили этот фильтр. в первом случае можно отсекать хотя бы всякие drop table 14.04.15 01:15   Автор: dl <Dmitry Leonov> <"чистая" ссылка> При передаче из программ вообще не так уж часто используются несколько команд в одном запросе, ну и можно считать, что нефиг таким опасным командам идти в комбинации с другими. Во втором случае достаточно анализировать логические операции на предмет тривиального результата (типа 1=1 или сводящегося к нему). C union хуже, но это первые варианты, которые пришли в голову, наверняка там полно разных эвристик. Естественно, нормальные клиентские библиотеки все это и так лечат.

<добавить комментарий>