Search
Ruby on Rails
The Evolution of Rails Security
Edit
#rails-security
#ruby-on-rails
#web-security
#cross-site-request-forgery-csrf
#authentication
Summarized using AI

The Evolution of Rails Security

Justin Collins • May 17, 2018 • Pittsburgh, PA

In this presentation titled "The Evolution of Rails Security" at RailsConf 2018, Justin Collins, an expert in application security and the creator of the Breakman security tool, discusses the development and improvements in security features for Ruby on Rails. The talk is divided into two parts: an overview of past security vulnerabilities and an examination of the modern security measures implemented in Rails.

Key Points Discussed:

  • Historical Context:

    • Rails, since its inception in 2004, has had various security issues, starting from its first CVEs shortly after its initial release which highlighted how vulnerabilities were often handled poorly back then compared to today.
    • Key vulnerabilities included remote code execution due to file loading issues and concerns around mass assignment security flaws which became a significant topic of discussion and led to critical changes in Rails framework.

  • Significant Vulnerabilities:

    • Major security incidents were discussed, including the 2013 Rails apocalypse involving YAML deserialization vulnerabilities that could allow attackers to execute code on the server.
    • The talk also addressed cross-site request forgery (CSRF) and how Rails updated its protection measures to combat such attacks.

  • Security Features Evolved:

    • Collins outlines essential security features introduced over the years, such as auto-escaping of outputs, introduction of strong parameters for better attribute whitelisting, and the introduction of session security headers.
    • Newer features mentioned include per-form CSRF tokens, default security headers in Rails, encrypted session cookies, and content security policy support to prevent XSS attacks.

  • Continuous Improvement:

    • The presentation emphasizes the ongoing evolution of Rails concerning security practices and features, encouraging developers to stay informed and utilize resources like the Rails security guide.

Conclusions and Takeaways:

  • The overall security landscape of Rails has changed dramatically since its early days, with learned lessons leading to a more robust framework.
  • Developers are advised to be proactive about security, utilize the available tools such as Breakman, and follow best practices outlined in the Rails security guide.
  • The speaker expresses optimism for the future of Rails security, highlighting that despite the past challenges, the framework continues to add important safety features to protect developers and users alike.
    This session underlines a crucial aspect of web development: the importance of security, demonstrating that as frameworks evolve, so must our understanding and implementations of security features.

The Evolution of Rails Security
Justin Collins • May 17, 2018 • Pittsburgh, PA

RailsConf 2018: The Evolution of Rails Security by Justin Collins

Rails has a reputation for being secure by default, but how deserved is that reputation? Let's take a look back at some of the low points in Rails security history: from the first Rails CVE, to the controversial GitHub mass assignment, the 2013 Rails apocalypse, and more recent remote code execution issues. Then we'll cheer ourselves up with the many cool security features Rails has added over the years! We'll cover auto-escaping, strong parameters, default security headers, secret storage, and less well-known features like per-form CSRF tokens and upcoming Content Security Policy support.

RailsConf 2018

00:00:10.940 All right, welcome everyone! Today, I am going to be talking about Rails security and the history of Rails security.
00:00:18.060 My name is Justin Collins, and I'm the president of Beef on the Internet. I have a fair amount of slides to cover, more than I'm normally comfortable with.
00:00:23.250 There’s a lot of information, so I might over-explain some things and not explain others enough. If I mention something that you don’t understand or a term that’s unfamiliar, I encourage you to look it up online. The slides have numerous links, and I always post them on my website afterward, so you can click through to learn more and dive deeper into the details.
00:01:08.970 The talk is essentially divided into two parts: the first part will cover various security issues that Rails has faced in the past, and the second part will discuss some of the features that have been added over the years.
00:01:17.759 This is my sixth RailsConf and my fifth time speaking. This is also my second time sponsoring, although I didn’t get enough to be on the big screen you saw at the beginning of the conference. I’ve been involved in application security for about eight years and have worked at several different companies, mainly working on a security tool for Rails called Breakman.
00:01:38.939 Does anyone here use Breakman? Okay, so for those who didn’t raise their hands, if you are working on a Rails app, you should definitely try Breakman. I’ll give a brief tutorial on it about halfway through my talk.
00:01:58.950 Additionally, I’ve been working on Breakman Pro, which is essentially a more advanced version of Breakman, as suggested by its name. This conference has already addressed a lot of the history surrounding Rails, so some of what I discuss might be repetitive.
00:02:07.799 To give you a brief overview, Rails was released in July 2004, and here is the email from DHH to the mailing list announcing Rails 0.5, marking it as no longer vaporware. By the end of 2005, Rails 1.0 was officially released, and in August 2006, less than a year later, four CVEs (Common Vulnerabilities and Exposures) for Rails were announced.
00:02:28.830 If you’re wondering what CVEs are, they are essentially identifiers assigned to publicly announced vulnerabilities so that we can discuss them coherently. The middle number is typically the year they were identified, which helps track vulnerabilities over time. In 2006, two significant CVEs were reported for Rails. I appreciate the posts surrounding this event, as they offer insight into how security issues were handled at the time. There was a notable post by DHH on August 9, 2006, informing users about a mandatory security upgrade but withholding details about the specific vulnerabilities, which is something you don’t see anymore in the community. Now, when vulnerabilities are released, detailed information is typically provided so everyone understands the potential impact.
00:03:22.170 On August 10th, a follow-up post occurred at an odd hour, providing a bit more detail about the security issue but still emphasizing the seriousness of the vulnerability. The day after that, DHH posted once more, indicating that the issue wasn’t fully resolved and recommending an upgrade. While this is a valuable historical reference, it also showcases the panic experienced by software teams encountering security issues for the first time.
00:04:07.320 In trying to understand the vulnerability, Evan Weaver and I analyzed the diffs between Rails versions 1.4, 1.5, and 1.6 to figure out what went wrong. The vulnerability stemmed from the routing layer mistakenly loading arbitrary files. For example, if a URL matched a certain pattern and there was a file in the public directory, Rails would load and execute it. This led to what we call RCE (Remote Code Execution), which is the most severe type of vulnerability, allowing attackers to execute code on your server.
00:05:01.330 In 2007, CVE-2007-5380 was interesting as it simply dropped a feature. At that time, it was common to see session IDs passed via URLs. Given the lack of HTTPS adoption back then, sensitive information was easily intercepted, leading to security concerns. As a result, when the CVE was announced, the Rails team decided to prohibit passing session IDs through URLs entirely, moving to a cookie-only method instead.
00:08:06.020 Jumping ahead to 2011, there was another significant CVE related to Cross-Site Request Forgery (CSRF). This type of attack could occur when a user was logged into their bank account and visited a malicious site, which then sent unauthorized requests to the bank's site. It's important to ensure that state-changing actions are behind post requests rather than gets, and Rails handles CSRF protection using the synchronizer token pattern.
00:09:44.990 Rails also adapted to the evolution of security threats, particularly around JavaScript requests. In earlier versions, it was assumed that attackers could not make cross-domain XMLHttpRequests, but vulnerabilities surfaced that allowed this through Flash and similar technologies. As a response, Rails modified its CSRF protection strategies, introducing meta tags requiring tokens for all non-get requests.
00:11:57.890 In 2012, the topic of mass assignment arose, where Rails allowed mass updates leading to potential security risks. A notable incident involved a 18-year-old security researcher named Igor who discovered that he could exploit this feature in GitHub, resulting in public discussion and changes to how mass assignment was handled in Rails. Later versions adopted white-listing and strong parameters to manage this risk.
00:14:58.550 The subject of remote code execution re-emerged with several vulnerabilities in 2013. This included issues with deserializing arbitrary Ruby objects via serialization, leading to potential exploitations. Moreover, Rails’ handling of JSON also allowed attackers to send crafted requests, resulting in similar risks to executing arbitrary code on the server. After identifying these vulnerabilities, the Rails community took steps to disable unneeded serialization features.
00:20:26.790 Various CVEs around that time also illuminated the issues associated with directory traversal. By allowing files to be rendered based on user input, attackers could access sensitive files if protections were not properly defined. This period underscored the importance of thorough input validation and cautious handling of user-submitted data.
00:21:59.830 As we moved into 2017, new challenges arose for handling Cross-Site Scripting (XSS) vulnerabilities. Developers faced a choice between sanitizing input or escaping potentially unsafe characters. However, sanitization proved to be a significant challenge, while escaping was generally more feasible and encouraged. Rails began adopting more security headers, such as X-Frame-Options and Content Security Policies, with a focus on enhancing overall application security.
00:24:31.890 Further enhancements in Rails came with features like encrypted session cookies in Rails 4.0, which helped address security concerns related to sensitive data exposure. The ability to enforce HTTPS and utilize Strong Parameters provided developers with robust security tools. Rails 5 introduced per-form CSRF tokens to enhance security and prevent exploitation of stolen CSRF tokens. Recent versions have continued to build on these foundations, further reinforcing the security posture of Rails applications.
00:31:13.430 In closing, the Rails security landscape has evolved significantly from its early days. The community has responded to vulnerabilities with proactive measures, integrating features that enhance the security of applications. I encourage you all to explore the Rails security guide, which remains the go-to resource for the latest security recommendations. Thank you for your attention, and please check out Breakman if you haven't already. And by the way, sticker distribution is a requirement for speakers at RailsConf. Thank you again for attending!
Justin Collins
@presidentbeef
Explore all talks recorded at RailsConf 2018
+98