Category: Ruby

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

Перевод публикуется с сокращениями, автор оригинальной статьи Dhruv.

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

Острые ножи

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

«Острые ножи» – это все
доступное в Ruby метапрограммирование, и тот нюанс, что все открыто для
изменения/переопределения в любой момент. Дальше станет понятнее. Рассмотрим
ошибки и их решения.

Небезопасная десериализация

Выполнять все, что
пользователь собирался отправлять – плохая мысль. А вот сериализация/десериализация
пользовательского ввода не кажется такой уж плохой идеей, т. к. никакой код при этом не
выполняется.

Основанная на Psych встроенная библиотека YAML Ruby поддерживает сериализацию пользовательских типов данных в YAML и обратно:

        # serialize.rb
require 'yaml'
require 'set'

s = Set.new([1, 2, 3])
File.open('set.yml', 'w') do |file|
  YAML.dump(s, file)
end
    

        --- !ruby/object:Set
hash:
  1: true
  2: true
  3: true
    

Десериализация этого
YAML возвращает исходный тип данных:

        # deserialize.rb
require 'yaml'
require 'set'

file = File.read('set.yml')
s = YAML.load(file)
p s
    

        $ ruby deserialize.rb

#<Set: {1, 2, 3}>
    

Как вы можете видеть,
строка -- !ruby/object:
Set описывает, как повторно создавать экземпляры объектов из их текстовых
представлений. Это открывает множество векторов атаки, которые могут перерасти
в RCE.

Решение

Решение заключается в
использовании безопасной загрузки. Используйте функцию YAML::safe_load вместо
YAML::load. Она полностью блокирует загрузку пользовательских классов:

        # deserialize.rb
require 'yaml'
require 'set'

file = File.read('set.yml')
s = YAML.safe_load(file)
p s
    

        $ ruby deserialize.rb

/usr/ruby/2.7.0/psych/class_loader.rb:97:in `find':
Tried to load unspecified class: Set (Psych::DisallowedClass)
    

Стандартные типы вроде хэшей и массивов все еще могут быть сериализованы в документы YAML и
десериализованы из них, как и раньше.

        ---
hash:
  1: true
  2: true
  3: true
    

        $ ruby deserialize.rb

{"hash"=>{1=>true, 2=>true, 3=>true}}
    

IO hijacking

Если вашему приложению
необходимо читать или записывать пользовательские файлы с диска или делать
запросы через API к пользовательским URL-адресам, вы можете написать следующий код:

        # test.rb
puts 'Enter file path:'
path = gets.chomp
puts 'File contents:'
open(path, 'r') do |file|
  until file.eof? do
    puts file.gets
  end
end
    

У пользователя запрашивается
имя файла, а потом его содержимое выводится построчно. Здесь есть ошибка.

Функция Kernel::open из приведенного выше фрагмента кода имеет еще одну
дополнительную функцию, которая используется для порождения процессов. Посмотрите,
что происходит, когда вы передаете начинающиеся с символа конвейера ( | ) входные данные:

        $ ruby test.rb

Enter file path:
|date
File contents:
Sun Nov 15 22:03:33 IST 2020
    

Она выполняет команду
date и передает выходные данные обратно Ruby. Злоумышленник будет выполнять
команды гораздо более разрушительные, чем в этом коде. В нашем примере базовое
RCE – удаленный пользователь, выполняющий код на сервере с полными
привилегиями, доступными вашему веб-приложению.

Никогда не запускайте
код от ненадежного источника, такого как пользователь, но если все-таки придется
– ограничьте доступ к выбранным ресурсам.

Решение

Никогда не используйте
Kernel::open! Альтернативой является File::open, URL::open или
IO::open, в зависимости от контекста. Попробуем еще раз, на этот раз с
File::open вместо Kernel::open. Такой вариант гораздо более безопасен, поскольку он не дает доступа к shell:

        # test.rb
puts 'Enter file path:'
path = gets.chomp
puts 'File contents:'
File.open(path, 'r') do |file|
  until file.eof? do
    puts file.gets
  end
end
    

        $ ruby test.rb

Enter file path: 
|date
File contents:
Traceback (most recent call last):
	2: from test.rb:4:in `<main>'
	1: from test.rb:4:in `open'
test.rb:4:in `initialize': No such file or directory @ rb_sysopen - |date (Errno::ENOENT)
    

SQL injection

Инъекция происходит,
когда пользовательский ввод из фронтенда без проверок и очистки применяется непосредственно
в SQL-запросе на бекенде.

Допустим, у вас есть
столбец users, в котором выполняется
поиск по введенному в форму имени. Вот, как бы это выглядело в Ruby:

        User.where("name = '#{name}'")
    

Это небезопасно.
Рассмотрим следующий ввод от злоумышленника:

        name = " ' OR '1' = '1" # Ввод от злоумышленника
    

Запрос ложный, как видно
в первой строке и крашится из-за вредоносного кода, как показано во второй
строке. WHERE всегда true и возвращает
каждого пользователя из таблицы:

        SELECT * FROM users WHERE name = '<name>'         -- <name> ложный запрос
SELECT * FROM users WHERE name = ' ' OR '1' = '1' -- все сломалось
    

Решение

Используйте один из следующих
двух способов:

        User.where(["name = ?", name])
User.where({ name: name })
    

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

Автоинкремент ID

Когда вы создаете
модель Rails, автоматически создается id – автоинкрементное целочисленное
поле. По большей части этого достаточно. Целочисленные идентификаторы
имеют преимущество: поскольку они постоянно увеличиваются, нет никаких шансов
на коллизию. Что произойдет, если пострадает безопасность:

• Масштабирование может стать сложнее. Если множество серверов работают независимо друг от друга, вполне вероятно, что они могут назначить один и тот же ID разным ресурсам.
• Станет возможным определить, сколько у вас объектов. Можно зарегистрироваться и увидеть собственный идентификатор, чтобы узнать количество клиентов и даже оценить бизнес-показатели.
• Можно будет перебирать и красть данные. Злоумышленник сможет вывести весь список и получить все ограниченные ресурсы.
• Возможна утечка конфиденциальной информации. Незарегистрированные ресурсы, видимые только держателям ссылок, сломались бы из-за целочисленных ID.

Решение

Используйте UUID. С Rails
сделать это будет очень просто. После несложного изменения все ваши модели будут использовать UUID в качестве первичных ключей:

        # config/application.rb 
config.generators do |g|
  g.orm :active_record, primary_key_type: :uuid
end
    

Если вы все-таки хотите
использовать целые числа, берите большие, выбранные случайным образом. Посмотрим
на структуру URL-адресов ролика из YouTube. Так выглядит его URL-адрес:

        https://www.youtube.com/watch?v=dQw4w9WgXcQ
    

Идентификатор видео – это
случайное число между $0$ и $64^{11}$ (более 73 квинтиллионов чисел), закодированное
в Base64. Не совсем UUID, но и не целочисленное поле с автоинкрементом.

Инструменты в помощь

Ключевой вывод из описанных выше примеров – никогда не доверять юзеру. Данные пользователя не
должны быть напрямую сериализованы/десериализованы, оценены или обработаны. В
качестве дополнительных мер предосторожности подойдет специальный софт.

Статические анализаторы кода

Инструменты анализа
кода, такие как линтеры и сканеры уязвимостей, могут найти множество просчетов
до того, как те начнут эксплуатироваться. RuboCop уведомит вас о проблемах безопасности, вроде небезопасной десериализации или IO
hijacking, а также предложит варианты исправления.

Brakeman
– сканер уязвимостей, который может найти SQL-инъекцию среди других ошибок
безопасности. Оба инструмента являются бесплатными и поставляются с открытыми исходными текстами.

DeepSource – комплексное ПО, способное сканировать код, на каждом коммите, анализировать результаты работы линтеров/анализаторов
и автоматически устранять множество проблем.

Для большинства языков программирования это решение имеет собственные
пользовательские анализаторы, которые постоянно совершенствуются
и обновляются. А еще оно элементарно устанавливается – нужно всего лишь
добавить .deepsource.toml файл в корень репозитория и DeepSource готов:

        version = 1

[[analyzers]]
name = "ruby"
enabled = true

[[transformers]]
name = "rubocop"
enabled = true
    

Заключение

Проблемы с безопасностью
– самые опасные и дорогостоящие. Будьте предельно внимательны и учитывайте все
вышесказанное в своих проектах. Обязательно продолжайте изучать язык программирования, ошибки других разработчиков и нашу статью про ошибки новичков. Удачи!