Ruby Video
Talks
Panel: Security
Bryan Helmkamp
@brynary
Piotr Niełacny
@LTe
2 more speakers
See all speakers
#security
#ruby-on-rails
#web-security
#cross-site-scripting-xss
Summarized using AI

Panel: Security

by Bryan Helmkamp, Piotr Niełacny, Richard Schneeman, and Arne Brasseur

The panel discussion on security at the wroc_love.rb 2013 event featured speakers Bryan Helmkamp, Richard Schneeman, Piotr Niełacny, and Arne Brasseur. They explored various security principles in the context of Ruby and Rails, emphasizing both best practices and common pitfalls. The following key points were discussed:

  • Security Principles in Rails: The panel highlighted Rails' built-in security features, such as SQL injection prevention, cross-site request forgery (CSRF) protection, and proper escaping of strings in views.
  • Importance of the Secret Token: Speakers stressed the risks associated with the secret token in Rails applications, advising developers to use environment variables in production and not to hard-code secrets.
  • Method Definitions for Routes: With Rails 4, developers will need to explicitly define method types for routes, reducing the risk of unintended vulnerabilities.
  • Defense in Depth: The panel underscored the concept of having a layered security approach, where multiple strategies are employed to secure applications, rather than relying on a single measure.
  • Handling Interpolated Strings: They warned against the dangers of using interpolated strings improperly, which can lead to vulnerabilities in various contexts (HTML, SQL, JavaScript).
  • Enhancing Code Security with Tools: Tools like Brakeman were recommended for scanning applications to identify security vulnerabilities during code reviews.
  • Cultural Considerations: Building a strong security culture through education and practices like code reviews was deemed crucial, especially in larger teams.
  • Managing External Gems: The speakers discussed minimizing security risks from unused or outdated gems and the importance of having proper versioning practices to manage security updates and patches.
  • Community Responsibility: They emphasized the need for a robust communication process around vulnerabilities and the importance of mailing lists to stay updated on security issues.
  • Learning from Issues: Past challenges faced by the Ruby ecosystem were examined to draw lessons for future improvements in security infrastructure and practices.

In conclusion, the panel reinforced that maintaining security is an ongoing process that requires vigilance, continuous learning, and community collaboration. Developers were encouraged to build applications with security as a foundational aspect while remaining adaptable to new threats and security challenges as they arise.

00:00:18.320 So now we have a panel about security. I will hand things over to the gentlemen here.
00:00:24.080 If you would be so kind, please introduce yourselves.
00:00:31.560 I'm Richard Schneeman. I work for Heroku, and I just gave a talk on security. Nice to meet you all.
00:00:38.079 I'm Arne Brasseur. You might know me from the lightning talk about security from yesterday.
00:00:46.440 If you ask me, I will be minimal about what we can do in Ruby.
00:00:54.920 Last year, I participated in creating a scanning tool for security.
00:01:00.640 I'm Bryan Helmkamp, the founder of Code Climate. I also gave a lightning talk about security.
00:01:06.760 Alright, I would like to start with the topic of security principles, how they relate to Ruby and Rails, and maybe what Rails gives us by default that we sometimes take for granted.
00:01:20.159 For example, Rails helps prevent SQL injections when we use it in the proper way with method helpers.
00:01:31.680 Rails is a web framework that addresses two structural problems with web applications: cross-site request forgery and cross-site scripting.
00:01:41.040 Rails tries hard to ensure that you do the right thing with security tokens.
00:01:47.840 Additionally, escaping in views is now enabled by default, which goes a long way in preventing cross-site scripting issues.
00:02:08.399 However, developers still need to know what they are doing. I appreciate that Rails is mostly secure by default unless serious mistakes are made.
00:02:34.040 I've been using Rails for five or six years, and if there is a generalizable fix for something, they implement it. That reliability is commendable.
00:02:51.400 Steve is famous for pointing out that every time I use Sinatra, I end up building an impromptu copy of Rails, which lacks CSRF protection by default. It doesn't provide encrypted cookies either.
00:03:09.799 Rails does a lot for developers without them having to worry about numerous security measures.
00:03:29.879 However, one thing I've been emphasizing recently is the insecure default concerning the secret token in your Rails application.
00:03:43.080 Most developers don’t realize that the secret token in the config file is essentially a root key to the entire application. Rails provides numerous security measures but including a root key that is easily checked into version control is risky.
00:04:15.200 We've been discussing ways to improve this situation so that it remains easy for developers to use, but also discourages committing the same secret token for production and development environments.
00:04:30.320 In production, the secret token should be configured using environment variables.
00:05:01.919 Moreover, there is another aspect that Rails currently doesn't manage. It's crucial to recognize when your CSRF protection token is not being checked during GET requests, which is a common situation.
00:05:27.400 Often, GET requests are considered safe, but mistakes occur when you have controller actions that are not resourceful, leading to potential vulnerabilities.
00:05:43.960 Rails 4 will tackle this issue by requiring explicit method definitions for routes. This is a helpful development that increases security.
00:06:09.440 Rails does a fantastic job of defining security defaults, but once you go beyond those defaults, you can easily lose track of vital security principles.
00:06:28.500 When discussing security with developers, I find the principles to be the most compelling aspect, as technology is ever-evolving.
00:06:46.000 Rails will continually introduce new security measures, and vulnerabilities in web applications will keep evolving; however, it is crucial to focus on underlying security principles.
00:07:05.079 For instance, the concept of defense in depth: we shouldn’t hinge the entire security on a single measure since if that measure fails, vulnerabilities emerge.
00:07:19.000 Securing applications requires a mindset focused on defense, privilege management, and understanding attack vectors.
00:07:47.080 Now, it's also important to watch out for string interpolation. Using interpolated strings can pose security risks, especially when they carry different semantics like HTML, SQL, CSS, or JavaScript.
00:08:01.680 That's why there are various methods for escaping strings; many security issues arise from improper handling in these interpolated strings.
00:08:23.679 For example, if you are developing a single-page application with lots of JavaScript, ensure that the JSON data is properly escaped to avoid vulnerabilities.
00:08:56.319 Rails, being a complex framework, might require developers to navigate a lot of strings carefully.
00:09:06.760 Mass assignment has been a significant topic in Rails security, as tools for whitelisting and blacklisting attributes must be implemented correctly by developers.
00:09:50.720 While Rails 4 introduces controller-level assignments, programmers must remain vigilant as they can still implement insecure practices.
00:10:08.399 Security is an emergent property of a system; issues often surface at boundaries between different layers of an application.
00:10:35.920 For example, if data is transferred improperly between the application and the database or from the application to the browser, vulnerabilities may arise.
00:11:06.679 Thus, examining these interlayer interactions provides insight when assessing application security, especially concerning shell injections.
00:11:45.560 Regarding security tools that can help identify potential vulnerabilities in code, tools like Brakeman can assist in manual code reviews.
00:12:14.919 Brakeman is a security scanning solution that analyzes your application's code to track data flow and detect vulnerabilities.
00:12:45.080 Another important point is to sanitize input not merely at the outer layer of an application but also at every internal layer.
00:13:08.280 This layered approach promotes better security by stopping vulnerabilities from spreading, thereby making your system more robust.
00:13:23.280 Moreover, cultural tools such as education and code reviews are absolutely crucial. In larger teams, employing practices like Github flow with pull requests for code reviews goes a long way.
00:13:49.919 While security vulnerabilities will always exist, establishing a support network can help ensure continuous scrutiny over code and practices.
00:14:17.919 The recent vulnerabilities in the Ruby community have sparked dialogue about how to approach and mitigate these security challenges.
00:14:42.919 Understanding attack surfaces is vital; while you can't predict future vulnerabilities, you can minimize risk by limiting what's publicly available, such as unused gems.
00:15:07.799 For instance, disabling XML parsing libraries if they're unnecessary can effectively shrink your application's attack surface.
00:15:24.720 Learning from past security mistakes from other communities equips us to develop more secure software.
00:15:45.160 However, recognizing that specific issues may be different, the overarching lesson is to minimize surface area and complexity to limit potential vulnerabilities.
00:16:10.240 We're now aware of the need for structured communication around vulnerabilities, especially when discussing upgrade strategies.
00:16:39.360 The Ruby community has learned the importance of having a robust upgrade plan for eliminating vulnerabilities when shifting from one version of Rails to another.
00:17:02.000 One particular lesson learned relates to cryptography and the necessity of having proper key management to ensure trust in the system.
00:17:39.320 The RubyGems.org issue demonstrated the importance of solid cryptographic practices and adequate infrastructure to prevent trust issues.
00:18:07.720 We need to look towards other ecosystems, particularly in terms of creating signed packages with verifiable signatures.
00:18:28.840 Recent improvements in security, such as Content Security Policies (CSP), have provided developers with better tools to protect their applications.
00:19:03.360 CSPs allow developers to define where scripts can be sourced from, significantly aiding in preventing cross-site scripting attacks.
00:19:21.440 By setting these policies in headers, developers can control script execution, ensuring only trusted sources are allowed.
00:20:02.280 In terms of staying updated about security issues, subscribing to mailing lists is critical.
00:20:38.399 When vulnerabilities arise, companies should reach out to their users fervently, as Heroku did during the YAML vulnerability incident.
00:21:04.640 Having contingency plans prepared for potential compromises is another key element in managing security threats effectively.
00:21:34.400 Prompt communication and awareness can lead the way for immediate action, safeguarding systems and data.
00:22:14.560 The Rails community executes structured approaches to vulnerability disclosures, which significantly helps to manage security concerns.
00:22:49.920 However, many gems lack formal processes for security disclosures, creating uncertainty for developers relying on those dependencies.
00:23:16.080 Efforts are underway to document all vulnerabilities related to Ruby gems in a single database, which aims to better inform developers.
00:23:53.680 As gem authors deal with vulnerabilities, the dilemma between yanking affected versions or continuing to support users relying on those versions becomes critical.
00:24:38.560 When developers streamline their deployment processes, they can manage issues proactively, avoiding situations like the ones witnessed with rapid exploitations.
00:25:05.240 Faster deployments enhance an organization's ability to respond to vulnerabilities efficiently.
00:25:29.120 Maintaining strong versioning discipline is also essential; using semantic versioning allows developers to manage bug fixes and security updates without substantial risk.
00:26:16.600 Active participation in version control systems can help keep track of updates and maintain valuable security practices.
00:26:48.920 Discussions around the importance of LTS (Long Term Support) in libraries can also help communities create long-lasting secure practices, potentially inspired by successful models from other languages.
00:27:10.960 Active discussions regarding semantic versioning, upgrade strategies, and error handling in collaborative coding practices are also essential.
00:27:29.120 Improving education and awareness among community members is vital to helping developers create more secure applications.
00:28:05.760 By fostering a culture that emphasizes security as a fundamental aspect of software development, the Rails community can empower future developers to write more secure code.
00:28:38.560 It is crucial for the community to collaborate on crafting educational resources and best practices that reflect evolving security challenges.
00:29:00.560 In this way, developers will be better prepared to address security challenges as they arise.
00:29:12.600 Thank you all for participating in this important discussion on security.
Edit
Explore all talks recorded at wroc_love.rb 2013
+30