Доступны (http://weblog.rubyonrails.org/2013/1/2/Rails-3-2-10--3-1-9--.../) для внепланового обновления корректирующие выпуски фреймворка Ruby on Rails 3.2.10, 3.1.9 и 3.0.18, в которых устранена опасная уязвимость (https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...) (CVE-2012-5664). Уязвимость позволяет осуществить выполнение произвольного SQL-кода на сервере через передачу специально оформленного запроса к web-приложению, использующему интерфейс динамического поиска Active Record в сочетании с передачей переменной без явного преобразования типа (например, уязвимы приложения с кодом подобным Post.find_by_id(params[:id]), для защиты достаточно использовать явное преобразование в строку: Post.find_by_id(params[:id].to_s)). Обновление выпущено в экстренном порядке, так как в сети уже можно найти готовый эксплоит для осуществления атаки.URL: https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...
Новость: http://www.opennet.me/opennews/art.shtml?num=35748
В SQLAlchemy такого никогда не будет. Python рулит!
Еще бы рулил куда надо )))
правильно. Вся эта педерастия в виде ORM не нужна
Точнее, в разумных пределах нужна. Смысл писать рутинный SQL когда он тривиально генерируется. Другое дело, что если по уму - то: 1) SQL генерируется один раз; 2) есть способы написать его руками; 3) не выпендриваться и не делать ORM слишком умным, его задача - избавить от рутинного кода.
> правильно. Вся эта педерастия в виде ORM не нужнаНе вопрос. Используй SQLAlchemy Core как генератор SQL.
> как генератор SQL.Или как конструктор. Не знаю как точнее описать это. В Drupal-е начиная с 7 версии похожая штука есть.
> В SQLAlchemy такого никогда не будет. Python рулит!Да, тут в соседней ветке в питонистом moinmoin нашли аж выполнение левого кода через убер-баянный баг.
О чем это я? Да о том что вы лишний раз нам показали что поделия на питоне надо обходить за километр: как видим, на питоне программируют бакланы полагающие что крютой рантайм и крютой фреймворк заменяют разработчику мозги.
> Да, тут в соседней ветке в питонистом moinmoin нашли аж выполнение левого
> кода через убер-баянный баг.И? Я не утверждал, что в питоне нельзя создать уязвимость по собственной глупости.
> на питоне программируют бакланы полагающие что крютой рантайм и крютой фреймворк
> заменяют разработчику мозги.Не проецируй. Функционал SQLAlchemy видел? Не читал, но осуждаю?
Это уязвимость в active record, или уязвимость из-за обхода active record и "делания по-своему"?
Насколько я понимаю - из-за слишком богатого функционала. Хрен все мыслимые пути проверишь.
> Насколько я понимаю - из-за слишком богатого функционала. Хрен все мыслимые пути
> проверишь.Помолчи. Два кейворда в строковом значении проверить, прежде, чем кормить это в запрос, может даже дебил. Ты не понимаешь ни сути инъекции, ни реляционных субд в частности.
Это ты сути не понял. Ну придумают какой-то другой путь. Ничему попытки резать HTML-теги в своё время для получения "безопасного" подмножества не научили? Валидация по черным спискам дырява всегда.Если уж на что там наезжать - так это на хранение чего-то, что десериализуется напрямую, в куках. Но - положились на HMAC и не вбили генерацию его секрета в дефолтное развертывание приложения. Ну и слишком вольная тактовка параметров всегда злом была. Былоб всё фиксировано - и нет проблем. В общем, вагон мелких и простительных огрехов удачно совпал.
Интеллигентные люди в куки не кладут ничего критичного. По сути, авторизационные куки есть лишь квитанция, что имярек успешно прошел аутентификацию и имеет доступ к тому-то и тому-то.Суть, однако, SQL-инъекции - в пропихивании через веб-форму подзапроса UNION с доступом к таблицам пользователей/паролей и эскалация прав в бакэндовой БД до суперпользовательских. С последующим выносом оттуда логинов и паролей пользователей.
И защита делается либо на стороне сервера приложений (проверяется либо посредством, скажем, GreenSQL или хардкодовой процедурой валидации значений на отсутствие SQL-кейвордов), либо на стороне самой БД, скажем, на уровне табличного интерфейса, обязательного при обращении к таблицам (как это сделано в Oracle).
а что, в AR нет нативного эйскепинга контента?
есть, если интересно патчи смотрите
> есть, если интересно патчи смотритеЭто руками за секунды пишется. Если чо. Любым вменяемым девелопером. SQL-инъекции как методике атаки сто лет в обед.
И что дальше? переполнению буфера и стрека по боле будет летов.
А в чём фишка-то? Рельсы, когда разбирают параметры, могут в качестве значения параметра создать не строку, а объект произвольного типа? Правильно я понял?
у рельсов там используется десериализация, из которой можно собрать что угодно. Друго дело, что там вполне разумно прикрылись подписью. Ключ для, которой, по идее, надо генерировать при каждом развертывании рельсового прииложения или предупреждат администратора, но этого не сделано во многих опенсорсных проектах.
> у рельсов там используется десериализация, из которой можно собрать что угодно. Друго
> дело, что там вполне разумно прикрылись подписью. Ключ для, которой, по
> идее, надо генерировать при каждом развертывании рельсового прииложения или предупреждат
> администратора, но этого не сделано во многих опенсорсных проектах.В опенсурсе тоже полно г@внокодеров, мнящих себя супер-пупер-мега-дупер-профессионалами.
http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulner.../Забавная дырка, да.
> But ActiveRecord also defines ways for the programmer to inject SQL fragments into the queryТак это же выходит не баг, это штатное поведение ActiveRecord.