RailsConf 2015
The World of Rails Security

The World of Rails Security

by Justin Collins

The video "The World of Rails Security" presented by Justin Collins at RailsConf 2015 delves into the essential topic of securing Ruby on Rails applications. As security is often an overlooked area in web development, Collins emphasizes the importance of understanding and implementing security features provided by Rails while also acknowledging its limitations.

Key Points Discussed:
- Overview of Rails Security Features: Collins begins by clarifying that the talk focuses on security mechanisms, not hacking methods. He emphasizes Rails' efforts in providing security against common vulnerabilities.
- Cross-Site Scripting (XSS): An explanation of XSS attacks is provided, detailing how malicious scripts can be injected into web pages. The development of automatic escaping in Rails 3 is highlighted as a significant milestone for mitigating XSS vulnerabilities. A historical example, the "perktweet" incident, illustrates the real-world impact of XSS vulnerabilities.
- Cross-Site Request Forgery (CSRF): The risks associated with CSRF are explained, showcasing how Rails employs security tokens in forms to combat this type of attack. Improvements in Rails 4 for easier CSRF protection are also discussed.
- Session Management: The video explains how session management has progressed from signed cookies in earlier Rails versions to encrypted session cookies in Rails 4, enhancing security against session tampering.
- SQL Injection Vulnerabilities: Collins discusses the importance of avoiding SQL injection by using Active Record and warns against passing raw user input directly into query strings.
- Additional Security Challenges: The talk points out areas Rails does not inherently protect against, such as directory traversal attacks and open redirects. Developers must implement their own defensive measures for these vulnerabilities.
- Static Analysis Tools: Collins identifies a lack of robust static analysis tools for security, encouraging developers to use tools like Brakeman to identify vulnerabilities early in the development cycle.

Conclusions and Takeaways:
- Developers must proactively educate themselves about Rails security features.
- Utilizing existing libraries and static analysis tools are critical steps to improving application security.
- Staying informed about Rails updates is imperative for maintaining application security.

In summary, while Rails offers many built-in security features, it still requires concerted efforts from developers to implement best practices and mitigate vulnerabilities effectively.

00:00:11.440 Hello everyone! I want to take a moment to let you know that this talk is actually about Rails security. There’s been some changes in the schedule, so if you were looking for a specific talk, it's worth checking back to see if it has moved to another slot.
00:00:30.439 If you're here for security, this is the right place. I promise you'll walk away with some useful knowledge.
00:00:38.930 Now, before we dive deeper, I need to clarify that this talk isn’t about hacking Rails applications or conducting DDoS attacks. Instead, we're going to explore a broad overview of what Rails offers in terms of security, what it lacks, and most importantly, how to better secure your Rails applications.
00:01:03.050 We'll look at the basics of cross-site scripting (XSS) and cross-site request forgery (CSRF). I'll give you examples to illustrate these vulnerabilities and discuss what Rails does to mitigate them.
00:01:15.380 Let's start with cross-site scripting. It's a common attack that happens when an attacker injects malicious scripts into web pages. In Rails 2, developers had to manually escape everything to prevent this. But when Rails 3 was released, the framework introduced automatic escaping, which was a great improvement for security. Now, everything is escaped by default.
00:01:42.890 It is crucial to escape user input to prevent XSS attacks. A historical example of this type of vulnerability involved the TweetDeck application, where a script could inject and retweet itself—this was humorously referred to as the "perktweet" incident. It highlights the importance of keeping user-generated content safe.
00:02:14.210 Rails also provides several helper methods that are supposed to be pretty safe. However, developers need to be cautious because improper usage can still leave the application vulnerable. For instance, developers might write raw HTML directly, which could lead to security pitfalls.
00:02:43.090 Let's shift focus to CSRF, or cross-site request forgery. An attacker might trick a user into executing unwanted actions on a different website, and this is particularly dangerous when that user is already authenticated.
00:03:12.850 Rails combats CSRF attacks by implementing a protection mechanism that involves a security token in the session. This token is sent along with forms, ensuring that requests are authenticated.
00:03:31.000 Rails 4 improved upon this by making it even easier for developers to leverage CSRF protection, but it requires developers to maintain best practices in their code.
00:03:56.020 Another critical aspect is session management. By default, Rails uses cookie-based sessions. In earlier versions like Rails 2 and 3, these were signed cookies, meaning any modification to the cookie would invalidate the session. However, Rails 4 further improved security by switching to encrypted session cookies, which are more resistant to tampering.
00:04:24.880 As a developer, you need to be aware of SQL injection vulnerabilities as well. Rails uses Active Record, which helps mitigate SQL injections by ensuring that queries are structured to exclude raw user input without sanitization. But if developers are careless and pass user input directly into query strings, they can open themselves up to attacks.
00:05:17.110 You also need to implement some security measures on your own. Rails does not protect against directory traversal attacks, so those must be managed carefully in your application to ensure that users can't access unauthorized files.
00:06:35.040 It also lacks built-in prevention against open redirect vulnerabilities, which can be abused by attackers to redirect users to malicious sites. Developers must implement strict checks to control where users are redirected after authentication.
00:07:55.320 Another area that I find lacking is static analysis tools for detecting security vulnerabilities in your Rails application. Tools exist, but the community can benefit from more contributions. Static analysis tools can identify security flaws early in the development cycle, helping to prevent vulnerabilities from being deployed.
00:09:20.410 So, what can you do about these security challenges? First, educate yourself thoroughly about Rails security features and vulnerabilities. Second, utilize existing libraries to improve your application's defenses. For example, consider using gems like Rack Attack for rate limiting or Secure Headers to set security policies.
00:10:40.560 Lastly, utilize static analysis tools like Brakeman to check your application for existing vulnerabilities. This should be a part of your development pipeline to catch any potential issues early.
00:11:44.740 In summary, while Rails has provided many improvements over the years, the application still requires developers to implement best practices. Familiarize yourself with security mechanisms and tools, and stay informed about enhancements in new versions of Rails to ensure the safety of your application.