最近 Rails 爆菊有点频繁嘛...

还好我只是用 Ruby 而已...

频繁好啊，说明使用的人越来越多，作为技术选择的越来越多，对我们来说是好事，哪种语言没有漏洞呢？

漏洞和语言无关！就像程序员和语言无关一样！

Due to the way Active Record interprets parameters in combination with the way that JSON parameters are parsed, it is possible for an attacker to issue unexpected database queries with "IS NULL" or empty where clauses.  This issue does *not* let an attacker insert arbitrary values into an SQL query, however they can cause the query to check for NULL or eliminate a WHERE clause when most users wouldn't expect it. 

For example, a system has password reset with token functionality: 

    unless params[:token].nil? 
      user = User.find_by_token(params[:token]) 
      user.reset_password! 
    end 

An attacker can craft a request such that `params[:token]` will return `[nil]`.  The `[nil]` value will bypass the test for nil, but will still add an "IN ('xyz', NULL)" clause to the SQL query. 

Similarly, an attacker can craft a request such that `params[:token]` will return an empty hash.  An empty hash will eliminate the WHERE clause of the query, but can bypass the `nil?` check. 

Note that this impacts not only dynamic finders (`find_by_*`) but also relations (`User.where(:name => params[:name])`). 

有什么影响么...User.where([]) 这样会有影响，但其实后面还有分页…… 有人提出不同观点 https://github.com/rails/rails/issues/8831

标题党

可以用这些漏洞去部分不升级的网站做好事

#4 楼 @keating 如果有 User.where(:xxx => params[:xxx]).update_attributes(:a => b) 就完了

#7 楼 @kenshin54 几乎不会这样吧……

#6 楼 @leekelby 感觉场景有限 比如查找一个用户

u = User.find_by_name([nil])
u.delete

只有在 name 确实有 null 值才会返回一个用户

可以看着自己写的项目的代码，分析那些场景可能被利用上

好像问题比较严重，才升了 10 没几天，又升 11 了。。。