SQLインジェクション：『1=1』の呪文

たった1行の呪文で、鉄壁のはずのシステムが内側からガラガラと崩れ落ちる。そんな恐ろしくて、でもすごく古典的な攻撃があるんです。 今日は、その全てを破壊する魔法、SQLインジェクションの正体に迫っていきましょう。さてこの話、ある若いエンジニアのアキラくんから始まるんですね。 彼はこう言ったんです。「SQLなんてちょろいですよ、文字列をくっつけるだけでしょ」ってね。まあ彼、自分が作ったログイン機能にそれもう満足げだったわけです。 でもね、この、なんていうか、単純さが、後に、とんでもない悲劇を呼ぶことになるなんて、彼はまだ知る由もなかったんです。 そこに先輩エンジニアのヨミさんが、こうぴしゃりと釘を刺すんです。「君はさ、城の門番に自分の命令を書き換えられるメガホンを渡しちゃったんだよ」って。 うわあ、なんか不吉な例えですよね。これ一体どういう意味なんでしょうか。さあ、この話の核心に、一緒に飛び込んでいきましょう。 はい、というわけでセクション1：欠陥のある要塞です。まず、アキラくんがまあ、本人も気づかないうちに 一体どんなやばいものを作り上げてしまったのか。その構造から見ていきましょう。そもそもSQLインジェクションって何って話なんですけど。 これはですね、アプリの例えばログイン画面の入力欄とかありますよね。ああいうところに悪意のあるSQL文、つまりデータベースへの命令文を注入して 無理やり実行させちゃうっていうサイバー攻撃なんです。本来はただのデータが入るはずの箱に、とんでもない命令が忍び込んじゃう。そんなイメージですね。 じゃあアキラくんのコードの何がそんなに問題だったのか。もう根本的な欠陥はたった一つ。 ユーザーが入力したIDとかパスワードを、何の疑いもなくそのままSQLの命令文にガッチャンコしちゃったことなんですよ。 これってユーザーから送られてきたものを、信頼できる命令の一部として扱っちゃうってことですからね。もうこれ以上ないってくらい危険なやり方なんです。 さあセクション2：1=1の魔法です。いやあ、この単純すぎる数式がですね、どうやって鉄壁のセキュリティを いとも簡単に打ち破ってしまうのか。そのからくりをじっくり見ていきましょう。ここで、先輩のヨミさんがアキラくんに言うんですね。 「じゃあ、このパスワード欄に普通のパスワードじゃなくて、このわけのわからない文字列を入れてみて」と。それがこれ、@ OR 1=1。 ね、意味不明でしょ？でも、この奇妙な文字列こそがあらゆる扉をこじ開ける、まさに魔法の呪文だったんです。 じゃあ、この悪意のある文字列を入れると裏側で何が起こるのか。アキラくんのコードはさっき言ったみたいに入力されたものをそのままくっつけちゃうんで 出来上がった命令文がこうなっちゃうんです。本来のパスワードチェックの後に、OR 1=1っていう全く新しい条件が勝手に追加されちゃってるんですね。 で、ここが肝なんですけど。数学で考えたら1=1ってこれ当たり前ですけど絶対に正しい、つまり真ですよね。 だから、元のIDとかパスワードが合っていようが間違っていようが、この追加されたOR 1=1のおかげで条件式全体が強制的に真、つまりOKってことになっちゃうんです。 結果どうなるか。はい、認証あっさり突破です。「ようこそ」ってね。はい、セクション3：究極の大惨事。いや、ちょっと待ってと。 不正にログインされるだけでも大問題だけど、話はね、それで終わりじゃないんですよ。この脆弱性がどれだけやばい、 もう壊滅的な被害に繋がる可能性があるのか。ちょっと見ていきましょう。不正にアクセスされるのが最悪のシナリオだと思います？ いやいやとんでもない。それはね、まだほんの入り口にすぎないんです。この穴は会社一つを丸ごと終わらせちゃうくらいのパワーを秘めてるんですよ。 例えばですよ、さっきの1=1の呪文じゃなくて、代わりにこのたった一個の命令が注入されちゃったらどうなると思います？ セミコロン、ドロップ・テーブル・ユーザー、スラッシュ。これ、ユーザーっていうテーブル、つまり顧客情報のデータベースをもう跡形もなく完全に削除しなさいっていう 超強力な命令なんです。一瞬で大事なデータが全部消し飛ぶんですよ。この攻撃が引き起こす結果はもう目も当てられないくらい悲惨です。 全ユーザーの個人情報がダダ漏れになったり、データが勝手に書き換えられたり。最悪の場合、データベースが丸ごと消え去ったり。 これってお金の問題だけじゃなくて、会社の信用も全部失うってことですからね。文字通り、会社が終わるレベルのダメージです。 さあセクション4：コードの解毒剤。ここまでこの攻撃の恐ろしさを見てきましたけど、もちろん、ちゃんと対策はあるんです。 ここからはこの恐ろしい呪いを解くための、すごくシンプルで、でもめちゃくちゃ強力な方法を見ていきましょう。 ここでまた先輩のヨミさんがいいこと言うんですね。「解決策は消毒液みたいなもんだ」と。つまり、ユーザーからの入力を危険かもしれない命令としてじゃなく、 単なる無害な値として扱う。この考え方がセキュリティを守る上でのもう大原則になるんです。じゃあ、その具体的な消毒液って何なのか。 それがこの「プレースホルダ」っていうやり方なんです。すごく簡単で、まずステップ1。SQL文を書く時に、ユーザーの入力が入りそうな部分を、 とりあえずクエスチョンみたいな記号で置いておくんですね。で、ステップ2。実際のユーザー入力は、また別の形で後から渡してあげる。 そうすると最後のステップ3で、データベース側が賢く安全に、これをただの値として扱ってくれるんです。 こうすれば入力されたものが命令として暴走することは絶対にあり得ないわけです。さて、いよいよ最後のセクションです。鉄のルール。 今日見てきた中でこれだけは絶対に覚えて帰ってほしいっていう、一番大事な教訓をバシッとまとめておきましょう。 はい、この表が今日のまとめの全てです。まず呪文はOR 1=1。これで条件を無理やり真にしちゃうんでしたよね。 そしてその先にある恐怖は、データの漏えい、改ざん、そして削除。で、一番大事な鉄則、それは何かと言うと、もう一度言いますね。 SQL文を文字列の足し算で作るのは絶対にだめ。必ずプレースホルダを使って、ユーザーからの入力を無害化する。これだけです。 最後に、皆さんに一つ問いかけをさせてください。もし自分たちが書くコードが一つのお城だとしたら、普段何気なくやってるコピー・アンド・ペーストで 一体いくつの裏口を自分でも気付かないうちに明けっ放しにしちゃってるんでしょうかね。今日のこの話が、皆さんが築くそのお城の壁を 少しでも頑丈にするきっかけになったら嬉しいです。