Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

SQLインジェクション対策の極意はSQL文を組み立てないことにあり

OWASPでビルトイン・セキュリティ 第4回

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2016/01/29 14:00

 特にウェブアプリケーションにおいて、SQLインジェクションはもっとも有名な脆弱性の一つであり、2005年以降は日本のウェブサイトにも活発に攻撃が行われています。OWASP Top 10の2010年版においても、最新版の2013年版においても、ともに1位に位置づけられています。本稿では、OWASPのドキュメントを参照しながら、SQLインジェクションのあるべき対策について説明します。

目次

SQLインジェクションとは何か

 ここでSQLインジェクションについて簡単におさらいしましょう。以下のSQL呼び出しを例として考えます。

SELECT * FROM books WHERE author='$author'

 $authorの箇所には外部から指定された著者名が埋め込まれるとします。ここで、$authorとしてO'Reillyという文字列が指定されたらどうなるでしょうか。実際に埋め込まれたSQL文は以下に示すとおりです。

SELECT * FROM books WHERE author='O'Reilly'

 文字列O'Reillyに含まれるアポストロフィ(シングルクォート)により、author=の後の文字列が終端し、あとに続くReilly' が文字列の外にはみ出しています。上記はSQL文として正しくないためにエラーになります。しかし、そのあとに続くReillyの箇所に、SQL文としてエラーにならないようにつじつまを合わせると、攻撃者が元のSQL文の意味を変えることができます。これがSQLインジェクション攻撃であり、このような攻撃を許す状態をSQLインジェクション脆弱性と呼びます。

SQLインジェクション対策もれで損害賠償の判決も

 SQLインジェクション脆弱性に関して、2014年1月23日に東京地裁で興味深い判決が出ました。ECサイトがSQLインジェクション攻撃を受けてクレジットカード情報が漏洩した事件について、サイト運営者がアプリケーションの開発会社に対して損害賠償を請求して、結果として約2262万円の損害賠償が命じられたというものです。この判決は確定しています。

 判決文を読みますと、サイト発注者はセキュリティ対策について特に仕様として指示はしていなかったもようですが、開発会社側の「専門家としての責務」として、特に要求されていなくてもSQLインジェクション対策をしているべきところ、それを怠っていた過失が認定されています。

 従来は、発注者の多くはこの判決のようにセキュリティ対策については開発会社にお任せということが多く、一方開発会社は、セキュリティの対策をすると開発費用が高騰し、それを見積もりに転嫁できないため、脆弱性対処に消極的になってしまうという状況がありました。

 これについて、私としては脆弱性対処は発注者と開発会社の双方に責任があると考えていますが、前述のような判決が出た以上は、開発会社は「セキュリティについて求められてなくても」SQLインジェクション対策くらいは自衛のためにしておくべきでしょう。

OWASPのドキュメントに見るSQLインジェクション対策

 OWASPはSQLインジェクションをまとめたドキュメントとしてSQL Injection Prevention Cheat Sheetを公開しています。このドキュメントには、SQLインジェクション対策として以下が推奨されています。

  • Defense Option 1: Prepared Statements (with Parameterized Queries)
  • Defense Option 2: Stored Procedures
  • Defense Option 3: Escaping All User Supplied Input

 日本語に訳すと以下のようになります。

  • 選択肢1: プリペアードステートメント(およびパラメータ化クエリ)
  • 選択肢2: ストアドプロシージャ
  • 選択肢3: すべてのユーザからの入力をエスケープ

 このうち、選択肢1のプリペアードステートメントと選択肢3のエスケープについては日本語のドキュメントでもよく見かけるもので、独立行政法人情報処理推進機構(IPA)が発行する「安全なSQLの呼び出し方」などの解説でもこれらは言及されています。

 一方、選択肢2のストアドプロシージャがSQLインジェクション対策として有効という解説は、日本語の資料ではあまり見かけません。そこで本稿では、プリベアードステートメントやエスケープによる対策はこれらのドキュメントに譲り、なぜSQLインジェクション対策としてストアドプロシージャが有効かという理由を解説し、加えてストアドプロシージャを使う上での注意点を説明しましょう。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 徳丸 浩(OWASP Japan)(トクマル ヒロシ)

    1985年京セラ株式会社入社、1995年、京セラコミュニケーションシステム株式会社(KCCS)転籍。携帯電話向けインフラ、プラットフォームの企画・開発を担当。Webアプリケーションのセキュリティ問題に直面し、研究、社内展開、寄稿などを開始する。2004年に、KCCS社内ベンチャーとしてWebアプリケ...

バックナンバー

連載:OWASPでビルトイン・セキュリティ

おすすめ記事

All contents copyright © 2006-2016 Shoeisha Co., Ltd. All rights reserved. ver.1.5