TOP
＞
システム開発
＞ セキュリティの脆弱性問題
ながさきITモデルへの参画 〜 地場SIerの官公庁システム開発奮戦記
第４回：ソースコードの公開と脆弱性問題との戦い
著者：
ドゥアイネット 穴井 春奈
2006/5/24
前のページ
1
2
3
次のページ
セキュリティの脆弱性問題
ソースコードが公開されて間もなく、OSVFNを通して当社へある連絡が入った。ソースコードを公開しているシステムに、JPCERT／CC（注1）からセキュリティの脆弱性があるとの指摘を受けたのだ。
注1：
JPCERT／CC（有限責任中間法人 JPCERT コーディネーションセンター）
インターネットを介して発生する侵入やサービス妨害等のコンピュータセキュリティインシデントについて、日本国内のサイトに関する報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討や助言などを、技術的な立場から行っています。特定の政府機関や企業からは独立した中立の組織として、日本における情報セキュリティ対策活動の向上に積極的に取り組んでいます。
（
http://www.jpcert.or.jp/
より抜粋）
アクセス制御欠如の脆弱性
脆弱性指摘事項の内容は次のようなものだった。
悪意ある第三者による不正アクセスがあった場合、データベースに対して操作することが可能となる。システムの入り口でユーザ名・パスワードによるユーザ認証を行っているが、特定のサーバスクリプト（PHP）などを、認証を介さずに呼び出してしまう可能性があるとの指摘を受けた。
つまり、セッション管理によってアクセスを制御するべきだという指摘なのだが、指摘を受けたシステムはすべてながさきITモデルによる分割発注によって数社の企業で構築されているため、対策を行うには分割した部分の連携が必要になりコストがかかってしまうのだ。
このため、セッション管理の対応の代わりとしては県のシステムではセキュリティが担保されている環境を前提とし、まず第三者がユーザ名とパスワードを盗用し他のPCからアクセスした場合を想定してアクセス制御の対策を行った。
図1：長崎県庁のセキュリティ対策
SQLインジェクションの脆弱性
システム側で入力値のチェックが不十分だった場合、リクエストのパラメータにSQL文を与えてデータベースを不正に操作することが可能となる。JPCERT／CCからはPOSTまたはGETされた値に対し、SQLの条件になり得るような記号文字が含まれていないかなどをチェックを行う必要があるとの指摘を受けた。
例えば、ユーザ認証画面においてユーザIDを入力し、「login」ボタンクリックでデータベースへ接続しユーザ認証を行う処理である場合、図2のようにこのIDにデータベースを操作するSQL文をセミコロン（;）付きで入力されると、データベースを簡単に操作することが可能となってしまう場合があるのだ。
図2：SQLインジェクション画面
そこで、SQLインジェクションを防ぐために以下の2つの対策を取った。
1つ目はPOSTまたはGETされた値にSQLの条件になり得るような記号文字が含まれていないかをチェックする対策である。
図3：不正文字のチェック
（画像をクリックすると別ウィンドウに拡大図を表示します）
そして、2番目の対処としてエスケープ処理を行った。
図4：エスケープ処理
（画像をクリックすると別ウィンドウに拡大図を表示します）
前のページ
1
2
3
次のページ
「長崎県スケジューラー紹介」
ドゥアイネットでは、リッチクライアント言語を使ったスケジューラーを開発致しました。直感的な操作性とストレスを感じさせない処理スピードで、事務の効率化とコストダウンを実現しています。デモサイトが公開されていますので、ぜひ一度お試しください。
機能詳細はコチラ（実際に体験できるデモサイトをご用意しています！）
http://www.doinet.co.jp/activity/scheduler/
著者プロフィール
株式会社ドゥアイネット 穴井 春奈
システム技術部2課 チーフ。
前職は一般事務。もっと自分にしかできない仕事をしたいという思いから転職を決め、ドゥアイネットに入社して4年。現在は長崎県電子自治体プロジェクトに携わり、設計から開発までをこなす。
INDEX
第4回：ソースコードの公開と脆弱性問題との戦い
オープンソースとしてソースコードを公開
セキュリティの脆弱性問題
ログインIDによるパスワードのチェック方法
