- Rails SQL injection vulnerability: hold your horses, here are the facts – Phusion Corporate BlogPhusion Corporate Blog
- Let Me Github That For You | Lands of Packets
- CVE - CVE-2012-5664 (under review)
User.find_by_name('foo', :select => 'id, name')
とやると、
select id, name from users where name = 'foo';
ってなるのだが、:selectの部分はエスケープ処理とかしていないので任意のSQLが書けてしまう。とはいうものの、そこは外部の入力を入れるべきではないので、普通そんなことはしない。
User.find_by_name(params[:name])
とかやっていると
http://example.com/foo?name[select]=id,name
で{'select' => 'id,name'}となるのだけども、シンボルではなく文字列キーのハッシュなので大丈夫。
でも、Authlogicでは
User.find_by_persistence_token(the_token)
とやっていて、Railsセッションによる認証メソッドを利用し、セッションストアの設定がデフォルトのクッキーである場合、クッキーからthe_tokenが取得される。
その場合、任意のRubyのオブジェクトが保存できて、シンボルキーのハッシュを設定することもできるので攻撃できちゃう。ただし、SHA-1 HMAC付きなので、鍵がばれないと大丈夫。
でも、$railsapp/config/initializers/secret_token.rbをデフォルトのまま使うと鍵わかっちゃうけどね。Githubとか。
という話みたい
Rails側は既に修正を入れていて、
find_by_xxxの引数の数がxxxの数(xxx_and_yyyとかできるので複数指定可能)以下の場合は:selectとかのオプションを指定できなくするという処理になっている。find_by_xxx('xxxの値', オプション)となるので引数の数がxxxの数より大きくなるため。
まあ、どちらかというとAuthlogicとアプリ側の問題な気はするけど。