00:00:11.000
Hi everyone, security is a crucial aspect of every web application, and the good news is that Rails is particularly well-suited for applications with high security standards. In my talk today, I will highlight the recent security-related changes in Rails, and in the second half, I will explain why I believe Rails is a good choice for security.
00:00:30.599
First of all, let me introduce myself. My name is Greg, and I became a Rails developer about 14 years ago when I saw the famous 'Build a Blog in 15 Minutes' video. A few years later, I took a contract with a security consultancy, which piqued my interest in security. I started to learn more about it, and eventually, I became a certified penetration tester. I did penetration testing while working in Rails development part-time because I love to break software, but I also love to build software. Recently, I stopped doing penetration testing to focus on bug bounty hunting and Rails development.
00:01:10.119
Now, let's move on to the more important stuff: the actual talk. The first change I want to talk about was introduced in Rails 7.2 and is the integration of Dependabot. Rails 7.2 ships with a generated Dependabot configuration file for GitHub Actions. If you don't know what Dependabot is, it's a tool that alerts you about outdated and insecure dependencies.
00:01:27.679
Why is that important? When a CVE (Common Vulnerabilities and Exposures) is published for a gem, automated attacks can occur within a day. So if you don't upgrade your applications, you might get hacked. I'll provide examples where Rails is quite secure, but we still have CVEs published quite frequently. For instance, Action Text had a recent CVE published, as well as Flex, which had three recent XSS issues—one of which I discovered. Additionally, the Sidekiq UI had a recent XSS vulnerability. While the ecosystem is generally secure, issues still arise, and using Dependabot will alert you to these problems quickly, allowing you to upgrade your applications and maintain safety.
00:02:09.640
For those using an older version of Rails, you can easily copy the CI configuration file to stay secure. If you're not on GitHub, I recommend using 'bundle audit', which is a valuable tool for checking vulnerabilities.
00:02:32.519
The next change is regarding Brakeman, a static code analyzer included in the default CI file with Rails. Brakeman helps identify security issues within your code. While it isn't a silver bullet and won't find every issue, it will identify a significant number of them. It does sometimes generate false positives, but you can typically ignore those in your CI configuration. That's about it for Brakeman.
00:03:35.840
The next change is a very important one: Rails now has built-in rate limiting. Rate limiting is crucial as it helps prevent attacks such as credential stuffing, which is a highly common threat today due to the abundance of leaked password databases. This type of attack attempts to gain access to accounts by trying various leaked passwords. For example, 23andMe experienced a significant data breach a few months ago, and instead of taking responsibility, they blamed users for reusing passwords. Developers should work to prevent security issues, following the example of companies like General Motors and Roku, which also endured credential stuffing attacks due to compromised password databases.
00:05:01.920
The new rate limiter in Rails is simple to implement. You just need to add a single line to your authentication controller. You can set a parameter to specify how many requests you want to allow, and the system will manage the timing of requests. Functions like 'only' or 'except' can be used to control which actions this rate limiting applies to. Furthermore, Rails 8 will introduce multi-rate limiting methods within the same controller.
00:05:41.960
Requests will be grouped by IP address by default, but you can change this setting if needed. Rails uses a 429 Too Many Requests response for rate limiting by default, but you have the option to customize this. You can redirect users to a different page or display a user-friendly flash message for the 429 errors. Importantly, there are no dependencies for this feature; it does not require Redis and can simply utilize your existing database for storage.
00:07:19.560
Now, let's talk about an exciting new feature in Rails 8: the built-in authentication generator. This is a feature many have requested over the years. While authentication is often customized, it can be challenging to have a one-size-fits-all solution. The new generator provides a simple authentication setup that you can build upon. Running the generator with 'bin/rails generate authentication' will show you the files that will be generated.
00:08:03.319
This authentication system is straightforward, which minimizes opportunities for errors and reduces the attack surface for potential vulnerabilities. It supports password-based login and an email-based password reset flow, built on Rails helpers for secure password handling. Moreover, it includes rate limiting configuration right out of the box. What it doesn't include are signups, password validation, or multi-factor authentication; however, these can be easily implemented using Rails’ built-in helpers.
00:09:09.180
Another change worth noting is the update to the Rails maintenance policy. Minor releases will now receive security fixes for two years after their first release. For example, if a hypothetical Rails 1.1.0 was released on January 1, 2023, it will receive security fixes until January 1, 2025. After this period, it will reach its end of life, and it is the responsibility of developers to handle any bugs or security issues.
00:09:29.859
Ultimately, to keep applications secure, it's critical to keep them updated. A smaller change has introduced CVV and CVC filtering within the default parameters of Rails. This filter is important for ensuring sensitive information like authentication tokens and API tokens are kept out of logs. Properly utilizing this tool can help prevent leaking sensitive data.
00:09:40.240
Now let's look at why you should choose Rails for security. Rails provides tools for virtually everything. For instance, in security questionnaires, you'll often see questions like 'Do you encrypt data at rest?' This can be a complex question in many frameworks, but with Rails, there's Active Record encryption to handle this for you, which includes cryptographic functionality. This feature supports both deterministic and non-deterministic encryption, allowing you the flexibility to search your data as needed.
00:10:50.080
Another common security question is, 'Do you use strong cryptographic methods?' Rails offers built-in strong cryptography for session cookies, data caching, and more. You don't have to think about it; it's set up securely by default. For handling secure tokens, Rails has great new helpers, such as Active Record secure token, which simplifies the process of creating password reset tokens and API keys, complete with expiration settings. Identifying and retrieving records by these tokens is also straightforward.
00:11:45.960
If you need to address issues like credential stuffing or brute-force attacks, Rails’ built-in rate limiter can help. However, if you need something more advanced, there are other tools available, such as RCH, which operates at the request level and could suffice for more complex applications. For smaller applications, I recommend starting with the built-in rates as it raises awareness of security needs more naturally.
00:12:51.040
It's crucial not to store sensitive information in logs, as these might be accessed through vulnerabilities in the system. Regular audits of developer access to production data are also essential. Rails provides options like PaperTrail to track changes to your Active Record models, but it's vital to store your audit logs in a write-only table. This prevents anyone from tampering with audit records and losing your security history.
00:13:51.760
When it comes to dependencies, you shouldn't worry too much about vulnerabilities, thanks to Dependabot and bundle audit. These tools simplify management of your dependencies and help maintain application security with ease. Implementing a content security policy is another best practice to mitigate risks of XSS attacks. Although Rails provides good support against XSS, a well-structured content security policy can help further reduce exposure.
00:14:56.840
Finally, Rails comes equipped with built-in protection against open redirects, meaning you won't need to worry about these vulnerabilities by default. The framework raises exceptions for such cases, allowing developers to handle them via custom logic, ensuring users are aware and confirming any potential external redirects.
00:15:49.960
In summary, I believe Rails is one of the best options for applications that require high security standards. Rails has tools for just about everything, and our community is increasingly aware of and focused on security. The future looks bright for security within the Rails ecosystem.
00:16:40.760
As a final note, I'm the co-editor of a community-run newsletter titled 'This Week in Rails,' where we share weekly updates on changes in Rails. If you're interested in keeping up with new features, I encourage you to subscribe. If you have any questions, I have some time available now, or you can find me later—I'm very approachable and happy to talk about security or any other related topics.
00:17:54.600
Now, do we have any questions?
00:19:16.240
Authorization issues tend to be complex because they depend on custom rules for your application. It's important to implement a whitelist approach. You should be restrictive and allow only what you want to permit; this way, if there's a breach, the harm is minimized.
00:21:16.680
Regarding page authorization, a popular gem for role-based authorization is Pundit. However, it's quite easy to implement your own system using plain Ruby objects. Don't fear security; it requires time and diligence, but it's not rocket science.
00:22:14.920
When asked about bug bounty programs, I believe every company should consider creating one, even if it isn't officially managed. Simply having a page on your site stating that you welcome reports of vulnerabilities can make a difference. Review the application security of various gems you plan to use.
00:23:17.040
To wrap up, the key takeaway is to own your authentication process and carefully manage your sensitive data to better protect against potential security breaches.
00:23:22.760
Thank you, everyone, for your time and attention!
