На конференции RubyRussia будет много докладов о том, как писать код и как делать это лучше других. Но если продукт, который выпускает ваша компания, небезопасен, то это может привести к большим проблемам. Григорий Петров обсудил эту важную тему с Михаилом Пронякиным из компании «ОНСЕК», разработчик комплексной платформы «Валарм».
Расскажи, чем ты занимаешься и как используешь Ruby?
Когда-то, давным-давно я работал специалистом в области информационной безопасности. Делал что-то вроде пентестов веб-приложений и различных физических устройств. Параллельно с этим занимался системным программированием на языке C. В то время, как и сейчас, был популярен фреймворк Metasploit, который можно было расширять собственными модулями поиска и эксплуатации уязвимостей. Он был написан на Ruby — так началось мое знакомство с этим языком. Затем я перешел работать в компанию «Онсек», где сначала ускорял некоторые критические части бэкенда проекта путем переписывания кода с Ruby на C, а потом стал писать новую функциональность только на 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
Расскажи, чем ты занимаешься и как используешь Ruby?
Когда-то, давным-давно я работал специалистом в области информационной безопасности. Делал что-то вроде пентестов веб-приложений и различных физических устройств. Параллельно с этим занимался системным программированием на языке C. В то время, как и сейчас, был популярен фреймворк Metasploit, который можно было расширять собственными модулями поиска и эксплуатации уязвимостей. Он был написан на Ruby — так началось мое знакомство с этим языком. Затем я перешел работать в компанию «Онсек», где сначала ускорял некоторые критические части бэкенда проекта путем переписывания кода с Ruby на C, а потом стал писать новую функциональность только на 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