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!