GitHub遭遇Mass Assignment漏洞攻击

fmms 9年前
     <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>