Проблемы безопасности фреймворка Ruby on Rails и способы их решения

Вторая ситуация интересна тем, что она актуальна и для других платформ. Я называю эту проблему «GET Accessible Actions» — это такая ситуация, в которой по задумке разработчика запрос должен осуществляться с использованием метода POST и с токеном, но на деле фреймворк спокойно принимает метод GET и пропускает проверку токена. В случае RoR проблема заключается в использовании метода match в файле routes.rb, описывающем систему обработки путей на сайте. Данный метод предназначен для маппинга определенного действия сразу на все доступные методы HTTP: GET, POST, PATCH, DELETE и так далее. Метод match используется повсеместно, поэтому при анализе защищенности приложения RoR всегда пробуй передавать параметры через альтернативные HTTP-методы (в самом простом случае — GET) и следи за реакцией сервера. Следующее выражение является классической иллюстрацией описываемого случая:

match “/follow”, to: “followings#create” 

Именно благодаря наличию такого выражения и использованию обычного тега

<img src=site/follow?user_id=myid>

я получил сотни фолловеров на сайтах formspring.me, slideshare.net, bitbucket.org и других.

Хотел бы отметить, что в четвертой версии Rails было запрещено использование метода match без параметра «:via». Теперь, если ты хочешь, как и раньше, не ограничивать перечень используемых HTTP-методов, тебе нужно передать аргумент «via: :all».

Рекомендация: независимо от платформы твоего сайта всегда четко разграничивай все действия на POST, как изменяющий информацию запрос (с проверкой токена), и GET, как запрос на получение информации (без токена).

XSS

Очень полезна реализованная в RoR защита от XSS при помощи экранирования потенциально опасных символов, включенная по умолчанию. Каждая строка (класс String) помечается специальным флагом html_safe. При этом если данный флаг отсутствует, то перед выводом переменной Rails осуществит ее фильтрацию.

Для вывода безопасных данных принято использовать конструкцию

<%=raw data%>

а для всех остальных (например, значений, которые могут быть модифицированы пользователем):

<%= data %>

Метод raw помечает строку флагом html_safe:

def raw(stringish)
  stringish.to_s.html_safe
end

Поэтому многие рубисты привыкли к наличию фильтров XSS, используемых по умолчанию. Однако хороший специалист по информационной безопасности понимает, что XSS — это комплексная атака, которая может принимать различную форму и проводиться в несколько этапов (например, происходить после осуществления пользователем каких-либо действий или запуска событий, то есть в рантайме).

Проблема возникает тогда, когда разработчикам необходимо вставить данные в формате JSON в возвращаемую пользователю страницу. Обычно для этого используют выражение:

<%=data.to_json%>

или для варианта с языком разметки haml:

:javascript
  var data = #{data.to_json}

В первом случае используется конструкция <% — то есть стандартная фильтрация будет применена. Во втором случае JSON, который может содержать HTML-код, не будет очищен. Уязвимость исправлена в четвертой версии Rails, в ней символы <>& заменяются на их Unicode-аналоги.

Рекомендация: не вставлять в inline JavaScript небезопасные данные и вообще не использовать inline javascript / CSS. Альтернативой может быть такой метатег: .

Это может выглядеть неэффективно, зато семантично и безопасно с точки зрения взаимодействия данные — код, обрабатывающий данные.

Mass Assignment

Согласно конвенции RoR, параметры передаются в виде хеша: user[username], user[secondname], и уже в контроллере этот хеш переходит в модель — user.update_attributes params[:user]. При этом, если подкидывать в хеш значения других полей таблицы, которые изначально нам не разрешено менять, становится возможным обновить и их вместе с остальными. Например, изменить foreign keys и назначить сущности другого владельца (user_id).

Известная защита от такого поведения RoR — использовать attr_accessible: при создании модели разработчик обязан описать, что именно можно обновлять посредством mass assignment, а что — нельзя. Фактически же такими методами пользуются только настоящие джедаи, то есть те разработчики, которые не только помнят об этой защите, но и не ленятся описывать вручную соответствующие параметры. Основным препятствием к безопасной разработке с использованием данных методов оказывается то, что никто и ничто (даже генераторы моделей) не напоминает разработчику о необходимости их применять.

Особенно пагубно mass assignment влияет на foreign keys, в ситуации, когда один объект можно переназначить другому. Чтобы защиту включили по умолчанию, я проводил активно агитировал разработчиков в тикете #5228 на основной странице Rails (bit.ly/ydMRCB), однако моей идеей мало кто вдохновился.

Параллельно с агитацией я занимался тестированием самого гитхаба, и это принесло свои плоды, так как защита от mass assignment в проекте отсутствовала. Первый пример (его можно применить для множества других сайтов) — обновление дефолтных полей updated_at/created_at. Тикет из 3012 года до сих пор стоит первым в выдаче при сортировке по полю Submitted (рис. 3).

Вторым примером стала смена значения public_key[user_id] моего ключа на ID пользователя Rails и последующий коммит в rails/rails — репозиторий Rails, хранящийся на GitHub, написанном на Rails (рис. 4).

Нельзя назвать мой наглый поступок ответственным, хоть я и уведомил администрацию о похожих уязвимостях еще за три дня до этого. Вместо полного аудита кода на наличие mass assignment они запатчили лишь частные случаи, поэтому я был вынужден поступить не по whitehat’ски. Это принесло свои плоды — спустя пять часов после коммита Rails Core Team сделала whitelist_attributes обязательным по умолчанию (заставляет прописывать attr_accessible в моделях), а также добавила атрибут attr_accessible в генераторы. Вероятно, это было сделано под воздействием общественного мнения — о том коммите написали многие сайты.

В Rails 4 вместо старой защиты в модели будет использоваться джем strong_parameters для фильтрации ключей тем же способом, но в контроллере. Этот способ выглядит более логичным, так как контроллер является первым рубежом обороны от ошибок, связанных с некорректной обработкой данных, поступающих от пользователя.

Рекомендация: всегда использовать whitelist и делать защиту включенной по умолчанию, не надеясь на самих пользователей.

SQL injection

Хотя ORM-рельс в большинстве случаев экранирует входные параметры, есть такие служебные методы, которые подразумевают передачу только безопасных параметров. Например, Order.where(:user_id => 1).joins(params[:table]) — параметр table никак не будет очищен, да и джойнить произвольную таблицу — изначально плохая идея.

Рекомендация: Для полного списка таких опасных методов советую посмотреть сайт rails-sqli.org и убедиться, что для создания SQLi в рельс-приложении надо иметь руки немного не из того места.

Сессии

В RoR сессии хранятся по умолчанию в signed cookie, представляющей собой обычную строку, подписанную секретным ключом HMAC. Многие разработчик полагают, что пользовательская сессия — это что-то по умолчанию безопасное и недосягаемое для пользователя. Да, пользователь не может модифицировать значения параметров сессии, так как она подписана сессионным ключом приложения — session_secret, зато он может прочитать все, что записано в сессии (например, значения user_id, access_token или path_to_secret_file). Вот так, например, выглядит _gh_sess cookie на github.com:

BAh7DDoQX2Nzc ... AGOgpAdXNlZHsA—
d12b0f42ed9881fbv55cc9559d50adwf5f5638d2

Данное значение состоит из двух частей: первая часть значения представляет собой строку, закодированную по алгоритму Base64, вторая часть — ее MD5-подпись. Попробуем декодировать первую часть строки при помощи функций atob(decodeURIComponent()) и получим следующее значение:

"{:_csrf_token"19yv3VZY8veGCQXyS3dl47XGB9r4rzWVUNZqUFqSmWNI=:session_id"%76f701b09a1b5a1831a51a309ff8f79d: userieª:contextI"/:EF:fingerprint"%5ffecf01f27d79b4ff0dbeaa39568eb7:return_toI"(https://github.com/settings/profile; TI"
flash; FIC:'ActionController::Flash::FlashHash{:
@used{"

Собственно говоря, ничего, кроме раскрытия данных, этот баг не несет. В Rails 4 для хранения сессий уже используется encrypted session storage, что существенно ограничивает возможность получения полезных данных из сессии, так как она хранится в зашифрованном виде.

Рекомендация: лучше не хранить ничего на стороне клиента, а в качестве session ID использовать неугадываемую строку, соответствующую строчке в базе данных, для этого есть джем activerecord-session_store.

to_sym

Symbol — это особый тип данных в Ruby, являющийся, по сути, константой, при этом сами символы никогда не удаляются сборщиком мусора. Поэтому, если приложение создает символы на основании контролируемых пользователем данных и при этом указать длинные последовательности случайных букв/цифр, возможен отказ в обслуживании. Основной задачей в этом случае становится поиск места, в котором пользовательский ввод приводится к типу symbol.

Хотя со временем код рельс «очистили» от символизации, однако до сих пор некоторые разработчики злоупотребляют этим в своих приложениях и контроллерах. Очень часто встречается, например: I18n.locales.include?(params[:locale].to_sym) — разработчик только что привел параметр locale к символу (а он может быть очень длинным), забив тем самым память.

pic dlinn

Я, например, находил возможность DoS в Rack (единый интерфейс для большинства веб-фреймворков на Ruby), который приводил к символу часть заголовка Authorization (:basic, :digest, :blahblahverylong):

def parts
  @parts ||= @env[authorization_key].split(' ', 2)
end
@scheme ||= parts.first.downcase.to_sym

Рекомендация: не приводить к символам пользовательский контент.

Remote code execution

Первая информация об уязвимостях данного типа появилась в январе 2013 года. В течение месяца в рельсах было найдено три уязвимости, позволяющие выполнять произвольный код. Давай рассмотрим причины существования таких уязвимостей.

Исторически сложилось так, что рельсы обрабатывали параметры, представленные в различных форматах: urlencoded (обычные формы), JSON и даже XML. Кроме того, XML мог содержать внутри себя ноду, представленную в формате YAML, например:

<exploit type=”yaml”>---</exploit>

Кроме того, YAML мог инстанцировать (по сути, вызывать Object.new) любые классы в атакуемой системе, а потом назначать свойства через метод [] (доступ к элементу массива).

В конце концов исследователи нашли такие классы в системе, которые приводили к выполнению кода в результате обработки поступающих от пользователя произвольных данных. На момент публикации информации об этой уязвимости ей были подвержены все сайты на RoR (необходимо отметить, что в четвертой версии Rails отключена обработка XML-параметров по умолчанию). Рабочий эксплойт для данной уязвимости выглядит следующим образом:

    --- !ruby/hash:ActionController::Routing:: /
     RouteSet::NamedRouteCollection
    ? #{encoded_payload}
    : !ruby/struct
      defaults:
    :action: create
    :controller: foos
      required_parts: []
      requirements:
    :action: create
    :controller: foos
      segment_keys:
    - :format

Дальше — больше, и по похожей схеме. Оказалось, что JSON.parse вызывает внутри себя метод JSON.load, а JSON.load поддерживает инстанцирование “json_creatable?” классов. В рельсах было достаточно таких “json_creatable?” классов, чтобы довести это до удаленного выполнения произвольного кода. Хоть в паблике я эксплойта до сих пор не видел, Бен Мерфи (Ben Murphy), нашедший этот баг, гарантировал мне, что у него есть рабочий RCE.

Рекомендация: не использовать YAML и JSON.load для парсинга пользовательского инпута.

<html>
<body>You are being 
<a  href="javascript:alert(0)//HOST/">redirected</a>
</body>
</html>

Nils, integers и brute force

Первым багом, связанным с типами параметров, был nil. Дело в том, что Rack парсит параметры таким образом, что ?var дает params[:var]==nil, а значит, ?var[] дает массив [nil]. При этом многие разработчики часто проверяют наличие токена при восстановлении пароля следующим образом:

if params[:token]
 User.find_by_token params[:token]
end

Если передать ?token[] в адресной строке, то if params[:token] пройдет проверку, а ORM вернет первую же запись с пользователем, у которого поле token не задано (пустое). Такая ошибка была найдена мною в системе электронной коммерции Spree. Используя ссылку вида http://example.com/api?api_key[], можно было делать API-запросы от лица суперадмина, так как по умолчанию api_key получался пустой.

Спустя несколько недель после обнаружения описанной проблемы исследователи обратили внимание на то, как MySQL осуществляет сравнение строк с числами. В частности, выражение “random_token” = 0 вернет логическое значение true, так как будет осуществлено приведение типа строки к нулю. При этом возникает вопрос — как можно передать в приложение значение нуль? Ответ прост — используй JSON (например, объект {“token”:0}), и вот ты уже меняешь кому-то пароль! После обнаружения этой особенности авторы фреймворка отказывались что-либо менять, но после публикации деталей уязвимости и под воздействием общественного мнения разработчики решили исправить данное поведение приведя типы полей к тому, что от них ожидается в схеме базы, — строки к строкам, числа к числам.

Рекомендация: можно использовать баг в стиле brute-force — вместо ?token=123 отсылай POST body с содержанием token[]=1&token[]=2..., что позволит тебе за раз проверять более 10 тысяч вариантов.

Заключение

Да, в Rails выявлено много серьезных проблем. Но это говорит в первую очередь о росте фреймворка, а также о том, что Rails в процессе своего развития заставляет обычных разработчиков задумываться о безопасности их кода.

В блогосфере четко прослеживается усилившийся интерес к безопасности. Многие начали писать книги с названиями типа Ruby Security, некоторые создают онлайн-сканеры, остальные работают над brakeman (статический анализатор кода для Rails). Также есть Security Monitor от создателя Code Climate, который делает похожую работу, но «в облаке» и, разумеется, платный — 74 доллара в месяц (поэтому в годовой перспективе лучше нанять, например, меня :)). Прогресс определенно есть, и многие шутят, что если раньше рубисты были «одержимы» тестированием, то сейчас это место заняла безопасность.

Резюмируя сказанное, я могу с уверенностью утверждать, что из всех известных мне фреймворков, используемых для веб-разработки, Ruby on Rails обеспечивает на данный момент самый высокий уровень безопасности по умолчанию, не мешая при этом самому процессу разработки. Рекомендую!