Обнаружена критическая уязвимость в Ruby on Rails

Да, в банках обычно так. Другие конторы, бывает, что и по удалёнке нанимают. Где как.

А что делать если нравится язык но не нравится как на нём пишут?

А потом ещё удивляются что для веб приложений выбирают PHP. А я приведу ход мыслей:

- несмотря на отстойные не OO наименования ф-ций PHP имеет приемлемый и понятный C-синтаксис

- В Python присутствуют тоже странные ф-ции, не говоря о том что надо писать len(s) вместо s.length, какого чёрта '/'.join(array) вместо array.join('/')??? Нафига там multiple inheritance с укуреннейшими MRO правилами (http://www.python.org/download/releases/2.3/mro/), два типа классов (new style, old style) и куча других укуренных мест

- OK, несмотря ни на что соглашусь что Python лучше PHP. Возьмём Python для разработки нового веб приложения. Выясняем что как с PHP не получится, надо выбирать ещё и фреймвёрк. Тут то глаза разбегается. С одной стороны имеем Django которая слишком жирная во многих случаях и слишком мало гибкая. С другой стороны идёт фреймвёрк типа Pyramid по которому новичок сможет прочитать разве что короткий мануалчик и всё - никаких книг по нему нет (наверное API частенько меняется), в документации хрен разберёшься - слишком много опций непонятно для чего предназначенных. Чёрт побери, неужели нельзя всё продумать и упростить для такой часто встречающейся задачи как веб.

- Смотрим на Ruby. Опять же, с одной стороны жирный, негибкий, а к тому же ещё и БАЖНЫЙ rails, с другой sinatra и т.д. которые опять таки не солидно выглядят для приложения больше чем 'hello world'. Есть и другие фреймвёрки о которых никто не слышал, в списке фреймвёрков некоторые ссылки ведут на уже умершие страницы. Ясно что такие вещи глупо использовать т.к. ими никто не занимается, баги никто не фиксит.

- Куда ещё податься? Java которая жрёт гигабайты памяти, при этом объём писанины на ней почти такой же как если писать на C++ если не больше. И при этом она способна загнуть мощнейшие сервера на задачах на которые хватит i386 с 1 Mb памяти. Нет, Java и всё что с ней связано отпадает.

- Какие ещё варианты? Попробовать что ли Haskell да боюсь утонуть в функциональщине, думаю очень уж много времени придётся убить на познание новой парадигмы не известной воспитанным на C подобных языках программистам.

- Вот и остаётся в итоге PHP на котором за время мучительных поисков подходящего языка можно было уже набросать первую версию.

В нашей фирме используются не попсовые, а только проверенные временем технологии.

Вы обиделись?

С одной стороны ты написал ерунду.

жирный, негибкий, а к тому же ещё и БАЖНЫЙ rails

Вранье, он не бажный, а количество расширений (из-за которого его и используют!) говорит само за себя.

С другой я тебе посоветовал не «другие фреймвёрки о которых никто не слышал», а использовать веб-сервер напрямую, через rack или goliath (это прослойки между приложением и сервером), под rack опять же существует множество расширений, а goliath асинхронный (на фиберах). И это будет минимум чужого кода. Пиши свое «как надо».

Я возмутился.

В нашей фирме используются не попсовые, а только проверенные временем технологии.

Бейсик, что ли?

Ты просто неосилятор, всё у тебя жирное и негибкое, смирись со своей убогостью. :) Всё, что ты понаписал - сплошной пи###ж.

Возмущаются, когда задет гешефт.

Так, как Вы еще не пишите ничего серьезного для enterpriZe рынка, то мы таки не можем говорить о «возмущении».

А понты в бизнесе, в отличие от гнутия пальцев на ЛОРе, не рассматриваются.

Первая серьёзная уязвимость за последний год, а аналитики уже изошлись на всем известную субстанцию. Почему первая? Потому что уязвимость от 2 января проявлялась в очень специфических условиях, а прошлогодняя история с attr_accessible - не уязвимость по сути. Но я завидую аналитикам. Они умеют делать абсолютно безбажное ПО на проверенных временем технологиях. Жаль, об этом никто, кроме них, не знает.

при этом объём писанины на ней почти такой же как если писать на C++ если не больше.

А я и не знал, что в Джаве нет GC.

Но я завидую аналитикам.

Money talks, bullshit walks...

Почему Вы ещё не в Кремниевой долине?

А ты, сынок,что — совладелец фирмы? Или обычная наёмная шестёрка, которую пнут под зад, как только станет не нужна хозяину?

а прошлогодняя история с attr_accessible - не уязвимость по сути.

Не знаю, что значит «не уязвимость по сути», но с ее помощью гитхаб поимели.

Вранье, он не бажный, а количество расширений (из-за которого его и используют!) говорит само за себя.

Если он не бажный о чём вообще тема? Я уже давно заметил что это у них такой стиль программирования наплевательский. Ну когда профессионалы (должны быть ими по крайней мере) не замечают проблемы в коде в котором даже я новичок вижу что что то подозрительно - ФРЕЙМВЁРК НАПИСАННЫЙ ТАКИМИ ЛЮДЬМИ ИСПОЛЬЗОВАТЬ ОТКАЗЫВАЮСЬ.

С другой я тебе посоветовал не «другие фреймвёрки о которых никто не слышал», а использовать веб-сервер напрямую, через rack или goliath (это прослойки между приложением и сервером), под rack опять же существует множество расширений, а goliath асинхронный (на фиберах). И это будет минимум чужого кода. Пиши свое «как надо».

А объём работы? Может ещё посоветуешь использовать ассемблер напрямую?

уязвимость

Где тег «Решето»?

Ты просто неосилятор, всё у тебя жирное и негибкое, смирись со своей убогостью. :) Всё, что ты понаписал - сплошной пи###ж.

Знать бы ещё что осиливать. Сотни фреймвёрков и ничего конкретного. Вместо единственного PHP со всеми его недостатками и достоинствами.

Вместо единственного PHP со всеми его недостатками и достоинствами.

пхп - не фреймворк. http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#PHP

Точно!

Уйду всё же в функциональщину наверное, там по идее должны быть на порядок умнее разработчики )) безо всяких новомодных agile methodologies бажных

пхп - не фреймворк. http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#PHP

В PHP не нужен фреймвёрк.

В PHP не нужен фреймвёрк.

Зачем же их пишут и используют?

Знать бы ещё что осиливать.

Rails очень неплох, а Ruby - няшка. Баги есть везде, вопрос в том, насколько они критичны и как быстро их правят после нахождения.

В PHP не нужен фреймвёрк.

Ага, не нужен, если есть желание велосипедить. MVC(T) там нет из коробки.

Rails очень неплох

Rails говно, почитай его исходники на досуге если не веришь. Такое ощущение что пишут школьники.

А я и не знал, что в Джаве нет GC.

GC сильно сокращает код? Ну предположим. А знал ли ты об этом:

http://en.wikipedia.org/wiki/Boehm_garbage_collector

?

Не знаю, что значит «не уязвимость по сути», но с ее помощью гитхаб поимели.

Поимели, используя стандартное поведение, описанное в документации. Ошибка авторов рельс здесь состояла только в том, что они не предусмотрели защиту от дурака. То, что разработчики гитхаба ниасилили прочесть мануал, не является уязвимостью рельс. На самом деле это отличный пример того, что разгильдяйство и неаккуратность в коде не зависит от масштаба бизнеса.

Ага, не нужен, если есть желание велосипедить. MVC(T) там нет из коробки.

Оно там не нужно, и я уверен в моём коде написанном на PHP без MVC меньше багов чем в rails и т.д. т.к. чем проще система тем меньше в ней багов.

Поимели, используя стандартное поведение, описанное в документации. Ошибка авторов рельс здесь состояла только в том, что они не предусмотрели защиту от дурака. То, что разработчики гитхаба ниасилили прочесть мануал, не является уязвимостью рельс. На самом деле это отличный пример того, что разгильдяйство и неаккуратность в коде не зависит от масштаба бизнеса.

Это разгильдяйство и неаккуратность характерна для всех любителей rails начиная с его разработчиков и кончая любым школьником прочитавшим их мануальчик и начавшим клепать собственное решето.

Оно там не нужно, и я уверен в моём коде написанном на PHP без MVC меньше багов чем в rails и т.д. т.к. чем проще система тем меньше в ней багов.

Конечно, зачем для гостевухи паттерны-фреймворки?

Это разгильдяйство и неаккуратность характерна для всех любителей rails начиная с его разработчиков и кончая любым школьником прочитавшим их мануальчик и начавшим клепать собственное решето.

Расслабься, бро. Все уже поняли, что php - самый лучший язык. Твоя работа закончена, можешь отдыхать.

Ненужно. PHP наше все!

Если он не бажный о чём вообще тема?

Тема - фарс. Отсутствие экранирования в arel objects - фича, а не баг.

стиль программирования наплевательский

Ага.. обкладывание тестами 100% кода и комментирование под rdoc.. Покажи мне свой ненаплевательский код.

Школьники нашли новую версию спердобейся и долбят ЛОР… Печально.

А объём работы

А где объем.. пишешь простенький парсер (или берешь готовый), прикручиваешь шаблонизатор в пару строк (если надо), а модель - это просто ActiveRecord (или что-нибудь другое).

Тестирование, документация, генераторы, бин-файлы также прикручиваются без проблем кстати.

В нашей фирме используются не попсовые, а только проверенные временем технологии.

Бейсик, что ли?

Если верить этому персонажу - Алгол-68.

Оно там не нужно, и я уверен в моём коде написанном на PHP без MVC меньше багов чем в rails и т.д. т.к. чем проще система тем меньше в ней багов.

Отдача статического контента с редкой вставкой чего-то сгенерированного - да, не требует. Это уровень «Hello, World!». Всё остальное уже требует, как минимум, разделения данных и представления.

Меня возмущает глупость.

у меня не запустилось.. :(
ни how to apply for a job, ни это письмо.. раби какой-то 1.8 (специально вкорячил), я в сортах этого не разбираюсь..

В нашей фирме нет даже запаха Ruby. Мы такое говно не используем.

а какое говно вы используете?

та жа проблема в других веб стеках:

php: ( возможность удаленно исполнять команды, проверено на phpmyadmin, piwik, чем-то еще ) http://www.suspekt.org/downloads/POC2009-ShockingNewsInPHPExploitation.pdf

struts: ( возможность удаленно исполнять команды ) http://websec.wordpress.com/2012/01/04/multiple-vulnerabilities-in-apache-str...

python(pickle): http://blog.nelhage.com/2011/03/exploiting-pickle/

тут, по-ходу, только пара человек понимает в чём, собственно, суть уязвимости заключается

генераторы

Кстати впервые использовал thor для генератора (да и вообще), классная штука, забавная такая, спрашивает файл переписать - не переписать)

кстати, если кому интересно, вот коммит, с которого всё началось: https://github.com/rails/rails/commit/27ba5edef1c4264a8d1c0e54675723d37a391dd...

Тема - фарс. Отсутствие экранирования в arel objects - фича, а не баг.

Если фарс, то почему сами разработчики рейлса называют эту уязвимость критической и настоятельно рекомендуют либо обновиться, либо применить воркэраунд?

Расслабься, бро. Все уже поняли, что php - самый лучший язык. Твоя работа закончена, можешь отдыхать.

Я такого не говорил и даже так не думаю. PHP отстой, rails остой, пошёл учить Happstack... отпишусь потом остой или нет.

Ага.. обкладывание тестами 100% кода и комментирование под rdoc.. Покажи мне свой ненаплевательский код.

Очевидно это никак не поможет если разработчик глупец и не способен предусмотреть все варианты unsafe input для того что бы написать тест для их проверки. Я много мест подозрительных видел когда читал их код.

та жа проблема в других веб стеках:

Насчет пхп и струтсов не знаю, а в питоне только самый упортый идиот будет принимать голый пикл от юзера. В документации по пиклу явно сказано, что это небезопасно (The pickle module is not intended to be secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source. ). И ни один стек на основе питона такого не делает (очень по крайней мере на это надеюсь).

Собственно и yaml, на котором споткнулись рейлсовцы, тоже не предназначен для форматирования запросов пользователей, так как содержит конструкции для сериализации произвольных объектов.

Давно известно что нормальные люди юзают wt

пошёл учить Happstack...

Зачем, это же фреймворк? Пиши на голом хаскеле.

Отдача статического контента с редкой вставкой чего-то сгенерированного - да, не требует. Это уровень «Hello, World!». Всё остальное уже требует, как минимум, разделения данных и представления.

Писал довольно объёмные веб приложения. Особой потребности не возникало никогда. Просто надо понимать что во многих случаях решение под конкретную задачу лучше чем общее решение т.к. общее решение получится весьма сложным и как следствие более подвержено ошибкам при написании. Кроме того иногда проще сделать своё чем разбираться с написанным другими. Кроме того качество кода других не известно и зачастую низкое. Да, NIH: Not Invented Here.