言葉は知られていても危険性までは認識されていない「SQLインジェクション」(2/2 ページ)

» 2005年06月07日 08時41分 公開
[高橋睦美,ITmedia]
前のページへ 1|2       

 一般への認識が薄いとしても、SQLインジェクションの危険性は大きい。「認証を回避して、パスワードなしでログインが可能になるだけでなく、いろいろと条件やテクニックは必要だが、データベースの中身をすべて取得したり、対象OSの権限を取得したりといったことが可能になる」(笠原氏)。

 もっとも、運営者側が「問題を解消する」と決めたならば、対策はそう困難なことではないという。

 SQLインジェクションとは、不正な入力によって、運営者の意図とは異なるSQL文を実行させられてしまう脆弱性だ。そこで最も基本的な対策は、「SQL文の中のパラメータ値を必ずシングルクォートでくくり、ユーザー入力の中にシングルクォートなどの特殊文字があれば、それをサニタイジング(無害化)すること」(MBSDのシニアコンサルタント、中村隆之氏)という。特に、ユーザー入力のチェックを徹底していれば、ほとんどのWebアプリケーションの脆弱性を回避できるという(関連記事)

 また、万一攻撃を受けた場合の被害を拡大させないために、サーバおよびそこで稼動しているサービスの権限を見直しておくこと、ログをきちんと取得し、監視を実施することなども重要だろう。さらに最近では、Webアプリケーションに渡される文字列のチェックを自動的に行い、ルールに該当しない入力をはじくことで攻撃を防ぐ、Webアプリケーション専用ファイアウォール製品も登場している。

発注側、受注側の姿勢も問われる

 さらに根本的な原因は、Webアプリケーションが安易に作られてしまう「構造」にあるのかもしれない。

 「最近のWebアプリケーションは、いわゆるCやC++などによるアプリケーションとは異なり、比較的簡単に書ける。経験の少ないプログラマが、『とりあえず動くこと』を前提にセキュリティのことを考えずWebアプリケーションを作ってしまうケースが多いのが原因だと思う」(笠原氏)。

 また、MBSDのシニアシステムエンジニア、目崎匠氏は、「以前までは、発注側が受注側に対して『安全に作ってくれ』といった漠然とした指針しか提供せず、できあがってきたWebアプリケーションの安全性はあまり考えられていなかった」とコメント。その背景には「うちは大手のどこそこに頼んでいるから大丈夫だよ」という神話があったのではないかと指摘する。

 しかし、個人情報保護法が全面施行となった今となっては状況が異なる。

 「単に『安全に作ってくれ』というだけでは、開発ベンダーに対する『監督責任』を果たすことができないため、いざ問題が発覚した場合に、責任を追及されるのは発注側であるという流れになる」(目崎氏)。そうした事態を避けるためには、発注側でもセキュリティに関する最低限の知識を身に付け、開発側に明確な開発指針を提示することが重要だという。

 さらに、「現に動いている」Webアプリケーションに手を加えることが歓迎されるかどうか、またそれに必要となる「予算」をどうするかといった事柄も、現場では問題にされるかもしれない。

 目崎氏はさらに、「Webアプリケーションに問題が発覚した場合は改修が必要になる。中には、改修に要した費用を請求するベンダーがある一方で、開発に当たり、セキュリティに関することは当然加味するというベンダーも登場しているようだ。こういったことから、近い将来、セキュリティを意識した開発を行う場合にエクストラチャージを要するベンダーは淘汰されてしまう可能性もある」ともコメントしている。

前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ