SQLインジェクション：入力欄からデータベースを操られる

レン

検索機能を作った！入力された文字でデータベースを検索するんだ。

ウィルスン

ほう。その入力された文字を、そのまま検索の命令文に混ぜているのではないか？だとすれば、ワタシは検索語のふりをして「命令」を送り込めるということだ。

レン

検索してるだけなのに、命令できるの…？

プロクラ

できてしまうんだ。データベースへの指示は文字列で組み立てるよね。そこに利用者の入力をそのまま貼り付けると、入力の中身が「データ」なのか「命令」なのか、データベース側で区別がつかなくなる。

何をされるのか

ウィルスン

検索結果に、本来見えないはずの全員分のデータを混ぜて表示させる。ログイン画面なら、パスワードを知らずに認証を通す。場合によってはテーブルごと消すこともできる。入力欄1つで、そこまで届くのだよ。

レン

入力欄ひとつでそこまで！？

プロクラ

しかも、画面に何も表示されない形でも成立する。応答の違いを1つずつ確かめて、中身を少しずつ読み出す手口もあるんだ。「エラーが出ないから大丈夫」は根拠にならないよ。

防ぎ方：命令とデータを分けて渡す

文字列を組み立てて渡す限り、どれだけ丁寧に加工しても、命令として解釈される余地が残ります。分けて渡す仕組みを使えば、データはどこまでいってもデータとして扱われます。加工で頑張るのではなく、そもそも混ざらない経路を選ぶ。これが「正しい対策はひとつしかない」と言われる理由です。

プロクラ

対策はほぼ1つに集約されるよ。文字列を連結して命令文を作るのをやめて、「ここに値が入る」という場所を用意した命令文と、値そのものを別々にデータベースへ渡すんだ。これをパラメータ化クエリ（プレースホルダ）と言う。

プロクラ

こうすると、渡された値は必ず「データ」として扱われる。中に命令のような文字が含まれていても、ただの文字列として検索されるだけなんだ。

プロクラ

ここが根本的な解決である理由は、入力の中身を検査していないところにある。何が来ても構造が壊れないので、想定外の書き方を思いつかれても関係ないんだ。

パラメータで渡せない場所がある

プロクラ

ただし、値の部分は差し込めても、テーブル名や並べ替えの向きのような「構造」の部分は差し込めないんだ。ここに利用者の入力を混ぜたくなったときが、いちばん危ない。

• 並べ替えの列名や向きを、利用者に選ばせる場合
• 検索条件の数によって、命令文を組み立て直す場合
• 対策は、許可する値をあらかじめ一覧にして、その中から選ばせること
• 受け取った文字をそのまま使わない。照合して、こちら側が持つ値に置き換える

やってはいけない対策

危険な文字を探して弾く方式は、必ず抜け道が残ります。表現の仕方が複数ある以上、想定した書き方だけを塞いでも別の書き方で通ります。しかも正常な入力まで弾いてしまい、苦情の原因にもなります。塞ぐ努力の方向を間違えている典型です。

• 危険な文字を自分で除去しようとする（漏れが出る。抜け道が次々見つかっている）
• 入力の長さ制限だけで防いだつもりになる
• 画面側（ブラウザ）の検証だけで済ませる（サーバーへ直接送られたら無意味）

プロクラ

最近のフレームワークやORMを普通に使っていれば、自動的にパラメータ化されることが多いよ。危ないのは、速度や柔軟性のために自分で命令文を組み立てたときだね。そこだけは特に慎重に。

破られたときの被害を小さくする

プロクラ

対策は入口だけじゃない。万一通されたときに、できることを減らしておく備えもある。

• アプリが使うデータベースの利用者に、必要な権限だけを与える
• テーブルを消す権限や、他のデータベースを見る権限は与えない
• データベースを外部から直接接続できない場所に置く
• エラーの詳細を画面に出さない（構造を教えることになる）
• パスワードは元に戻せない形で保存する（読まれても即座には使えない）

ウィルスン

…エラー画面か。あれは親切でな。どのデータベースを使い、どんな命令文を組み立てているかを、丁寧に教えてくれる。ワタシにとっては地図のようなものだ。

レン

値は分けて渡す。構造は一覧から選ばせる。権限も絞っておく。