RubyRussia 2019. Mikhail Pronyakin: Ruby é seguro?

Haverá muitas palestras na conferência RubyRussia sobre como escrever código e como fazê-lo melhor do que outros. Mas se o produto que sua empresa lança for inseguro, isso pode levar a grandes problemas. Grigory Petrov discutiu esse importante tópico com Mikhail Pronyakin, da empresa ONSEK, desenvolvedora da plataforma Valarm integrada.


Diga-me o que você faz e como usa o Ruby?

Era uma vez, trabalhei como especialista na área de segurança da informação. Fez algo como o mais completo dos aplicativos da web e vários dispositivos físicos. Paralelamente, ele estava envolvido na programação de sistemas em C. Naquela época, como agora, a estrutura Metasploit era popular, que podia ser expandida com seus próprios módulos para pesquisar e explorar vulnerabilidades. Foi escrito em Ruby - então comecei a conhecer esse idioma. Depois fui trabalhar para a Onsek, onde, a princípio, acelerei algumas partes críticas do back-end do projeto, reescrevendo o código de Ruby para C, e comecei a escrever novas funcionalidades apenas em Ruby. As atividades de nossa empresa estão relacionadas à segurança da informação; estamos desenvolvendo o Valarm, uma plataforma para proteger e testar aplicativos da Web (e não apenas). Acontece que eu sou desenvolvedor de Ruby e especialista em segurança da informação.

Seu relatório estará relacionado a este tópico. Me conte mais.

O RoR oferece ao programador grandes oportunidades para escrever código, mas também existem pontos não óbvios que podem levar a problemas de segurança. Na conferência, falarei sobre vulnerabilidades típicas de aplicativos Ruby e darei exemplos práticos que ajudarão a evitar erros.

Na sua opinião, como está o Rails agora em termos de segurança?

Na filosofia de Ruby e Rails, existe algo como "prioridade de acordo sobre configuração". Se tudo for pensado no contrato, nenhum problema de segurança será exibido. Mas se surgir repentinamente uma situação de que você pode escrever código vulnerável por padrão, isso já pode causar problemas sérios. Especialmente para desenvolvedores iniciantes que começaram a aprender Rails e nem sequer pensam na segurança de seu código. Olhando para o passado, costumava ser pior em todos os lugares com segurança do que agora. Isso se aplica não apenas ao Ruby, mas também a outras linguagens e estruturas. Todos os anos, os recursos de segurança estão sendo integrados cada vez mais profundamente às estruturas. Por exemplo, o Rails já possui tokens CSRF prontos para uso em todos os lugares, o que é muito bom. E tudo isso funciona muito bem, mas se você não sabe e deseja fazer algo personalizado, a segurança do aplicativo pode ser comprometida.

Se considerarmos as vulnerabilidades, elas podem ser divididas em dois tipos: são vulnerabilidades no tempo de execução e vulnerabilidades da própria linguagem. Era uma vez em Python uma história triste - descobriu-se que, em Python, o hash do dicionário é calculado sem sal. Pode-se provocar maliciosamente um número infinito de colisões. Como resultado, os dicionários transbordaram e os servidores morreram devido a vários megabytes de solicitações de ataque. Diga-me, no seu mundo Rails, na sua experiência, quantas vulnerabilidades existem no próprio Ruby e quantas vulnerabilidades existem nos trilhos?

Se olharmos para o tópico vulnerabilidades, ele é muito mais extenso do que apenas Ruby e Rails. Por exemplo, temos nginx. Se não estiver configurado corretamente, você poderá simplesmente ler alguns arquivos do servidor e obter o segredo do aplicativo Rails. E é isso, o aplicativo está hackeado - faça o que quiser. Você precisa entender que a segurança não se limita a um idioma e estrutura - existe um ambiente em que é executado, um ambiente em que é montado e outro milhão de nuances diferentes.

E em termos de quantidade, você pode descobrir de alguma forma onde há mais vulnerabilidades? Fora do Ruby e Rails, na própria linguagem, em seu tempo de execução, na biblioteca padrão ou no Rails como uma estrutura que usa Ruby?

Eu diria que a maioria das vulnerabilidades está na junção entre a lógica do aplicativo e o próprio Rails ou outras funções da biblioteca.

Nos últimos anos, qual foi a vulnerabilidade mais engraçada que você ou seus colegas encontraram? Da série "Ahh, bem, é isso que você tinha que estragar dessa maneira".

A vulnerabilidade mais memorável estava na gema, permitindo textos de voz. Você dá a ele o texto, e ele o expressa. Gem chamou o utilitário do console e passou parâmetros para ele sem uma triagem adequada. Como resultado, uma injeção foi descoberta no Bash e você pode ouvir o resultado da execução de um comando arbitrário. Você envia o comando "ls /" para a entrada e a voz em resposta determina "slash dev slash etc" e assim por diante.

Nos últimos anos, o ecossistema de linguagens de nível superior - Python, Ruby, JavaScript - contou com um grande número de pequenas bibliotecas. Existem muitos deles, e eles dependem um do outro para remover um pouco da esquerda para a esquerda, e isso mata o ecossistema. Os invasores começam a criar suas bibliotecas ou controlam estranhos e adicionam códigos maliciosos que você não consegue encontrar. Quão grande e terrível é isso agora?

Existe um problema, mas até agora ninguém realmente pensa nisso, todo mundo confia "de forma aleatória". Se um invasor tem o objetivo de atacar uma empresa específica de uma certa maneira, ninguém o impedirá hoje. Nada impede que se faça apenas uma boa joia, ganhando muitas estrelas no GitHub e esperando que todos comecem a usá-la. Em seguida, incorpore secretamente código malicioso a ele, o que não é nada difícil. Penso que a questão das dependências hoje é uma questão de confiança: o problema está aberto e ainda aguarda sua solução.

Vejo você no RubyRussia!

Perguntas sobre o tema segurança podem ser feitas a Mikhail após o relatório, bem como discutidas no estande de sua empresa. Você pode ver outros tópicos que os rubistas discutirão em 28 de setembro no site .

Além de palestrantes e participantes, você pode se familiarizar com empresas maravilhosas que apóiam a conferência:

Organizador - Evrone
Parceiro Geral - Toptal
Parceiro Gold - Gett
Parceiros Silver - Valarm , JetBrains , Bookmate e Cashwagon
Parceiro Bronze - InSales