Search
Application Security
...But Doesn't Rails Take Care of Security for Me?
Edit
#rails-security
#application-security
#sql-injection
#cross-site-scripting-xss
#cross-site-request-forgery
#best-practices
Summarized using AI

...But Doesn't Rails Take Care of Security for Me?

Justin Collins • May 13, 2016 • Kansas City, MO

In the presentation titled "...But Doesn't Rails Take Care of Security for Me?" at RailsConf 2016, Justin Collins explores the misconception that the Ruby on Rails framework adequately handles all security concerns for web applications. He emphasizes that while Rails offers protections against common vulnerabilities such as SQL injection, cross-site scripting, and cross-site request forgery, developers cannot rely solely on the framework for security. Rather, they must understand the limitations and responsibilities involved in securing their applications.

Key Points Discussed:

  • Rails Security Features & Limitations:

    • Rails implements foundational security measures like strong parameters and encrypted session cookies, but is not a complete safeguard against all security threats.
    • Collins highlights that security extends beyond known vulnerabilities and requires vigilance and understanding of the entire application context.

  • Real-World Vulnerability Case Studies:

    Collins shares specific incidents from notable companies to illustrate common security pitfalls:

    • Twitter: An insecure direct object reference allowed a researcher to delete payment methods without proper ownership validation, resulting in a $2,800 payout.
    • United Airlines: A vulnerability permitted access to sensitive information of other MileagePlus accounts through unfettered input modification.
    • Domino's Pizza: Poor handling of the payment process enabled order placements without validating payment success, highlighting the need for secure communication practices.
    • Ashley Madison: This infamous data breach was attributed to poor security controls and weak coding practices, underscoring the risks of mismanaging sensitive data.
    • Collins also discusses vulnerabilities in Facebook’s password reset process and issues faced by platforms like Imgur and Instagram.

  • Takeaways for Developers:

    • Trust Relationships: Developers must verify that users have permission to perform actions and should not blindly trust client-side data.
    • Secure Coding Practices: Utilize strong hashing algorithms, implement rate limiting, and avoid storing sensitive credentials in the source code.
    • Educational Resources: Collins recommends the OWASP Top 10 and other practical exercises like Railsgoat for enhancing security knowledge.

Conclusion:

Collins concludes by urging developers to educate themselves about security and to take proactive measures in their applications. He emphasizes that while frameworks like Rails provide valuable security features, the onus of keeping applications secure ultimately lies with the developers. Furthermore, he touches upon the nuances of bug bounty programs and how companies can approach payouts with their unique budgets.

In summary, the talk serves as a crucial reminder that security is multifaceted and cannot be overlooked even in robust frameworks like Rails. Developers are encouraged to understand their security landscape thoroughly and assume responsibility for safeguarding their applications.

...But Doesn't Rails Take Care of Security for Me?
Justin Collins • May 13, 2016 • Kansas City, MO

Rails comes with protection against SQL injection, cross site scripting, and cross site request forgery. It provides strong parameters and encrypted session cookies out of the box. What else is there to worry about? Unfortunately, security does not stop at the well-known vulnerabilities and even the most secure web framework cannot save you from everything. Let's take a deep dive into real world examples of security gone wrong!

RailsConf 2016

00:00:10.880 We have about three minutes before we're supposed to start, but who was here for Mike's talk just a few minutes ago?
00:00:18.590 Okay, so this is like part two. Just when you thought it was safe to go back on the web, Mike covered some specific problems and breaches that have happened. When I saw he was speaking, I sent him an email saying, 'Hey, your talk sounds really similar to mine. You're discussing breaches, and I thought I'd go through some real things that have been found.' Here’s a list of things I might talk about. Does this conflict with anything you’re discussing?
00:00:33.300 I couldn’t believe it; he wrote back saying he wasn’t going to talk about any of those. Although he did mention Ashley Madison, he didn’t elaborate on it. So if you were in that talk, this is kind of similar, but with a focus on details of vulnerabilities that have been found in different sites. In case you were curious about this talk versus that one, I just really like to talk.
00:00:56.610 We have one minute before we’re officially supposed to start. I like to use vacation pictures for my title slides. This is a meteor crater in Arizona; it's the first crater anyone recognized as having come from a meteor. For a long time, they thought it was volcanic. It's quite large, though I don't remember exactly how big.
00:01:45.810 Now, to start the real talk: my name is Justin Collins, and you can find me as @beef on Twitter and most of the internet. I wanted to give this talk because I've heard people say phrases very similar to this over the years.
00:01:52.259 At least one person this week asked the question: 'But isn't Rails pretty good at security? Doesn't it do a lot for me?' So I thought it was a suitable title for this talk. The question is: does Rails take care of security for me? The answer is, no, it doesn't. And that's all I have. Thank you! I would have shared pictures of my cats, but everyone does that, and mine are not as funny-looking as Aaron's. So here’s my turtle instead.
00:03:31.459 I hate doing these slides, but it's somewhat relevant. This is a Snapchat snapshot of what I look like. I've been working in application security for about six years and have been involved with the Brakeman open-source project for essentially the same amount of time. Over the last couple of years, I’ve worked on Brakeman Pro, which is for users who want to be more professional about their security tools.
00:04:03.049 And if you really like Brakeman but don’t feel the need for the Pro version, you can buy licenses for it to support the open-source project, even if you don't use them.
00:04:40.990 This talk is more about what Rails does give you and does not give you. Last year, I gave a talk titled 'Vacation to the Grand Canyon,' discussing the security features of Rails: the good, the bad, and the areas for improvement. Brian Helmkamp a couple of years before me talked about Rails' insecure defaults, some of which have since changed.
00:05:06.439 This talk focuses on real cases, primarily sourced from public disclosures, mostly from bug bounties. I'm not picking on these companies; I actually like most of them, especially Twitter, where I work. These are simply some of the well-documented write-ups that I found useful to share with you.
00:05:54.860 Let’s start with Twitter. Similar to what Mike mentioned earlier, a researcher was looking around on our ad site and noticed how, when entering a credit card that wasn’t valid, a modal would pop up saying, 'We weren't able to approve that card,' with options to try again or dismiss.
00:06:06.770 However, when he dismisses that modal, there is a URL being hit. Inside that URL are indicators that suggest the account ID and that the payment method is being referenced, which brought the researcher’s attention. He assumed that this ID was probably the identifier for the payment method. So he thought, 'What if I just change this ID? Does it still work?' And it turns out, it did. The backend code allowed him to delete that payment method.
00:07:23.119 This type of issue is classified as an insecure direct object reference, which means the system is not validating whether the user attempting to perform the action (deleting a payment method) owns that payment method. This resulted in a payout of $2,800 because deleting a customer's payment method could seriously impact how Twitter operates.
00:08:15.559 Next is United Airlines, which launched a bug bounty program. A researcher conducted some testing and found that by modifying his MileagePlus number in a POST request to their system, he could access sensitive personal information about other accounts, including flight details and even emergency contact information. After reporting the issue, he faced resistance from the company to implement a fix.
00:09:12.140 Now we have Domino's Pizza. A researcher initially sought to understand how their mobile app generated coupons but discovered how their payment process worked. Instead of securely handling payments, the app would send credit card information directly to the payment processor and assumed their validation as a success based on whatever was returned without checking the actual status.
00:10:38.170 This started a chain of discovery: by tampering with the return status, he placed the order without proper validation of the payment status. If the server had checked with the payment processor for confirmation, the vulnerability could have been avoided.
00:11:29.110 The theme in security is not to trust inputs blindly. The main conclusion is about understanding the relationships of trust within your application. You must assess who or what to trust when developing an application.
00:12:55.070 Ashley Madison had a massive data breach, leading to millions of user account details being leaked online. Part of their issue was poorly secured codes, which stored sensitive keys in easily accessible places, making it possible for attackers to exploit the system. Even using bcrypt for passwords isn’t inherently secure if additional weak coding practices are in place.
00:15:39.640 The weaknesses lay in their attempt to hash but ultimately failing to secure the login key. Identifying hashing algorithms’ strength or weaknesses is vital; they should prioritize adequate algorithms over easier, riskier ones.
00:17:22.230 There are significant areas where security protocols can fail, even in recognizable companies. The researcher found important credentials left unguarded, showing how crucial it is for organizations to consider how they store and manage these sensitive keys.
00:19:11.980 In another example, Facebook had vulnerabilities around their password reset functionality, which is often seen as a weak point in security. By exploiting a lack of rate limiting on their beta site, the researcher found he could access user accounts with not much more than knowledge of their username or email.
00:25:24.540 There was also an issue with Imgur's URL handling when processing video links. A researcher discovered that by manipulating the server to fetch content irresponsibly, it became possible to exploit their internal systems, leading to unauthorized access.
00:28:15.860 Another interesting case involves a researcher investigating an Instagram-related admin panel which was open source. He discovered that important secret keys were left in the source code of an older version of the application's codebase. The exploitation began with accessing the panel through forged session cookies, leading to a chain of compromising additional information.
00:34:45.150 To summarize this section, here are crucial points: Verify that the current user can perform actions they're trying to do, be aware of trust relationships in your architecture, and never trust client-side information. Always utilize strong hashing algorithms, implement rate limiting, and do not store secrets directly in source code. These practices are essential for maintaining security.
00:37:56.960 People often ask about resources for improving security knowledge. OWASP's Top 10 is a fantastic resource. Their proactive security controls documentation is highly informative as well. If you're interested in hands-on exercises, check out the Railsgoat project or the Enthusiast Security Casts for practical learning experiences.
00:39:24.180 I have stickers available for anyone who wants them after the next talk. I’ll be in the lunch area for additional discussions regarding security.
00:39:46.360 If your company is located in the San Francisco Bay Area, please reach out if you want me to come and speak to your team about these security issues. Thank you all for your attention.
00:41:52.790 In conclusion, questions about bug bounty payouts often arise. There's no clear answer to what these should be, as companies have their unique budgets for such programs. Establishing a balance during negotiations is essential for both parties.
Justin Collins
@presidentbeef
Explore all talks recorded at RailsConf 2016
+106