JaSST15九州(1)「基調講演:ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
10/9(金)に開催されたソフトウェアテストシンポジウム2015九州(JaSST'15 Kyushu)に参加しました。私が聴講したセッションは下記です。
基調講演:「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
徳丸 浩(HASHコンサルティング)
事例発表・経験発表:「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉(九州ソフトウェアテスト勉強会)
事例発表・経験発表:「テストする人。の思うところ」
福田 里奈((九州ソフトウェアテスト勉強会)
招待講演:「テストエンジニアを育てるためのポイント」
鈴木 三紀夫(リコーITソリューションズ)
企画イベント(JaSST Kyushu実行委員会)
今回は、基調講演:「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」のメモをまとめました。
基調講演:「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」 徳丸 浩 (HASHコンサルティング)
(1)脆弱性とは?
(1-1)悪用可能なバグ。
サーバーの設定不備により、できないはずのことができてしまう。また、できてはいけないことができてしまうこと。
(1-2)脆弱性の例
- バッファオーバーフロー
C言語のメモリ確保関数 - SQLインジェクション
文法ルールを守っていないこと - XSS(クロスサイトスクリプティング) 悪意のあるスクリプトが実行される
(2)進入経路
- 認証突破
簡単なパスワードで入られる - ソフトウェアの脆弱性を悪用
基盤ソフトウェア
自開発のアプリケーション
(3)あらゆるバグは脆弱性に通じる
排他制御の漏れなど。例えば、仙台の某アイドルグループのライブ開催におけるホテル予約殺到で、ダブルブッキングやトリプルブッキングした事件。
(4)脆弱性=バグと捉えるのが一般的
(4-1)脆弱性の責任
発注者に責任がある(徳丸さんの意見)。
(4-2)家具インテリアECサイト
- 東京地裁でSQLインジェクション攻撃と断定。
- SQLインジェクション対策を怠ったのは、重過失。
- 考察
専門家としての責務を重視。
「安全なWebサイトの作り方(https://www.ipa.go.jp/security/vuln/websecurity.html)」に記載している対策は、最低限対策したほうがよい。
(5)デモ
(5-1)SQLインジェクション攻撃@EC立方体
EC立方体の初期状態(インストール直後)で、都道府県の欄に
'OR" "a-a" init 10 #
と入力すると福岡県のはずが北海道が出力される。
UNION SELECT 1, cardname ...
UNION SELECT文でカード情報を取得し、information_schemaでテーブルを取得し、その情報から攻撃。
(5-2)PHP入門書
- 掲示板の削除ボタンのリンクにあるIDに"?id=729-1"を付与すると、728番目の書き込みが消える。
- extractvalue関数で故意にエラーのあるクエリを入れ、わざとエラーメッセージを出して、個人情報を取得。
- sleep関数を利用して時間差で情報を盗む。
(5-3)横浜市のCSRF悪用
- XSS
見えないiframe。
投稿欄にjavascriptを仕込む。
利用者側で注意はできないので、サイト側で対策の必要がある。
(6)脆弱性対策と開発プロセス
- 実装や開発者のテストでも脆弱診断するとよい
- 発注者側:仕様書にSQLインジェクション、XSS対策を書く
- 安全なWebサイトは、抽象的なので具体的に仕様を書くとよい
- RFPに「SQLインジェクションなどの対策」などの範囲があいまいなので、セキュリティ要件は開発標準に盛り込んで明確化する。
- セキュリティテストを内部でこれからのトレンドになりそう。
(7)脆弱性診断
- リモート(ブラックボックス)診断
害の無い攻撃(疑似攻撃) ツールを使った診断もある - ソースコード(ホワイトボックス)診断 ツール(Fortify)
- グレーボックス リモート(ブラックボックス)診断とソースコード(ホワイトボックス)診断を組み合わせる。
(8)Webアプリ脆弱性診断
- 脆弱性診断は、テストの一種。
- テスト環境を準備
DBが壊れてもOKな環境 - 課題
費用高額
安全性(DB破壊など) - ネットの情報を鵜呑みにしない
- 脆弱性検査するときは、1箇所だけSQLインジェクションして、その他は正常データを入れて検査。
- whileのところは、orよりand使う。andはプロが使う。
- 新しい攻撃手法は、それほど出ていない。もし出たら、大騒ぎするレベルである。
(9)質疑応答
Q1
サーバ側の脆弱性診断したいが、jsで弾かれたので脆弱性診断がやりにくいが、どうすればよいか?
A1
Burp Suiteなどのツールを利用するとよい。本ツールは、サーバにパケットを投げる前に色々仕込める。
Q2
セキュリティ検査を社内で実施するのがトレンドだが、第3者的な監査は残るか?
A2
第3者的な監査は残ると思う。
Q3
非属人化が問題だが、どうすればよいか?
A3
- 人はなかなか集まらない。
- ツールの進化に期待する(ただし、緩やかだが...)。
- Webアプリ開発経験者を教育するのが現実的だと思う。
所感
初め、脆弱性のイメージがピンと来なかったですが、脆弱性が「悪用可能なバグ」という話でガッテンしました。また、Industrie4.0が当たり前の時代になり、脆弱性や機能安全の対応を疎かにすると市場不具合が発生したときに、多大な損害を被ることになりますので、開発もテストも予防できることは何か、どのようなアプローチがあるか、情報のアンテナを張り、日頃から議論したり考えていこうと思う。