RubyRussia 2019. Mikhail Pronyakin: Ruby est-il sûr?

Il y aura de nombreuses discussions lors de la conférence RubyRussia sur la façon d'écrire du code et de le faire mieux que d'autres. Mais si le produit que votre entreprise lance n'est pas sûr, cela peut entraîner de gros problèmes. Grigory Petrov a discuté de ce sujet important avec Mikhail Pronyakin de la société ONSEK, le développeur de la plate-forme intégrée Valarm .


Dites-moi ce que vous faites et comment vous utilisez Ruby?

Il était une fois, j'ai travaillé comme spécialiste dans le domaine de la sécurité de l'information. A fait quelque chose comme le pentest des applications Web et divers appareils physiques. Parallèlement à cela, il était engagé dans la programmation système en C. A cette époque, comme maintenant, le framework Metasploit était populaire, qui pouvait être étendu avec ses propres modules de recherche et d'exploitation des vulnérabilités. Il a été écrit en rubis - c'est ainsi qu'a commencé ma connaissance de cette langue. Ensuite, je suis allé travailler pour Onsek, où j'ai d'abord accéléré certaines parties critiques du backend du projet en réécrivant le code de Ruby en C, puis j'ai commencé à écrire de nouvelles fonctionnalités uniquement dans Ruby. Les activités de notre entreprise sont liées à la sécurité des informations, nous faisons Valarm, une plate-forme pour protéger et tester les applications Web (et pas seulement). Il s'avère que je suis à la fois développeur Ruby et spécialiste de la sécurité de l'information.

Votre rapport sera lié à ce sujet. Dites m'en plus.

RoR donne au programmeur de grandes opportunités d'écrire du code, mais il y a aussi des points non évidents qui peuvent conduire à des problèmes de sécurité. Lors de la conférence, je parlerai des vulnérabilités typiques des applications Ruby et donnerai des exemples pratiques qui aideront à prévenir les erreurs.

À votre avis, comment va Rails en termes de sécurité?

Dans la philosophie de Ruby and Rails, il existe une «priorité d'accord sur la configuration». Si tout est pensé dans l'accord, aucun problème de sécurité n'apparaîtra. Mais si une situation survient soudainement que vous pouvez écrire du code vulnérable par défaut, cela peut déjà causer de graves problèmes. Surtout pour les développeurs novices qui viennent de commencer à apprendre Rails et ne pensent même pas à la sécurité de leur code. En regardant dans le passé, la sécurité était pire partout aujourd'hui que maintenant. Cela s'applique non seulement à Ruby, mais également à d'autres langages et frameworks. Chaque année, les fonctionnalités de sécurité s'intègrent de plus en plus profondément dans les frameworks. Par exemple, Rails a déjà des jetons CSRF prêts à l'emploi partout, ce qui est très bien. Et tout cela fonctionne sous le capot, mais si vous ne savez pas comment faire et souhaitez faire quelque chose de personnalisé, la sécurité de l'application peut être compromise.

Si nous considérons les vulnérabilités, elles peuvent être très grossièrement divisées en 2 types: il s'agit des vulnérabilités au moment de l'exécution et des vulnérabilités du langage lui-même. Il était une fois en Python une triste histoire - il s'est avéré qu'en Python le hachage du dictionnaire est calculé sans sel. On pourrait malicieusement provoquer un nombre infini de collisions. En conséquence, les dictionnaires ont débordé et les serveurs sont morts de plusieurs mégaoctets de requêtes d'attaque. Dites-moi, dans votre monde Rails, d'après votre expérience, combien de vulnérabilités sont dans Ruby lui-même et combien de vulnérabilités sont dans les rails?

Si nous regardons le sujet des vulnérabilités, alors il est beaucoup plus étendu que Ruby et Rails. Par exemple, nous avons nginx. S'il n'est pas configuré correctement, vous pouvez simplement lire certains fichiers du serveur et obtenir le secret de l'application Rails. Et c'est tout, l'application est piratée - faites ce que vous voulez. Vous devez comprendre que la sécurité n'est pas limitée à un langage et à un framework - il y a un environnement où il est exécuté, un environnement où il est assemblé et un autre million de nuances différentes.

Et en termes de quantité, pouvez-vous en quelque sorte déterminer où il y a le plus de vulnérabilités? En dehors de Ruby et Rails, dans le langage lui-même, dans son exécution, dans la bibliothèque standard ou dans Rails en tant que framework qui utilise Ruby?

Je dirais que la plupart des vulnérabilités sont à la jonction entre la logique d'application et les Rails eux-mêmes ou d'autres fonctions de bibliothèque.

Au cours des dernières années, quelle a été la vulnérabilité la plus drôle que vous ou vos collègues ayez trouvée? De la série "Ahh, eh bien, c'est ce que vous avez dû foutre comme ça."

La vulnérabilité la plus mémorable était dans le joyau, permettant les textes vocaux. Vous lui donnez le texte, et il l'exprime. Gem a appelé l'utilitaire de console et lui a transmis des paramètres sans filtrage approprié. Par conséquent, une injection a été découverte dans Bash et vous pouviez entendre le résultat de l'exécution d'une commande arbitraire. Vous envoyez la commande "ls /" à l'entrée, et la voix en réponse dicte "slash dev slash etc" et ainsi de suite.

Au cours des dernières années, l'écosystème des langages de très haut niveau - Python, Ruby, JavaScript - s'est appuyé sur un grand nombre de petites bibliothèques. Il y en a beaucoup, et ils dépendent les uns des autres, ce qui enlève un peu de pad-left, et cela tue l'écosystème. Les attaquants commencent soit à créer leurs propres bibliothèques, soit à prendre le contrôle d'étrangers et à leur ajouter du code malveillant que vous ne pouvez pas trouver. À quel point est-ce grand et terrible maintenant?

Il y a un problème, mais pour l'instant personne n'y pense vraiment, tout le monde se fie "au hasard". Si un attaquant a pour objectif d'attaquer une entreprise spécifique d'une certaine manière, personne ne l'arrêtera aujourd'hui. Rien n'empêche de faire juste un bon bijou, de gagner beaucoup d'étoiles sur GitHub et d'attendre que tout le monde commence à l'utiliser. Ensuite, incorporez secrètement du code malveillant, ce qui n'est pas du tout difficile. Je pense que la question des dépendances est aujourd'hui une question de confiance: le problème est ouvert et attend toujours sa solution.

Rendez-vous à RubyRussia!

Des questions sur le thème de la sécurité peuvent être posées à Mikhail après le rapport, ainsi que discutées sur le stand de son entreprise. Vous pouvez voir quels autres sujets les rubistes discuteront le 28 septembre sur le site Web .

Et en plus des conférenciers et des participants, vous pouvez vous familiariser avec de merveilleuses entreprises qui soutiennent la conférence:

Organisateur - Evrone
Associé commandité - Toptal
Partenaire Gold - Gett
Partenaires Silver - Valarm , JetBrains , Bookmate et Cashwagon
Partenaire Bronze - InSales