あなたのWebサイトのセキュリティ、大丈夫？
竹内義晴です。
今日、IPAの情報セキュリティセミナーに行ってきました（ITコーディネータの資格更新のポイント稼ぎもありまして（汗））。
主な内容は、情報セキュリティの標準的な話に加え、SQLインジェクションやクロスサイトスクリプティングなど、具体的なデモを踏まえながら、脆弱性によってどのようなことが起こりうるのかが分かるセミナーでした。
特に、SQLインジェクション攻撃は、JSOCの侵入傾向分析レポート Vol.11によれば、2008年4月ぐらいから急増だそうです。7月、8月の伸びも非常に大きいんですね。SQLインジェクションについては、@ITの今夜分かるSQLインジェクション対策を見てください。
脆弱性をついた攻撃……というと、何か高度な印象がありましたが、SQLインジェクションの脆弱性は非常に身近で、いつ作りこんでしまってもおかしくなさそう。セミナーで私の隣に座っていた方も「大丈夫かなぁ」と不安げでした。
Webアプリケーションに限らず、SQLを使ってデータベースを操作するプログラムを書いたとき、一度ぐらいは今夜分かるSQLインジェクション対策に書かれているような
SQLインジェクションの脆弱性を持ったアプリケーションのよくある例としては次のようなものである。
これは、ユーザー名とパスワードを入力してログインする処理の一部である。uidとpwdの組み合わせが、データベースのものと一致すると認証するという仕組みだとする。
SELECT * FROM user WHERE uid='$uid' AND pwd='$pwd'
ユーザーからの入力は、ユーザー名が$uid、パスワードが$pwdに渡されるものとする。ここで、以下のような入力があった場合の挙動を考えてみよう。
$uid ： ueno
$pwd ： ' OR 'A'='Aこれを入力するとSQLは以下のようになる。
SELECT * FROM user WHERE uid='ueno' AND pwd='' OR 'A'='A'
これが実行されるとORの後は常に真なので、パスワードが異なるにもかかわらず認証されてしまうという現象が起きてしまう。
このような実装をした経験をお持ちの方も多いのではないかと思います。
このような場合、プログラムを修正せずに「シングルクォートやアスタリスクは使用禁止文字として運用でカバー…」なんていう事例を過去に何回か見てきています。多くの人の目に触れるWebシステムなら影響が大きいですよね？
あと、「そりゃそうだな」と納得したのがエラーハンドリング。デバッグのために良かれと思ってエラーメッセージにSQLを出していたら、テーブルの構造がわかってしまいますもんね。当たり前だけれど、言われなきゃ案外気づかないかもしれません。このような事例も過去に見てきました。
私は2年ほどまとまったプログラムを書いていませんが、このような脆弱性に関する最近の動向はぶっちゃけどうなんでしょう？
無料セミナーですが、2008年度版の情報セキュリティ白書もいただけて、わかりやすくお得なセミナーでしたので、ご興味のある方はこちらで調べて参加してみてはいかがでしょうか？
セキュリティに関する情報や実装方法など、IPAの参考サイトがありますので、脆弱性について参考にされてください。