PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収

45分で分かる 安全なWebアプリケーション開発のための 発注・要件・検収 2009年9月4日 HASHコンサルティング株式会社 徳丸 浩

本日お話しするテーマ • セキュア開発をベンダーに促すにはどうすればよいか • セキュア開発においてコストを低減するには • セキュア開発の要件定義はどう考えればよいか • セキュア開発で大切な3つのこと – セキュリティ要件とセキュリティバグ – 開発標準と教育 – セキュリティテスト • セキュリティテストツールとしての「ウェブ健康診断仕様」 Copyright (C) 2009 HASH Consulting Corp. 2

徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • その他 – 1990年にPascalコンパイラをCabezonを開発、オープンソースで公開 「大学時代のPascal演習がCabezonでした」という方にお目にかかることも • 現在 – HASHコンサルティング株式会社 代表 – 京セラコミュニケーションシステム株式会社 技術顧問 http://www.hash-c.co.jp/ http://www.kccs.co.jp/security/ – 独立行政法人情報処理推進機構 非常勤研究員 http://www.ipa.go.jp/security/ Copyright (C) 2009 HASH Consulting Corp. 3

• http://www.hash-c.co.jp/
• http://www.kccs.co.jp/security/
• http://www.ipa.go.jp/security/

責任と契約について • Webアプリの脆弱性の責任は発注者か開発者か – 発注者に責任というのが主流のよう – ただし、判例があるわけではないので要注意 • 経産省の「モデル契約書」では、以下のような記述がある なお、本件ソフトウェアに関するセキュリティ対策については、具体的な機能、遵守方 法、管理体制及び費用負担等を別途書面により定めることとしている（第50 条参照）。 セキュリティ要件をシステム仕様としている場合には、「システム仕様書との不一致」に 該当し、本条の「瑕疵」に含まれる。 （セキュリティ） 第50 条 乙が納入する本件ソフトウェアのセキュリティ対策について、甲及び乙は、その 具体的な機能、遵守方法、管理体制及び費用負担等を協議の上、別途書面により定め るものとする。 • 発注者は自衛のために要求仕様にセキュリティ用件を盛り込んでおく べき – 「発注者のための・・・ 」 – 「ウェブ健康診断仕様」によるテストに合格すること、と記述する手もありか Copyright (C) 2009 HASH Consulting Corp. 4

RFI/RFPの書き方アプローチ • パターン１:提案を求める – 要求も提案も曖昧になりがち • 要求の例：セキュリティに留意して開発すること • 提案の例：セキュリティには万全の体制で臨みます • パターン２：詳細な仕様を出す – 「安全なWebサイトの作り方」に準拠せよ – 「発注者のためのWebシステム／Webアプリケーション セキュリティ 要件書」に準拠せよ • パターン３：検査仕様を提示する – 第三者に検査させる – 発注者が自ら検査する（後述） Copyright (C) 2009 HASH Consulting Corp. 5

RFI/RFPの書き方 • 漠然としたものは効果が薄い • 脆弱性の名前を列挙する方法 – XSS、SQLインジェクション【略】の対策を施すこと – 対策の「質」を問うことは難しい • 実装方式を指定する方法 – 例：SQLアクセスの際はPrepared Statementを使用すること – 既存ソフトの流用やフレームワークの使用に制限が生じると、コスト増の要因にな り得る • 検収の方法を指定する – 例：弊社の指定する脆弱性検査会社の試験に合格すること – コストは高くなる – 検査会社の検査内容がグレーなので、開発会社にとってはリスク – 「ウェブ健康診断仕様」の応用【後述】 Copyright (C) 2009 HASH Consulting Corp. 6

提案する方法 • 基本はベンダーに提案してもらう – 開発言語、ミドルウェア、フレームワークを考慮したセキュアな開発 体制を提案してもらう – セキュリティ的な機能の提案 – 脆弱性を作り込まない体制の提示を求める – セキュリティ検査にパスできる根拠を説明してもらう • 納品物としてセキュリティ検査結果を添付してもらう – 今後、納品検査としてのセキュリティ検査は必須とすべき • 検収時の検査として自らもセキュリティ検査を実施する – 「Web健康診断仕様」による検査を自ら実施する（一種の抜き取り 検査） – 予算に余裕があれば、第三者に検査してもらう Copyright (C) 2009 HASH Consulting Corp. 7

従来言われてきたセキュリティ仕様策定プロセス 経済産業省「モデル契約書」別紙3より引用 http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05

• http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05

資産洗いだし・リスク分析・対策の例 経済産業省「モデル契約書」別紙3より引用 http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05

• http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05

情報資産洗いだしの例 完全性と可用性はだ いたい「中」くらいに なる 機密性の高低くらい を洗い出せば十分 「情報システムの構築等におけるセキュリティ要件及びセキュリティ機能の検討に関する解説書」より引用

脅威分析の例 脅威分析は、どのサイトでも同じ ような結果になる 開発プロジェクトごとに脅威分析 をやってもあまり意味はない 「情報システムの構築等におけるセキュリティ要件及びセキュリティ機能の検討に関する解説書」より引用

脅威に対する技術的対策の例 技術的対策も、毎回同じようなものが「候 補」にあがる 脅威分析の結果というより、情報資産の 価値と機密性に応じて、対策を選ぶよう な形になりがち 脅威分析の結果によって技術的対策が 左右されることはあまりない･･･と思う 「情報システムの構築等におけるセキュリティ要件及びセキュリティ機能の検討に関する解説書」より引用

リスク分析は手間の割に効果が少ない ⚫ 一般的なWebアプリの場合、わかりきっていることをなぞる 結果になりやすい ⚫ 重要な情報はなにか? − ⚫ 情報の格納場所はどこか − ⚫ ⚫ データベースに決まっている 情報資産に対する対策方法は? − ⚫ 個人情報、企業情報など ベストプラクティスが分かっている 重要なのは、なにが重要情報か(What)ではなく、それをどう (How)扱うか わかりきった資産洗いだしをするよりも、「対策を選ぶ」ような アプローチの方が効果的 Copyright (C) 2009 HASH Consulting Corp. 13

リバース・ リスク・アセスメントの勧め ベストプラクティスのセキュリティ対策から選択しあるいはリスクを許容する 対策 採用 ○ 不採用時のリスク - 代替コントロール - ファイアウオ ール WAF ○ - - IDS/IPS × 攻撃予兆の見逃し、脆 弱性対策の漏れに対す る攻撃 WAFによる防御、 WAF等のログ監視強化、 脆弱性対策強化 認証方式 パスワード認証 パスワード管理の不備 を突いた攻撃を受ける パスワード管理の徹底 回線の選択 SSL - - データベース の暗号化 △（パスワードの ハッシュ化のみ） ストレージ持ちだしによ る情報漏洩 入退室管理強化による持ち出し 対策 監査証跡 認証、エラー、操 作ログ - - ウィルス対策 ソフト × マルウェアの感染 速やかなパッチ適用、 本番環境と運用環境間のFW Copyright (C) 2009 HASH Consulting Corp. 14

脆弱性対策と開発プロセス ⚫ ⚫ ⚫ ⚫ ⚫ SQLインジェクションやクロスサイトスクリプティング(XSS)な どが「ないこと」という要求は、仕様として盛り込みにくい リスク分析の結果で脆弱性対策をするものではない。 脆弱性対策は常にすべき。 これらはセキュリティバグであり、バグがないことはわざわざ 仕様に明記するものではない 脆弱性対策は、開発標準に盛り込むのがよい ⚫ だから、ベンダーの開発標準が重要 ⚫ 開発標準の閲覧を要求するのも一法 ただし、契約上の問題は別 ⚫ ベンダーの責任範囲は、発注仕様に書いてある範囲 Copyright (C) 2009 HASH Consulting Corp. 15

提案:3つのポイント ⚫ セキュリティ要件とセキュリティバグ ⚫ 開発標準と教育 ⚫ セキュリティテスト Copyright (C) 2009 HASH Consulting Corp. 16

3分で分かるセキュアプログラミング ポイント① セキュリティ機能（要件）と セキュリティ・バグは分けて考える 基本設計 セキュリティ・バグの撲滅 開発標準の整備とメンバーの教育でチーム力をアップ 認証方法などのセキュリティ要件は ユーザーと相 談して定義し，そのあとに粛々と実装する SQLインジェクションなどのセキュリティ・バグへの 対処法を明確にする 要件定義 ポイント② 詳細設計 方式設計において， 開発標 準やテスト方式を整備して おく 開発 コーディング規約をメンバーに学習 してもらう。 規約を破ると本当に危険だと認識 してもらう テスト 運用 コード・レビューの方針を決める。内部レビュー 脆弱性テストの方針を決める。内部テス を基本とし，誰がどの範囲（抜き取り検査など）を チェックするのかを明確にする。レビューできる担 当者の リソースを確保する トを基本にし，必要に応じて外部の専門ベ ンダーに依頼する。テストできる担当者の リソースを確保する ポイント③ コスト要因となるレビューとテストを計画的に 日経SYSTEMS2009年8月号「プロマネの技で守るWebセキュリティ」図1を改変 セキュリティ・バグの撲滅

セキュリティ要件とはなにか ⚫ ⚫ ⚫ ⚫ リバース・リスク・アセスメントのところで出てきたような「積極 的な」セキュリティ対策 セキュリティ仕様の例 ⚫ パスワード仕様、アカウント・ロック… ⚫ 暗号化（回線、データベース） ⚫ ログ ⚫ ウィルス対策ソフトの導入 ⚫ … セキュティ仕様の実装は、要件定義からウォーターフォール で粛々と実施(通常機能と同じ) 脆弱性対策は開発標準で対応 Copyright (C) 2009 HASH Consulting Corp. 18

開発標準と教育 • SQLインジェクション対策やXSS対策などは、実装設計時に 個別に設計していたのでは効率が悪いし、対応が統一でき ないので、開発標準で定義する • 開発標準は作りっぱなしになることが多く、定着が難しい。教 育を実施して、テストで定着度を確認するとよい • 日経SYSTEMS寄稿時に各社にインタビューした際の印象で は、「やられサイト」を作って開発者向けにデモしている企業 が意外に多く、効果が期待できる Copyright (C) 2009 HASH Consulting Corp. 19

開発標準として利用できるリソース • 安全なウェブサイトの作り方 改訂第3版 – http://www.ipa.go.jp/security/vuln/websecurity.html • 発注者のためのWebシステム／Webアプリケーション セキュリティ要件書 – http://脆弱性診断.jp/specifications/index.html • いずれも基本的な内容だが、これくらいからスタートするほうが賢明 【参考】K社の 開発標準利用状況 引用:http://techtarget.itmedia.co.jp/tt/news/0902/10/news01.html Copyright (C) 2009 HASH Consulting Corp. 20

• http://www.ipa.go.jp/security/vuln/websecurity.html

方式設計のすすめ
• 開発標準の抽象度が高い場合、基本設計フェーズの「方式
設計」として、具体的なコードレベルに落としておくとよい
XSS対策のため特殊文字をエスケープする

Bad

HTML表示の際に「<」、 「>」、 「&」、 「”」は文字参照によりエ
スケープする
HTML表示の際にhtmlspecialchars()関数によりエスケープ
HTML表示の際にライブラリ e()関数を用いる
【実装】
function e($p) {
echo htmlspecialchars($p, ENT_QUOTES, 'UTF-8');
}

Good

• 開発言語、アーキテクチャ、ライブラリ、チームの習慣等を考
慮し、コピペ可能なレベルまで具体化しておく
• 方式設計の際には、テスト方法も検討しておくとよい
Copyright (C) 2009 HASH Consulting Corp.

21

コスト要素はどこか • 「セキュリティ要件」については、機能が増えることになるので、直接コ スト増となる – 発注者と要件詰めをしっかり行う必要がある • セキュリティバグについては以下がコスト要因となる – 開発標準作成、開発者の教育 – セキュリティテスト • 「発注者のための…セキュリティ要件書」でコスト増になるのは・・・ – アカウントロック機能の作りこみ – SSLの証明書代 …たいしたことはない • 開発標準や教育はプロジェクトをまたがって有効なので間接費用と考 えられる。一度しっかりしつものを作れば使い回しがきく • セキュリティテストはプロジェクトごとに必要であり、費用も大きいので、 セキュリティテストのコスト削減が、セキュア開発の課題 Copyright (C) 2009 HASH Consulting Corp. 22

セキュリティテスト ⚫ ⚫ セキュリティ要件にせよ、セキュリティバグにせよ、最終的に はテストで品質を保証することになる 開発工程 ⚫ ⚫ ⚫ テスト工程 ⚫ ⚫ ⚫ ⚫ ソースコードレビュー、ソースコードチェッカー 単体テスト工程での「ウェブ健康診断仕様」利用もあり ツールでのテスト・・・ツールが高価、全項目テストできない ウェブ健康診断仕様の活用 専門家にアウトソース 受け入れテスト（検収） ⚫ ⚫ ウェブ健康診断仕様の活用 専門家にアウトソース Copyright (C) 2009 HASH Consulting Corp. 23

ウェブ健康診断とは 診断方式 ： 遠隔地からインターネット経由による手動若しくは自動診断ツールを利用 診断実施数：約３００団体 診断対象 ： 地方公共団体が保有若しくは利用している、現在インターネットで稼動中のWeb サーバ１サイト分（1 ドメインネーム） http://www.lasdec.nippon-net.ne.jp/cms/12,1284.html より引用

ウェブ健康診断仕様(1) ⚫ 12項目の診断項目により危険度の高い脆弱性項目を網羅 している ⚫ ⚫ ⚫ ⚫ ⚫ 実被害に至る可能性の高いものに限定 「安全なウェブサイトの作りかた 改定第3版」で解説されている 9種類の脆弱性を包含 診断仕様、判定基準、抜き取り基準が明確に定義・公開さ れている 公開された無償ツールのみで診断できる 本番稼働サイトの診断を前提とした安全性の高い診断仕様 である Copyright (C) 2009 HASH Consulting Corp. 25

ウェブ健康診断仕様(2) http://www.lasdec.nippon-net.ne.jp/cms/12,1284.html より引用

ウェブ健康診断仕様(3) http://www.lasdec.nippon-net.ne.jp/cms/12,1284.html より引用

ウェブ健康診断仕様(4) Copyright (C) 2009 HASH Consulting Corp. 28

ウェブ健康診断仕様(5) Copyright (C) 2009 HASH Consulting Corp. 29

検査に必要なツールの例(burp suite) http://www.portswigger.net/suite/ Copyright (C) 2009 HASH Consulting Corp. 30

• http://www.portswigger.net/suite/

burp suiteの設定(Intercept) Copyright (C) 2009 HASH Consulting Corp. 31

burp Suite の設定（ログ取得） Copyright (C) 2009 HASH Consulting Corp. 32

Intercept と検査パターンの入力 Copyright (C) 2009 HASH Consulting Corp. 33

デモ

テスト工程のコスト削減方法 • 専門家に全部頼むと高いので、できる部分は自分でやる • 必ずしも全項目をテストする必要はない • 明らかにテスト不要なもの – 外部コマンドを利用しない・・・OSコマンドインジェクションは不要 – メール送信しない・・・メールヘッダインジェクションは不要 • ソースコード検査の方が効率がよいもの – OSコマンドインジェクション – パストラバーサル – SQLインジェクション(ソースコード検査しやすいように開発標準を定 めておくと良い) • セルフテスト工数を削減して浮いた費用で、専門家にも検査 してもらうとなお可 Copyright (C) 2009 HASH Consulting Corp. 35

まとめ • セキュアな発注方法論は発展途上であり、まだ業界標準とい える方法がない • 要件について – セキュリティ要件とセキュリティバグに分けて考える – 資産洗い出し、脅威分析は定石だが、Webアプリの場合、 うんと簡略化してよい • セキュリティバグ対応は、開発標準整備とチームの教育が鍵 • テスト、検収について – おもなコスト要素はセキュリティテスト – セキュリティテストツールとしての「ウェブ健康診断仕様」 • 契約にも注意 Copyright (C) 2009 HASH Consulting Corp. 36

ご清聴ありがとうございました