TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why the Latest Rails Exploit Is Indicative of a Bigger Problem

61 pointsby hhaidarover 12 years ago

5 comments

dfcarneyover 12 years ago
Their server is down. Here's the content:<p>-- by Rohit Sethi on February 13, 2013 -- <a href="http://blog.sdelements.com/author/rohit/" rel="nofollow">http://blog.sdelements.com/author/rohit/</a><p>The latest Rails security flaw [1] is example of a common anti-pattern. Ned Batchelder wrote an awesome post [2] explaining how a similar issue may also exist in Python’s YAML parser [3]. Looking at these vulnerabilities, I am reminded of similar flaws in other frameworks and libraries.<p>The issue in each case is an abuse of extensibility. At first glance the idea is clever: allow for run-time execution of new code or binding of server-side variables without changing your compiled code, thereby greatly enhancing extensibility. For example, provide extensions to your Python YAML parser that allow you to create arbitrary objects and execute Python code; provide extensions to XML Template parsing that allows for arbitrary command execution [4]; or dynamically assign user-supplied parameters to server-side variables [5] (aka mass assignment) based on the parameter name. This kind of vulnerability is by design in contrast to many other by accident vulnerabilities. We called the mass assignment anti-pattern out [6] several years ago when doing a security analysis of the Core Java EE Patterns for OWASP.<p>I have a strong feeling we’ll see more vulnerabilities of this type, particularly with the rising popularity of standards like SAML that are built upon several layers of libraries implementing and extending complex specifications. These kind of issues can sometimes be hard to catch with an automated scanning technology, which means most organizations adopting the status quo of application security due diligence [7] will undoubtedly miss detecting some instances of extensibility abuse.<p>Security-minded developers can protect themselves by taking the following steps:<p>Turn off unnecessary extensibility in third party libraries and frameworks Do not use untrusted input in libraries that provide broad extensibility, such as Apache’s Xalan [8] with extensions enabled.<p>Be vigilant about monitoring for and patching newly discovered vulnerabilities in frameworks and third party libraries. Wherever possible, sign up for security mailing lists or groups like Ruby on Rails Security [9]<p>[1] <a href="http://www.zweitag.de/en/blog/ruby-on-rails-vulnerable-to-mass-assignment-and-sql-injection" rel="nofollow">http://www.zweitag.de/en/blog/ruby-on-rails-vulnerable-to-ma...</a> [2] <a href="http://nedbatchelder.com/blog/201302/war_is_peace.html" rel="nofollow">http://nedbatchelder.com/blog/201302/war_is_peace.html</a> [3] <a href="http://pypi.python.org/pypi/PyYAML" rel="nofollow">http://pypi.python.org/pypi/PyYAML</a> [4] <a href="http://labs.securitycompass.com/tutorials/xslt-command-execution-exploit/" rel="nofollow">http://labs.securitycompass.com/tutorials/xslt-command-execu...</a> [5] <a href="http://www.codeproject.com/Articles/471784/Exploiting-Microsoft-MVC-vulnerabilities-using-OWA" rel="nofollow">http://www.codeproject.com/Articles/471784/Exploiting-Micros...</a> [6] <a href="https://www.owasp.org/index.php/Category:OWASP_Security_Analysis_of_Core_J2EE_Design_Patterns_Project/PresentationTier#Avoid_3" rel="nofollow">https://www.owasp.org/index.php/Category:OWASP_Security_Anal...</a> [7] <a href="http://blog.sdelements.com/raising-the-bar-on-application-security-due-diligence/" rel="nofollow">http://blog.sdelements.com/raising-the-bar-on-application-se...</a> [8] <a href="http://xml.apache.org/xalan-j/extensions.html" rel="nofollow">http://xml.apache.org/xalan-j/extensions.html</a> [9] <a href="https://groups.google.com/forum/?hl=en&#38;fromgroups#!forum/rubyonrails-security" rel="nofollow">https://groups.google.com/forum/?hl=en&#38;fromgroups#!forum...</a>
评论 #5220108 未加载
评论 #5220247 未加载
ehsanfover 12 years ago
I believe over-engineering is also a culprit here. We had a similar situation in JSON handling in browser. Some over engineered feature allows custom objects to replace built in object for lists, allowing XSS through JSON parser. The solution was to make every REST API to start with a top level dictionary object. It just sounds arbitrary over engineering!!
评论 #5224444 未加载
eykoover 12 years ago
Google text version cache: <a href="http://webcache.googleusercontent.com/search?q=cache:9m5PdBh6sEkJ:blog.sdelements.com/why-the-latest-rails-exploit-is-indicative-of-a-bigger-problem/&#38;hl=en&#38;tbo=d&#38;gl=uk&#38;strip=1" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:9m5PdBh...</a>
评论 #5221259 未加载
amalagover 12 years ago
I also don't understand why all parsing of user input needs to have YAML turned on by default. All this stuff should be turned off. I think it is a fundamental design choice that has to be looked at.
评论 #5224465 未加载
static_typedover 12 years ago
Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineering is hard, and it is heartening to see more people realise and promote awareness of some of the more dangerous anti-patterns we see in frameworks like Rails.
评论 #5220387 未加载
评论 #5220978 未加载
评论 #5220463 未加载
评论 #5222437 未加载
评论 #5220545 未加载