» » » RubyRussia 2019. Михаил Пронякин: безопасен ли Ruby

 

RubyRussia 2019. Михаил Пронякин: безопасен ли Ruby

Автор: admin от 13-09-2019, 23:40, посмотрело: 29

На конференции RubyRussia будет много докладов о том, как писать код и как делать это лучше других. Но если продукт, который выпускает ваша компания, небезопасен, то это может привести к большим проблемам. Григорий Петров обсудил эту важную тему с Михаилом Пронякиным из компании «ОНСЕК», разработчик комплексной платформы «Валарм».



RubyRussia 2019. Михаил Пронякин: безопасен ли Ruby


Расскажи, чем ты занимаешься и как используешь Ruby?

«Валарм» — платформу для защиты и тестирования веб-приложений (и не только). Получается, что я одновременно и Ruby-разработчик, и специалист по информационной безопасности.



Твой доклад будет связан с этой темой. Расскажи подробнее. 



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



На твой взгляд, как сейчас Rails в плане обеспечения безопасности?



В философии Ruby и Rails существует такое понятие как «приоритет соглашения над конфигурацией». Если в соглашении все продумано, то никаких проблем с безопасностью и не появится. Но если вдруг возникает ситуация, что ты можешь по умолчанию написать уязвимый код, то это уже может стать причиной серьезных проблем. Особенно у начинающих разработчиков, которые только начали изучать Rails и даже не задумываются про безопасность своего кода. Если смотреть в прошлое, то раньше с безопасностью везде было хуже, чем сейчас. Это касается не только Ruby, но и других языков и фреймворков. С каждым годом фичи безопасности интегрируются во фреймворки все больше и глубже. Например, в Rails уже из коробки везде есть CSRF токены, что очень хорошо. И все это работает под капотом, но если ты не знаешь как и хочешь сделать что-то кастомное, то безопасность приложения может быть нарушена. 



Если рассматривать уязвимости, то их можно очень грубо поделить на 2 вида: это уязвимости в runtime и уязвимости самого языка. Когда-то давно в Python была печальная история — оказалось, что в Python хеш для словаря рассчитывается без соли. Можно было злонамеренно спровоцировать бесконечное количество коллизий. В результате словари переполнялись, и сервера умирали от нескольких мегабайт атакующих запросов. Скажи, в мире Rails, по твоему опыту, сколько уязвимостей приходится на сам Ruby, а сколько уязвимостей приходится на рельсы?



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



А по количеству можно ли как-то прикинуть, где находится больше уязвимостей? Вне Ruby и Rails, в самом языке, в его runtime, в стандартной библиотеке или в Rails как фреймворке, который использует Ruby?



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



За последние несколько лет какая была самая смешная уязвимость, которую ты или твои коллеги находили? Из серии «Ааа, ну это ж надо было так облажаться».



Самая запоминающаяся уязвимость была в геме, позволяющим озвучивать тексты. Ты ему передаешь текст, и он его озвучивает. Гем вызывал консольную утилиту и передавал ей параметры без должного экранирования. В результате обнаружилась инъекция в Bash, и можно было услышать результат выполнения произвольной команды. Ты передаешь на вход команду «ls /», а голос в ответ диктует «slash dev slash etc» и так далее.



Последние несколько лет экосистема языков сверхвысокого уровня – Python, Ruby, javascript – опирается на огромное количество маленьких библиотек. Их много, и они зависят друг от друга так, что убери какой-нибудь pad-left, и это убивает экосистему. Злоумышленники начинают либо делать свои библиотеки, либо брать контроль над чужими и добавлять в них какой-нибудь вредоносный код, который не найдешь. Насколько это сейчас большая и страшная проблема? 



Проблема есть, но пока о ней никто особо не думает, все полагаются «на авось». Если у злоумышленника есть цель атаковать конкретную компанию и определенным способом, то его сегодня никто не остановит. Ничто не мешает сделать просто хороший гем, набрать много звезд на GitHub и дождаться, пока все начнут его использовать. Затем скрытно встроить в него вредоносный код, что совсем не сложно. Думаю, вопрос зависимостей сегодня – это вопрос доверия: проблема открыта и ещё только ждет своего решения.



Увидимся на RubyRussia!



Вопросы на тему безопасности можно будет задать Михаилу после доклада, а так же обсудить на стенде его компании. Посмотреть на то, какие еще темы будут обсуждать рубисты 28 сентября можно на сайте.



А кроме спикеров и участников, можно познакомиться и с замечательными компаниями, которые поддерживают конференцию:



Организатор — Evrone

Генеральный партнер — Toptal

Золотой партнер — Gett

Серебярные партнеры — Валарм, JetBrains, Bookmate и Cashwagon

Бронзовый партнер — InSales

Источник: Хабр / Интересные публикации

Категория: Веб-разработка

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

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *