Webセキュリティの小部屋

Twitter のフォローはこちらから Facebook ページはこちら Google+ページはこちら RSSフィードのご登録はこちらから
公開日:2013年12月9日

「安全な SQL の呼び出し方」に期待すること

IPA 独立行政法人 情報処理推進機構:安全なウェブサイトの作り方

最近、IPA が発行している「安全な SQL の呼び出し方」で、プチ炎上が起きたみたいなので、「安全な SQL の呼び出し方」に期待していることを書いておきたいと思います。

なお、IPA の「安全な SQL の呼び出し方」は、安全な Web アプリケーションを構築するための「安全なウェブサイトの作り方」の別冊になります。

まず、この「安全な SQL の呼び出し方」が対象としているのは「SQL インジェクション」という脆弱性であり、この脆弱性にどのように対処していけばよいのかを、技術的な観点から詳細に解説しています。

SQL インジェクションの脆弱性に対する根本的な対策は「データベースのバインド機構」を利用することです(「安全なウェブサイトの作り方」より)。バインド機構は、プレースホルダやプリペアドステートメントと呼ばれることもあります。

「安全な SQL の呼び出し方」では、もう少し踏み込んで、サーバーサイドでプレースホルダの処理を行う「静的プレースホルダ」と、クライアントサイドのドライバーやライブラリでプレースホルダの処理を行う「動的プレースホルダ」について言及されています。

「静的プレースホルダ」を利用している場合は、仕組み的に SQL インジェクションの脆弱性は発生しないのですが、「動的プレースホルダ」では、条件により SQL インジェクションの脆弱性が発生してしまうことがあります。

そのため、「静的プレースホルダ」を利用できる場合は、「静的プレースホルダ」を使用することが推奨されます。

プチ炎上で問題にされていたのが、「プレースホルダ」を利用することが SQL インジェクションの対策として認識されていくのはおかしい、というものだったようです。炎上元の主張は、あくまで入力値の制御でエスケープ処理を正しく行うという考えのようです。

ですが、Web アプリケーション開発のガイドラインとして欲しいものは、こうすれば SQL インジェクションが発生しないという「明確な指針」であり、環境や設定によりエスケープする文字が変わってしまうような「あやふやな方針」では困ってしまう訳です。

また、脆弱性発生時の責任を、プログラマのスキルに帰結させるのもよくないです。Web アプリケーションの脆弱性はあくまで組織、もしくはプロジェクトとして対策を行うべきものであり、そのために「明確な指針」が必要なのです。

そして、「明確な指針」に併せて、専門家の検証による「安全性の裏付け」も欲しいところです。どこの現場でも、この方法だったら安全だと言い切れる技術者の確保は難しいですからね。

まとめると、「安全な SQL の呼び出し方」に期待することは、「明確な方針」と「安全性の裏付け」なのです。「安全な SQL の呼び出し方」は、この期待に応えています。

ということで、「安全な SQL の呼び出し方」はちゃんと読みましょう。

細かい要求としては、言語と DB の組み合わせが、Perl + MySQL と PHP + PostgreSQL だったのに違和感がありますね。事例としては、PHP + MySQL と Perl + PostgreSQL の方が多い気がするので、こちらの方がよろしいかと。

あと、.NET では、LINQ の言及も欲しいところです。このサイトでも、以下の記事で LINQ による SQL インジェクションの対策方法を載せています。用途は参照のみですが、LINQ を使用すれば SQL インジェクションは発生しないので、是非次の版ではちょろっと記載して欲しいですね。

まあ、細かい部分はともかく、セキュリティに関する技術情報が無償で公開されているというのは大いに意義があることなので、IPA にはこれからもがんばって欲しいです。


スポンサーリンク




カテゴリー:ブログ

Twitter でも、いろんな情報を発信しています。



コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA