ソースコード検査に耐えるコードとは？

～Webアプリ編 2016年度版～
エ レ クト ロ ニ ッ ク ・サービ ス・イ ニシアチ ブ
http://www.es-i.jp/

コンテンツ• セキュリティとは？
• セキュリティ標準とベストプラクティス• セキュアなコードとは？

(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

2

セキュリティとは？
基 本 的 な 要 素を 簡単に 解 説し ます(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

3

セキュリティ対策 ＝ セキュリティマネジメント
ISO27000の「リスク対応」（Risk Treatment）の定義• リスクを変化させる為のプロセス• リスクを発生させる活動を開始しない、または継続しないことを決断することによりリスクを回避する• 機会を獲得する為にリスクを選択または増加させるリスク（脆弱性）の排除• リスクの原因を排除するや削減はセキュリティ対• 発生の頻度を変える策の一部でしかない• 結果を変える• 他の組織（契約企業やリスクの資金的処理を含む 訳注：保険など）とリスクを共有し• 見聞のある選択によりリスクを抑える• 否定的な結果をもたらす事象のリスク対応は、”リスク緩和策”、”リスク排除策”、”リスク防止策”、”リスク削減策”などと呼ばれる事がある

 国際ITセキュリティ標準ISO 27000の定義(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

4リスク緩和策はセキュリティ対策• 否定的な結果をもたらす事象のリスク対応は、• ”リスク緩和策”• ”リスク排除策”

POINT！ 緩和策をセキュリティではないと勘違いしない• ”リスク防止策”• ”リスク削減策”

POINT！ 排除策、防止策、削減策はセキュリティ対策の一部• などと呼ばれる事がある
 国際ITセキュリティ標準ISO27000の定義(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

5

セキュリティ定義とセキュアコード例）ログの取得は重要
なセキュリティ対策！

• セキュリティ対策とは脆弱性を除去する
ものだけがセキュリ
ティ対策ではない

セキュリティ
対策• 安全性を変化させる
施策すべて• セキュリティ対策

セキュリティ対策• ソフトウェアは非常に複雑• バグの完全排除は困難

防御的コード• コードの安全性をマネジメントしやすいコード• 安全性の高いコード

安全性指向コード≠ 脆弱性除去

 防御的プログラミングは「プログラミング原則」のひとつ(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

6

セキュリティの基本概念
境界防御が基本かつ最も重要• 境界防御• 信頼境界線で防御

OS各レイヤー内でも小さな範囲で境界防御を実施• 縦深防御（多層防御）

ライブラリ• 信頼境界線内で防御

アプリケー
ション
ネットワー
ク

 アプリケーション内の縦深防御（多層防御）が重要(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

7

セキュリティの6要素＝ セキュアなアプリケーションの要素• Confidentiality（機密性）機密性• Integrity（完全性）• Availability（可用性）

追跡性• Reliability（信頼性）

セキュリティ

• Authenticity（真正性）• Non-Repudiation（否認防止）
Accountability（追跡性）

完全性

真正性

可用性
信頼性

 国際ITセキュリティ標準ISO 27000の定義(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

8セキュアな開発はPDCAサイクルに対応

DO

• 要件

• システム構築• 仕様• 品質検査• 安全性検査• この中もPDCA

PLAN

ACTION• 問題点確認• 改善への行動

CHECK✓ PDCAマネジメントは国際標準ISO規格の根幹(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

9

セキュリティ標準とベストプラクティス
開 発 者 が実 践 すべき 標準 と プラクテ ィ ス(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

10

セキュリティ標準規格• ISO27000• 国際標準のITセキュリティ標準規格• JISとしても定義• IT開発者必修• http://www.iso.org/iso/home.html• PCI DSS
• カード会社が中心となって策定した規格• クレジットカードなどの取り扱いに必須• https://ja.pcisecuritystandards.org/minisite/en/(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

11

Web開発者必修ベストプラクティス• CERT Top 10 Secure Coding Practices• 米カーネギーメロン大学のCERTが公開しているセキュアコーディング標準トップ10• CERTは1988年に設置され、ソフトウェアセキュリティの草分け的な組織として現在に至る• https://www.securecoding.cert.org/confluence/display/seccode/Top+1
0+Secure+Coding+Practices• OWASP Secure Coding Practices – Quick Reference Guide• OWASP（Open Web Application Security Project）：PCS DSS標準でも言及されているセキュリティ推進団体• 多数公開されているガイドの対策をまとめた文書。チェックリスト形式でセキュアコーディングの実施状態を確認できる。
• https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices__Quick_Reference_Guide(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

12

CERT Top 10 Secure Coding Practices• 1. 入力をバリデーションする• 6. 最小権限の原則を支持する• 2. コンパイラの警告に用心する• 7. 他のシステムに送信するデー
タを無害化する• 3. セキュリティポリシーの為に構成／設計する• 4. 簡易にする• 5. デフォルトで拒否する• 8. 縦深防御を実践する• 9. 効果的な品質保証テクニック
を利用する• 10. セキュアコーディング標準を採用する

http://blog.ohgaki.net/cert-top-10-secure-coding-standard(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

13

OWASP Secure Coding Practices– Quick Reference Guide• 入力バリデーション• データ保護• 出力エンコーディング• 通信セキュリティ• 認証とパスワード管理• システム設定• セッション管理• データベース管理• アクセス制御• ファイル管理• 暗号の取り扱い• メモリ管理• エラー処理とログ• 一般的コーディング実践

http://blog.ohgaki.net/owasp-secure-coding-practices-quick-reference-guide(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

14

Web開発者必修ガイドライン• CWE/SANS TOP 25• 最も危険なアプリケーション脆弱性トップ25とその対策• CWE（Common Weakness Enumeration）：米国MITRE社の脆弱性カタログ• SANS：セキュリティ研究・教育を行う米の組織• https://www.sans.org/top25-software-errors/• OWASP TOP 10• Webアプリケーションに特化した最も危険な脆弱性トップ10• https://www.owasp.org/index.php/Main_Page(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

15

開発者必修プログラミング原則• Defensive Programming（防御的プログラミング）• Secure Programmingとも呼ばれる• バグを最小限に留めるためのプログラミングプラクティス• Intelligent source code reuse• Legacy problems
安全な入出力の管理• Secure input and output handling
これを行うだけでもWebアプ• Canonicalization
リのセキュリティ問題の大多• Low tolerance against "potential" bugs数を解決可能• All data is tainted until proven otherwise• All code is insecure until proven otherwise• Design by contract• Assertions
 安全な入出力管理以外の原則は入出力管理に関連• Prefer exceptions to return codes またはそれらの緩和策と機能する• その他(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

16

開発者必修CWE/SANS TOP25の「怪物的セキュリティ対策」• CWE/SANS TOP25では個別の脆弱性対策以外に一般的対策として「怪物的セキュリティ対策」（Monster Mitigations）を定義• 怪物的セキュリティ対策の第一位と第二位
一位：確実な入力の管理• 入力バリデーションをシステム全体で行う
二位：確実な出力の管理

安全な入出力の管理
これを行うだけでもWebアプ
リのセキュリティ問題の大多数を解決可能• 安全な出力をデフォルトで利用• エスケープ、安全なAPI、バリデーション プログラミング原則 – 防御的プログラミング ISO27000 – 同様の要求(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

17

セキュアなコードとは？
ア プ リ ケーション 開 発 者が知るべき セキュア なコード の特 徴(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

18

ソフトウェアは非常に複雑• 簡単なコードでも背後で動作している多数の関数

IISのコールグラフ• しかもこれらは頻繁に更新• 機能追加・リファクタリング・バグフィック
ス• アプリ自身は更新しなくても、ライブラリやプラットフォームのバージョンが更新• 攻撃者はたった一つの弱点を見つければ勝ち 防御的プログラミングが有効(c) Electronic Service Initiative, Ltd. All rights reserved

https://twittech.wordpress.com/2013/05/06/building-kernel-modules-with-autotools/2016/6/18

19

防御的プログラミングの概念とツール－ セキュアプログラミング• 防御的プログラミングの要素• セキュリティ標準・ガイドラインをツールとして利用• Intelligent source code reuse• ISO27000• Legacy problems• CWE/SAN TOP 25• Secure input and output handling• CERT Secure Coding• Canonicalization• OWASP TOP 25• Low tolerance against "potential" bugs

• OWASP Guide• All data is tainted until proven otherwise• OWASP Chart Sheet• All code is insecure until proven otherwise• Design by contract• Assertions• Prefer exceptions to return codes• その他

 信頼できる、と保障できない物（入出力データ、ライブラリ、コード）は信頼しない(c) Electronic Service Initiative, Ltd. All rights reserved• マニュアル・リファレンス• プロトコルの仕様• 外部システムの入出力仕様

安全な入力・出力
処理には正確な仕様の理解が欠かせない• ライブラリの仕様• 言語・関数の仕様

 防御的プログラミングには仕様の理解が不可欠
2016/6/18

20一般的なプログラムの構造
IISのコールグラフ

Webサーバーの基本動作は単純
リクエストを受信
何らかの処理レスポンスを送信
基本動作は単純でも内部構造は複雑(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

21

防御のポイント 全ての入力をバリデーション
入力処理でバリデーション• 入力処理• バリデーション（ホワイトリストが基本）• ロジック処理• ベストプラクティス• OWASP・CWE・ISO・その他のガイドラ
イン・標準を利用

ロジックにはベストプラクティス
 認証・認可・セッション管理・ログ・エラー処理など• 出力処理• エスケープ、安全なAPI、バリデーション（ホワイトリストが基本）

出力処理を既定として安全性を担保
 デフォルトでエスケープ
 例）HTML出力(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/1822 全ての入力をバリデーション※ ISO27000の要求事項

まずアプリケーション全体を防御 入力処理でバリデーションし無用なリスクを排除• 入力処理• バリデーション（ホワイトリスト優先）• 出力処理• エスケープ、安全なAPI、バリデーション（ホワイトリスト優先）
防御対象アプリケーション境界での保護が第一 境界防御 – セキュリティの基本原則

出力処理の安全性を確実に担保
 デフォルトでエスケープ
 例）HTML出力(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

23

モジュール・関数レベルも同じ• 入力処理• バリデーション（ホワイトリスト優先）入力 全ての入力をバリデーション
 Assertや契約プログラミングが有効• 出力処理• エスケープ、安全なAPI、バリデーション（ホワイトリスト優先）処理

アプリ・モジュール・関数の境界を防御 モジュール・関数レベルで見ると境界防御だが、アプリレベルと見ると縦深防御（多層防御）
 縦深防御もセキュリティの基本原則(c) Electronic Service Initiative, Ltd. All rights reserved

入力処理でバリデーション

出力処理を既定として安全性を担保

出力

 異常な出力を防止（無効な値など）
 Assertや契約プログラミングが有効
2016/6/18

24

セキュアなソフトウェアアーキテクチャ• 基本アーキテクチャ – アプリケーション、モジュール、関数・メソッド、粒度に関わらず共通
入力
アプリケーション各レイヤーの境界防御が防御の基本
 アプリケーションレベルの境界防御が特に重要

モジュール

関数・メソッド

入力処理

入力処理

入力処理

ロジック処理ロジック処理ロジック処理

出力処理

出力処理

出力処理

出力
(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

25

セキュアなコード＝ セキュリティの基本要素を守るコード• 入力・出力制御
機密性
追跡性• セッション管理完全性• 認証・認可• 暗号・ハッシュ

セキュ
リティ
真正性

ベストプラクティスを最大限に利用 フレームワークやライブラリが必ずしもベストプラクティスを実装しているとは限らない点に注意• フェイルセーフ
可用性

信頼性(c) Electronic Service Initiative, Ltd. All rights reserved• 認証ログ、操作ログ、エラーログ• テスト・品質検査• コードレビュー
2016/6/1826

セキュアなコード＝ コードの安全性がひと目で分かる• PHPの例
パラメータが設定されているかのみをチェック？！

NG$id = isset($_GET[‘id’]) ? $_GET[‘id’] : null;$id = validate($_GET[‘id’], ‘int’, 0, PHP_INT_MAX); // invalidはエラーで停止
入力バリデーションはセキュリティ対策であり、入力パラメータは可能な限り厳格にチェック
入力バリデーションエラーはプログラムの実行を停止(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/1827

セキュアなコード＝ コードの安全性がひと目で分かる• PHP+HTMLの例
入力バリデーションで「入力」の安全性は担保そのまま出力して安全？！

NG<div id=“<?php echo $integer_id ?>” > …..</div><div id=“<?php echo hemlspecialchars($integer_id, ENT_QUOTES,‘UTF-8’) ?>” > …..</div>
入力バリデーションは「入力」の「境界防御」
防御的プログラミングでは出力を行う場合にも「出力」の「境界防御」を行う（出力対策は入力対策と独立）(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

28

Webアプリケーションの世界はテキストが基本• 安全なテキスト処理がセキュリティ対策の基本
正確・安全なテ
キスト処理を知り、実践する• 入力・出力の仕様を正確に理解• HTML、CSS、JSON、SQL、LDAP、XML、XPATH、SMTP、HTTP他• OSコマンド、C言語文字列、PHP文字列、JavaScript文字列他• 一文字でも意味がある文字を持つ場合、インジェクション攻撃が可能と仮定• 実際、一文字でも特別な文字があるとインジェクション攻撃に脆弱に• ヌル文字インジェクション、改行インジェクション（SMTP、HTTP）• テキスト処理をする場合、まず特殊文字があるか調べる• 一文字でもある場合、エスケープ方法・関数があるか調べる

安全なコードへの最短距離• エスケープ方法が定義されていても、エスケープAPIが無い場合も多い• 安全なAPIがあれば利用する• 安全と言われるAPIでも制限はある。例）プリペアードクエリは識別子、SQL語句のパラメータ化は対応していない。変数も埋め込める。

• バリデーションは“ホワイトリスト方式”が基本中の基本

 APIさえ使っていれば大丈夫、は遠回りかつ危険• バリデーションエラーになる無効な入力を受け付ける意味は通常ないので拒否する(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

29

セキュリティと速度・コスト• セキュリティ対策の多くはトレードオフ関係
境界防御、縦深防御（多層防御）、
防御的プログラミング

実行速度増加、実装コスト増加(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/1830

防御的プログラミングを行わないコスト• 防御的プログラミングを行わないメリット・デメリット
コード記述量が減る、一見システ
ムが正常（安全）に動作しているように見える（構築期間短縮）、システムの動作が軽快
隠れたバグの増加、セキュリティに影響するバグの増加、構築期間が短く見えてもバグ修正のコストが増大
 スーパープログラマが全てのコードを一人で書けばバグフリーも可能だが、現実の開発ではほぼ不可能(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/1831

CSRF ‐ Cross Site Request Forgery
CSRFは真正性の問題• 真正性はISO27000でセキュリティの要素として定義されている• 利用者、プロセス、システム、情報などが本物であることを確実にするということ。

Webアプリケーションはリクエストの詐称が容易• 罠ページを用意して認証済みのユーザー権限で不正なリクエストを送信• Webアプリケーションでは広くみられるセキュリティ問題

更新系のリクエスト全てにCSRF対策が必要• リクエストにランダムかつ一意なトークンを付与し、サーバーでバリデーション• CSRF対策は入力バリデーションの一種(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

32

セキュア（防御的）プログラミングの学習• セキュリティ標準・ガイドライン• ISO27000• CERT Secure Coding Standard• CWE/SAN TOP 25

どこから手をつけて良いかわからない• OWASP TOP 10• OWASP Secure Coding Practices• OWASP Guide• OWASP Chart Sheet• マニュアル・リファレンス

体系的にセキュア
プログラミングを学びたい• プロトコルの仕様• 外部システムの入出力仕様• ライブラリの仕様• 言語・関数の仕様• メソドロジー

弊社にお問い合わせください• 契約プログラミング（契約による設計）• OpenSAMM(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/1833

まとめ(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/1834

セキュリティ問題の8割、9割は入力と出力のセキュリティ対策で対応可能
入力バリデーションは#1のセキュリティ対策（SANS, MITRE, CERT,OWASP, ISO）

入力

• ホワイトリスト型でバリデーション• 全ての入力値が対象、要素数などもチェック

出力• 入力対策とは独立した対策。出力を徹底的に無害化• エスケープ、エスケープが必要ないAPI、バリデーション処理処理• ベストプラクティスを採用。特に認証、認可、その他セキュリティに関連する処理(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/1835

安全な入力処理の原則

入力バリデーション
エラーと入力ミスは異なるモノである点を理解していない開発者も多い！

バリデーション
• 全ての入力データは厳格にバリデーションする• バリデーションはホワイトリスト方式• 文字データ：文字エンコーディング、利用文字、形式、長さ• 数値データ：整数、浮動小数、最小値、最大値• 集合データ：集合に合致する値 例）都道府県、性別、学年• 入力値：入力パラメータの数、必須入力
 入力バリデーションは最も重要なセキュリティ対策
 バリデーションエラーは処理を停止(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

36

安全な出力処理の三原則
１．エスケープ「セキュアなAPIを利用する」は不完全な対策であることがある点に注意！

• 出力先のエスケープ方式理解し確実にエスケープする• 出力先が用意しているエスケープ関数を利用する• エスケープ関数が無い場合もある

２．API利用• エスケープが必要なくなるAPIが利用可能な場合は利用する• セキュアなAPIが無い場合が多い

３．バリデーション• エスケープもAPIも利用できない場合、バリデーションを行う• バリデーションできない場合、サニタイズを行う 出力処理は入力処理とは“独立”である
 正しい文字エンコーディングであることを保証する(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/1837

セキュリティ問題の8~9割に入力処理と出力処理で対応可能
入力バリデーションをセキュリティ対策でない、と考えている開発者は少なくないので要注意• 入力バリデーションはソフトウェア開発で最も重要なセキュリティ対策• 入力バリデーション無しで喜ぶのは攻撃者とブラックボックステストをするセキュリティ専
門家• 入力バリデーションはISO27000（ISMS）、PCI DSSで要求している事項。入力バリデーションを実施しない場合、仕様書に記載がなくても開発会社は損害賠償責任を問われる可能性がある

入力対策と出力対策が独立した対策であることを理解していない開発者は多いので要注意• 入力時に出力時のコンテクストは不明。したがって、入出力処理は独立した対策• 入力・出力対策（境界防御）はITセキュリティ以外にも通用するセキュリティ対策の基本中の基本

 入力と出力の制御は第一位、第二位のセキュリティ対策
 第一位、第二位のセキュリティ対策無しの対策は有り得ない(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/1838

ベストプラクティスCWE（Common Weakness Enumeration - 共通脆弱性タイプ一覧）にはソフトウェアによく見られる脆弱性とその対策が記載されている• https://www.ipa.go.jp/security/vuln/CWE.html
https://cwe.mitre.org/• CWEが利用する言語はJava、C#が多いが他の言語でも参考になる• CWEに記載されている対策が最善の対策とは限らない• CWEに記載されていない脆弱性もある

フレームワーク• フレームワークはベストプラクティスとなる実装も多い• ベストプラクティスとは言えない実装も多い(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

39

ベストプラクティス
CERT Top 10 Secure Coding Practices• CERTのセキュアコーディング標準準拠より、この一般的コーディング指針が重要• 独自のセキュアコーディング標準の構築が必要

OWASP Secure Coding Practices• チェックリスト形式で現在のセキュリティ対策の状態をチェック可能• 必ずしも全てのベストプラクティスを全てのプロジェクトに適用する必要はない

OpenSAMM• コードのみでなく「仕組み」としてセキュアな開発を実行する組織を作る方法論• 能力成熟度モデルであるため導入し易い• セキュリティは文化であり、段階的にセキュリティ文化を構築可能(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

40

お問い合わせセキュア開発/プログラミング・ソースコード検査のお問い合わせはエレクトロニック・サービス・イニシアチブ
http://www.es-i.jp/
info@es-i.jp(c) Electronic Service Initiative, Ltd. All rights reserved

2016/6/18

41