In this post, we’ll look at the security blindspots of lockfile injection that a Ruby gem might expose via its Gemfile.lock. As a prelude to that, we will open up with a brief introduction to Ruby and third-party dependencies management around RubyGems and Bundler. Web developers often work on Ruby projects, but are mostly referring to them as the popular open source web application framework Ruby on Rails.
Secure your apps! Protect sensitive data! Easy to say, harder to find solid answers on all the bits and pieces you need to adjust to make sure that happens. That's why we've put together this list of practical advice for securing your Ruby on Rails applications. Whether you're a Rails developer or work on any stack that relies on cloud technologies, we think you'll find something that stands out.
Ruby, much like other programming languages, has an entire ecosystem of third-party open source libraries which it refers to as gems, or sometimes Ruby gems. These gems are authored by the community, and are available from RubyGems.org which is the official registry for Ruby libraries. Similarly to other open source ecosystems, threat actors may publish deliberate malicious code or such which includes backdoors or credentials harvesting.
It’s been a bad month for RubyGems vulnerabilities. Critical CVE-2022-29176 was issued May 8, 2022, and another critical CVE-2022-29218 was discovered less than a week later, on May 11. This new vulnerability would allow for a takeover of new versions of some platform-specific gems under certain circumstances.
On May 6, 2022, a critical CVE was published for RubyGems, the primary packages source for the Ruby ecosystem. This vulnerability created a window of opportunity for malicious actors to take over gems that met the following criteria: Because RubyGems provides data dumps that include a lot of information, it is unfortunately relatively simple to create an automated mining process for these criteria.
The notorious Log4Shell vulnerability CVE-2021-45046, has put Log4j in the spotlight, and grabbed the entire Java community’s attention over the last couple of weeks. Maintainers of Java projects that use Log4j have most probably addressed the issue. Meanwhile, non-java developers are enjoying relative peace of mind, knowing that they are unaffected by one of the major vulnerabilities found in recent years. Unfortunately, this is an incorrect assumption.
Ruby is a well-defined and thought-out language and has been around since the mid-1990s. In 2004, Ruby incorporated RubyGems as its package manager. RubyGems is used to manage libraries and dependencies in a self-contained format known as a gem. The interface for RubyGems is a command line tool that integrates with the Ruby runtime and allows Gemfiles to be added or updated in a project. I looked at three Ruby platforms and found vulnerabilities that were surprising, even to me.
This post’s topic is very straightforward: SQL injection, Ruby flavored. More specifically, how you can protect your Ruby application against SQL injections—and other common security threats. Ruby is a wonderful language for beginner coders to start with and scale to large, distributed Web and Desktop applications. It has an accepting and helpful community. Also, it strives to keep itself up to date to match the needs of developers.
Do you know those things that are simultaneously incredibly important to get right but incredibly easy to get wrong? That makes for an explosive combination. One such thing happens to be one of the hardest areas in software development: security. Security is hard no matter the language or platform. Today, we’re here to talk specifically about security best practices in Ruby.
Saying that digital security is “important” would be the understatement of the century. It’s probably the most crucial aspect of any application nowadays. Unfortunately, security is easy to get wrong, and many developers and organizations do. Count yourself lucky if you never encountered a site that stores passwords in plain text, for instance.
