RubyRussia 2019. Mikhail Pronyakin: is Ruby safe?
There will be many talks at the RubyRussia conference on how to write code and how to do it better than others. But if the product that your company launches is unsafe, this can lead to big problems. Grigory Petrov discussed this important topic with Mikhail Pronyakin of the ONSEK company, the developer of the integrated Valarm platform.
Tell me what you do and how you use Ruby?
Once upon a time, I worked as a specialist in the field of information security. Did something like the pentest of web applications and various physical devices. In parallel with this, he was engaged in system programming in C. At that time, as now, the Metasploit framework was popular, which could be expanded with its own modules for searching and exploiting vulnerabilities. It was written in Ruby - this is how my acquaintance with this language began. Then I went to work for Onsek, where at first I accelerated some critical parts of the project backend by rewriting code from Ruby to C, and then I began to write new functionality only in Ruby. Our company’s activities are related to information security, we are doing Valarm, a platform for protecting and testing web applications (and not only). It turns out that I am both a Ruby developer and an information security specialist.
Your report will be related to this topic. Tell me more.
RoR gives the programmer great opportunities for writing code, but there are also unobvious moments that can lead to security problems. At the conference, I will talk about typical vulnerabilities of Ruby applications and give practical examples that will help to prevent mistakes.
In your opinion, how is Rails now in terms of security?
In the philosophy of Ruby and Rails, there is such a thing as “prioritization of convention over configuration”. If everything is thought out in the agreement, then no security problems will appear. But if a situation suddenly arises that you can write vulnerable code by default, then this can already cause serious problems. Especially for novice developers who just started learning Rails and don't even think about the security of their code. Looking into the past, it used to be worse with security everywhere than now. This applies not only to Ruby, but also to other languages ​​and frameworks. Every year, security features are being integrated more and more deeply into the frameworks. For example, Rails already has CSRF tokens out of the box everywhere, which is very good. And all this works under the hood, but if you don’t know how and want to do something custom, then the application’s security may be compromised.
If we consider vulnerabilities, they can be very roughly divided into 2 types: these are vulnerabilities in runtime and vulnerabilities of the language itself. Once upon a time in Python there was a sad story - it turned out that in Python the hash for the dictionary is calculated without salt. One could maliciously provoke an infinite number of collisions. As a result, the dictionaries overflowed, and the servers died from several megabytes of attacking requests. Tell me, in your Rails world, in your experience, how many vulnerabilities are in Ruby itself, and how many vulnerabilities are in rails?
If we look at the subject of vulnerabilities, then it is much more extensive than just Ruby and Rails. For example, we have nginx. If it is not configured correctly, then you can simply read some files from the server and get the secret of the Rails application. And that's it, the application is hacked - do what you want. You need to understand that security is not limited to one language and framework - there is an environment where it is executed, an environment where it is assembled, and another million different nuances.
And in terms of quantity, can you somehow figure out where there are more vulnerabilities? Outside of Ruby and Rails, in the language itself, in its runtime, in the standard library, or in Rails as the framework that uses Ruby?
I would say that most of the vulnerabilities are at the junction between the application logic and the Rails themselves or other library functions.
Over the past few years, what was the funniest vulnerability you or your colleagues found? From the series "Ahh, well, that’s why I had to screw up like that."
The most memorable vulnerability was in the gem, allowing you to voice texts. You give him the text, and he voices it. Gem called the console utility and passed parameters to it without proper screening. As a result, an injection was discovered in Bash, and you could hear the result of executing an arbitrary command. You send the command “ls /” to the input, and the voice in response dictates “slash dev slash etc” and so on.
Over the past few years, the ecosystem of super-high-level languages ​​- Python, Ruby, JavaScript - has relied on a huge number of small libraries. There are many of them, and they depend on each other so that remove some pad-left, and this kills the ecosystem. Attackers begin to either make their own libraries or take control of strangers and add some malicious code to them that you cannot find. How big and terrible is this now?
There is a problem, but so far no one really thinks about it, everyone relies "at random". If an attacker has a goal to attack a specific company in a certain way, then nobody will stop him today. Nothing prevents making just a good gem, gaining a lot of stars on GitHub and waiting for everyone to start using it. Then, covertly embed malicious code into it, which is not at all difficult. I think the question of dependencies today is a question of trust: the problem is open and still only waiting for its solution.
See you at RubyRussia!
Questions on the topic of security can be asked to Mikhail after the report, as well as discussed at the stand of his company. You can look at what other topics the rubists will discuss on September 28 on the website .
And besides speakers and participants, you can get acquainted with wonderful companies that support the conference:
Organizer - Evrone
General Partner - Toptal
Gold Partner - Gett
Silver Partners - Valarm , JetBrains , Bookmate, and Cashwagon
Bronze Partner - InSales
Tell me what you do and how you use Ruby?
Once upon a time, I worked as a specialist in the field of information security. Did something like the pentest of web applications and various physical devices. In parallel with this, he was engaged in system programming in C. At that time, as now, the Metasploit framework was popular, which could be expanded with its own modules for searching and exploiting vulnerabilities. It was written in Ruby - this is how my acquaintance with this language began. Then I went to work for Onsek, where at first I accelerated some critical parts of the project backend by rewriting code from Ruby to C, and then I began to write new functionality only in Ruby. Our company’s activities are related to information security, we are doing Valarm, a platform for protecting and testing web applications (and not only). It turns out that I am both a Ruby developer and an information security specialist.
Your report will be related to this topic. Tell me more.
RoR gives the programmer great opportunities for writing code, but there are also unobvious moments that can lead to security problems. At the conference, I will talk about typical vulnerabilities of Ruby applications and give practical examples that will help to prevent mistakes.
In your opinion, how is Rails now in terms of security?
In the philosophy of Ruby and Rails, there is such a thing as “prioritization of convention over configuration”. If everything is thought out in the agreement, then no security problems will appear. But if a situation suddenly arises that you can write vulnerable code by default, then this can already cause serious problems. Especially for novice developers who just started learning Rails and don't even think about the security of their code. Looking into the past, it used to be worse with security everywhere than now. This applies not only to Ruby, but also to other languages ​​and frameworks. Every year, security features are being integrated more and more deeply into the frameworks. For example, Rails already has CSRF tokens out of the box everywhere, which is very good. And all this works under the hood, but if you don’t know how and want to do something custom, then the application’s security may be compromised.
If we consider vulnerabilities, they can be very roughly divided into 2 types: these are vulnerabilities in runtime and vulnerabilities of the language itself. Once upon a time in Python there was a sad story - it turned out that in Python the hash for the dictionary is calculated without salt. One could maliciously provoke an infinite number of collisions. As a result, the dictionaries overflowed, and the servers died from several megabytes of attacking requests. Tell me, in your Rails world, in your experience, how many vulnerabilities are in Ruby itself, and how many vulnerabilities are in rails?
If we look at the subject of vulnerabilities, then it is much more extensive than just Ruby and Rails. For example, we have nginx. If it is not configured correctly, then you can simply read some files from the server and get the secret of the Rails application. And that's it, the application is hacked - do what you want. You need to understand that security is not limited to one language and framework - there is an environment where it is executed, an environment where it is assembled, and another million different nuances.
And in terms of quantity, can you somehow figure out where there are more vulnerabilities? Outside of Ruby and Rails, in the language itself, in its runtime, in the standard library, or in Rails as the framework that uses Ruby?
I would say that most of the vulnerabilities are at the junction between the application logic and the Rails themselves or other library functions.
Over the past few years, what was the funniest vulnerability you or your colleagues found? From the series "Ahh, well, that’s why I had to screw up like that."
The most memorable vulnerability was in the gem, allowing you to voice texts. You give him the text, and he voices it. Gem called the console utility and passed parameters to it without proper screening. As a result, an injection was discovered in Bash, and you could hear the result of executing an arbitrary command. You send the command “ls /” to the input, and the voice in response dictates “slash dev slash etc” and so on.
Over the past few years, the ecosystem of super-high-level languages ​​- Python, Ruby, JavaScript - has relied on a huge number of small libraries. There are many of them, and they depend on each other so that remove some pad-left, and this kills the ecosystem. Attackers begin to either make their own libraries or take control of strangers and add some malicious code to them that you cannot find. How big and terrible is this now?
There is a problem, but so far no one really thinks about it, everyone relies "at random". If an attacker has a goal to attack a specific company in a certain way, then nobody will stop him today. Nothing prevents making just a good gem, gaining a lot of stars on GitHub and waiting for everyone to start using it. Then, covertly embed malicious code into it, which is not at all difficult. I think the question of dependencies today is a question of trust: the problem is open and still only waiting for its solution.
See you at RubyRussia!
Questions on the topic of security can be asked to Mikhail after the report, as well as discussed at the stand of his company. You can look at what other topics the rubists will discuss on September 28 on the website .
And besides speakers and participants, you can get acquainted with wonderful companies that support the conference:
Organizer - Evrone
General Partner - Toptal
Gold Partner - Gett
Silver Partners - Valarm , JetBrains , Bookmate, and Cashwagon
Bronze Partner - InSales
All Articles