# Ruby入門＞ Ruby on Rails

Ruby on RailsのSQL文をdevelopment.logで確認

Ruby on Railsのデータベースとモデルクラス・MVCの対応関係に書きましたが、RoRでのDB操作は、DBオブジェクトをレシーバとしてfind系メソッドを通して行う。
実際に発行されるSQL文はどうなっているのだろうか・・・、SQLインジェクション対策は大丈夫だろうか・・・などの心配も多少ありますので、DBに対して発行される生のSQL文を確認したいと考えました。
実は、意外と簡単に生のSQL文を確認できます。

以下のパスのファイルを開きます。

Railsアプリ名/log/development.log

このファイルは、Railsアプリを操作した際のログがすべて記録されているようです。
Railsの場合、基本的にページ遷移が行われるたびに、なんらかのコントローラークラスとメソッドが呼ばれます。
DBに対する操作も、実際に発行された生のSQL文が記録されています。

SQLに対するエスケープがちゃんと行われているかという実験のために、「’」（アポストロフィまたは、シングルクオート）と「”」（ダブルクオート）からなる文字列「' ' ' " " "」をフォームから送信してみたところ・・・

development.logを確認しますと・・・

INSERT INTO `hoges` (`foo`, `bar`, ...) VALUES('\' \' \' \" \" \"', '\' \' \' \" \" \"', ...)

と、アポストロフィ、ダブルクオートとともに、「\」（バックスラッシュ）でエスケープされた文字が、INSERT INTOされているのを確認できました。
もう少し、UPDATEやSELECT、DELETEに関しても、動作を確認する必要がありそうですが、INSERTに関してはちゃんとエスケープされているようです。
まあ、Rails作ったのは、天才プログラマーと名高いDavid Heinemeier Hansson氏ですので、そこらへんのDBに対するセキュリティは大丈夫とは思いますが。

SQLインジェクション攻撃について少し

主にPHPを用いた場合ではありますが、SQLインジェクション攻撃について知ってること。
私の場合、PEARのDBライブラリなしで、PHPでDB操作する場合、SQL発行文には、mysql_real_escape_stringを用いるようにしていました。
それと、ワイルドカードの対策。

SQLクエリをDBに発行する場合は、「’」（アポストロフィ）などを、「\」（バックスラッシュ）でエスケープする必要があります。
でないと、POSTするデータ次第ではクエリがエラーになったり、最悪の場合SQLインジェクション攻撃でDBの中身のデータが壊れてしまいます。

あと、SQLの「WHERE ～ LIKE 」文を使う場合、LIKE演算子にフォーム送信されたデータを与えるのであれば、ワイルドカードもエスケープしなければならない。
mysql_real_escape_stringの問題点は、ワイルドカードをエスケープしない点です。
たとえば、送信されたデータが「%」（すべての文字にマッチするワイルドカード）だった場合・・・
「～ WHERE カラム名 LIKE ‘%’」などのSQL文が構築されてしまい、すべてのテーブルレコードにマッチしてしまいます。
なので、str_replaceなどで、「\%」、「\_」とワイルドカード文字をエスケープします。

PHPもRubyも、DBオブジェクトのライブラリを使ったほうが安全だろうとは思いますが、動作が少し気になりますね。

>> 次の記事 : マイグレーション（rake db:migrate）の確認・Railsカラム生成メソッドとMySQLデータ型の対応表

<< 前の記事 : Ruby on Railsのデータベースとモデルクラス・MVCの対応関係