Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
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!
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
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.
Suggest modifications
Cancel
