GitHub遭遇Mass Assignment漏洞攻击

     <div id="news_body">     <p> 作者 <a href="/misc/goto?guid=4958331654026389041">Jonathan Allen</a> 译者 <a href="/misc/goto?guid=4958331654885407681">曹如进</a></p>     <p> <a href="/misc/goto?guid=4958333723057548069">GitHub 最近遭遇</a>了一场 Ruby on Rails 漏洞攻击，该漏洞被称为 mass assignment。此漏洞被认为不仅影响了大量基于 Ruby 的网站，还对使用 <a href="/misc/goto?guid=4958333723851865543">ASP.NET MVC</a> 和其他 ORM Web 框架的网站造成了破坏。</p>     <p> Mass assignment 用于将表单数据映射为对象，它在单独使用时是一项安全且高效的技术。这与 ASP.NET 中的数据绑定异曲同工，并且后者在单独使用时也同样很安全。其实，真正的漏洞是由于粗心大意地混用了 mass assignment 和 ORM。</p>     <p> 考虑这样的场景：数据库包含一张“用户”表，其中混杂了敏感和非敏感数据，例如可能有些列代表用户显示姓名、电子邮件地址以及是否为管理员。开发人员希望创建一个页面修改显示姓名及电子邮件地址。为了达到这个目的，他们使用 Rails 或 MVC 脚手架自动生成了域对象，或许还有 view 本身。接下去，他们将用户无法编辑的字段，如“是否为管理员”复选框从 view 中移除。</p>     <p> 如果开发人员忘记将 IsAdministrator 属性从域对象中移除，那么一个安全漏洞便就此产生。如果他们没有进行移除，那么 mass assignment 或数据绑定器可能会陷入某种圈套，它们会在合法改动中更新不该修改的属性。接下去，当记录保存时，ORM 库会悄无声息地存储新值。</p>     <p> 有三种靠谱的方案可以解决该问题：</p>     <ul>      <li>标记不可被更新的属性，让 mass assignment/数据绑定器将其忽略；</li>      <li>彻底清除业务对象中实际不需要的属性；</li>      <li>创建模型专门接受更新请求，并手工将它们映射到 ORM 对象或存储过程调用。</li>     </ul>     <p> 应当指出，这并不是一个新的漏洞。我们可以很容易地找出4、5年前<a href="/misc/goto?guid=4958333724664693155">关于 mass assignment 的警告</a>，例如标题为“<a href="/misc/goto?guid=4958333725461130259">Mass Assignment，黑客们的最爱</a>”以及“<a href="/misc/goto?guid=4958333726251827291">不想被黑就使用 attr_protected</a>”的文章。这次唯一不同的是受害站点知名度较高。</p>     <p> <strong>查看英文原文：</strong><a href="/misc/goto?guid=4958333727053131272">http://www.infoq.com/news/2012/03/GitHub-Compromised</a></p>    </div>