More Related Content Similar to オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019) (20) More from Hiroshi Tokumaru (20) オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)2. アジェンダ
• オニギリペイとは
• オニギリペイの8つの試練
– 試練#1 キャンペーンを実施したら、某筋からお叱りを受ける
– 試練#2 ログインIDを発番したのに不正ログインが多発
– 試練#3 二段階認証を強制したのに不正ログインが止まらない
– 試練#4 ヘルプデスクが狙われる
– 試練#5 スマホアプリの脆弱性を指摘される
– 試練#6 スマホアプリのアップデートを広報したらアプリがリジェ
クトされる
– 試練#7 「あの有名な脆弱性」で大変なことに
– 試練#8 WAFを導入したらかえって脆弱になる
• 安全なインターネットシステムの構築法
2
3. 自己紹介(大事なことなので、本日3回お伝えします。)
3
徳丸浩の自己紹介
• 経歴
– 1985年 京セラ株式会社入社
– 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍
– 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会
社)設立
• 経験したこと
– 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当
– その後、企業向けパッケージソフトの企画・開発・事業化を担当
– 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当
Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始
– 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ
• 現在
– EGセキュアソリューションズ株式会社 代表 https://www.eg-secure.co.jp/
– 株式会社グレスアベイル 社外取締役 ←NEW! https://www.gresavail.com/
– 独立行政法人情報処理推進機構 非常勤研究員 h ttps://www.ipa.go.jp/security/
– 著書「体系的に学ぶ 安全なWebアプリケーションの作り方」(2011年3月)
同 第2版が 2018年6月21日発売
「徳丸浩のWebセキュリティ教室 」(2015年10月)
22. 参考: NIST SP800-63-3の要求
• 2017年6月にアメリカ国立標準技術研究所(NIST)がNIST
SP 800-63-3を発表
– 従来からの「パスワードの常識」がひっくり返る
• 主な要求は以下の通り
– 利用者が設定する場合、最小8文字
– 管理者側が設定する場合、最小6文字
– 文字種の複雑性などを課すべきではない。すべて数字でもよい
– 脆弱なパスワードをはじく仕組みを導入することを推奨
(辞書によるパスワードチェックなど)
– パスワードの最大文字数は64字まで設定可能とすること および
スペースを入力可能すること(パスフレーズへの対応)
– 秘密の質問は禁止
– アカウントロックの実装
– パスワードの定期的変更の強制の禁止
– パスワードのコピペは許可すべし
22
日本語訳: https://openid-foundation-japan.github.io/800-63-3-final/sp800-63b.ja.html
45. 参考: PHP 7.4にてproc_openに機能追加
proc_open() function
proc_open() now accepts an array instead of a string for the command. In
this case the process will be opened directly (without going through a shell)
and PHP will take care of any necessary argument escaping.
私訳
proc_open() は、コマンドを文字列の代わりに配列として受け入れるように
なりました。この場合、プロセスは(シェルを経由せずに)直接開かれ、
PHPは必要な引数のエスケープを処理します。
45
<?php
proc_open(['php', '-r', 'echo "Hello Worldn";'],
$descriptors, $pipes);
?>
https://www.php.net/manual/en/migration74.new-features.php より引用
53. EC2にてSSRF多層防御が実装された
What’s new in IMDSv2
With IMDSv2, every request is now protected by session authentication. A session
begins and ends a series of requests that software running on an EC2 instance uses
to access the locally-stored EC2 instance metadata and credentials. The software
starts a session with a simple HTTP PUT request to IMDSv2. IMDSv2 returns a secret
token to the software running on the EC2 instance, which will use the token as a
password to make requests to IMDSv2 for metadata and credentials. Unlike
traditional passwords, you don’t need to worry about getting the token to the
software, because the software gets it for itself with the PUT request. The token is
never stored by IMDSv2 and can never be retrieved by subsequent calls, so a session
and its token are effectively destroyed when the process using the token terminates.
There’s no limit on the number of requests within a single session, and there’s no
limit on the number of IMDSv2 sessions. Sessions can last up to six hours and, for
added security, a session token can only be used directly from the EC2 instance
where that session began.
53
https://aws.amazon.com/jp/blogs/security/defense-in-depth-open-firewalls-reverse-
proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
57. 各プロセスでの検討内容とインシデント例
プロセス 検討内容 インシデントの例
サービス企画 法律、各種ガイドライン、
業界慣行への準拠
試練1 キャンペーン企画
プラットフォー
ム設計
プラットフォーム固有の問
題
試練8 EC2のメタデータ
サービス(IMDS)
業務設計 業務上の脆弱性 試練4 パスワードリセット
(管理者)
機能仕様
(コンテンツ)
機能上の脆弱性、(デベ
ロッパー規約)
試練2 パスワードスプレイ
攻撃
デベロッパー規約 試練6 アプリリジェクト
実装設計 実装設計上の脆弱性 試練3 二段階認証の脆弱性
試練5 パスワードの保存
プログラミング プログラミング上の脆弱性 試練7 OSコマンドインジェ
クション
57
59. プロバイダーに関係の深い法律
• 個人情報保護法・GDPR
• 割賦販売法
• 電気通信事業法
• プロバイダー責任制限法
• 著作権法・商標法
• 資金決済法
• 景品表示法・不正競争防止法景品表示法
• 青少年インターネット環境整備法
• 出会い系サイト規制法
• 特定電子メール法
• 特定商取引に関する法律
• 情報処理の高度化等に対処するための刑法等の一部を改正す
る法律(コンピュータ・ウイルスに関する罪)
59
60. 法務的な検討
• 法規制・法的問題点の抽出
– 既存の同種ビジネスの調査
– 文献の検討
– 業界団体の自主規制等の調査
• 法規制・法的問題点の分析・検討
– 法規制等の解釈・検討
• 法務部門との検討
• 外部の専門家に相談
– 監督官庁に相談
※ この項については TMI総合法律事務所[編]、企業の法務 新規ビジネス設
計のケースメソッド、商務法事、2019 を参考にしました
60
64. 業界のガイドラインの例
• コード決済関連
– コード決済に関する統一技術仕様ガイドライン【利用者提示型】
– コード決済に関する統一技術仕様ガイドライン【店舗提示型】
– コード決済に関するオペレーションガイドライン【用語集】
– コード決済における不正流出したクレジットカード番号等の不正利
用防止対策に関するガイドライン
– (いずれも一般社団法人キャッシュレス推進協議会)
• クレジットカード決済
– クレジットカード取引におけるセキュリティ対策の強化に向けた実
行計画-2019-(クレジット取引セキュリティ対策協議会)
– PCI DSS (PCI SSC(Payment Card Industry Security Standards Council))
64
67. [発注] RFPとは
67
• RFP: Request For Proposal (提案依頼書)…簡単に言うと提案仕様書
• RFPの内容に回答する形で、業者は提案書と見積書を作成する
仕様
検討
RFP作
成 提案依頼
A社提案 提案書
見積書
C社提案 提案書
見積書
業者選定 発注B社提案 提案書
見積書
RFP 提案書
依頼書
70. 受託アプリケーションの脆弱性対応
• 「3. Webアプリケーション脆弱性対応」、「4. セキュリ
ティ機能」の要件を満たすこと(後述)
• 脆弱性対応については、セキュリティ実装方針を記した書類
を提出すること(3.2)
– 入札のために新たに書類を作成することは求めておらず、普段用いている
「セキュリティ実装ガイドライン」などを提出すればよい
– ただし、上記に『別紙1脆弱性リスト』を網羅していない場合、洩れている
内容を追記して提出すること
• 「4. セキュリティ機能」については、機能上の要件を満たす
こと
• 「4. セキュリティ機能」の不備に起因する脆弱性がある
– ログイン機能の不備(別紙1の4)
– クロスサイトリクエストフォージェリ(別紙1の6-①)
– クリックジャッキング(別紙1の6-②)
– アクセス制御の不備(別紙1の8)
70
71. 別紙1.脆弱性リストの脆弱性
(1)SQLインジェクション
(2) OSコマンド・インジェクション
(3) ディレクトリ・トラバーサル脆弱性
(4) ログイン機能の不備
①推測可能なセッションID
② URL埋め込みのセッションIDの外部へ
の漏えい
③クッキーのセキュア属性不備
④ セッションIDの固定化
③クッキーのセキュア属性不備
④ セッションIDの固定化
(5) クロスサイト・スクリプティング
(XSS)
(6) 利用者の意図に反した実行の防止機
能の不備
① クロスサイト・リクエスト・フォー
ジェリ(CSRF)
② クリックジャッキング
(7) メールヘッダ・インジェクション脆
弱性
(8) 「アクセス制御」と「認可処理」の
不備
①アクセス制御の不備
②認可処理の不備
(9) HTTPヘッダ・インジェクション
(10) evalインジェクション
(11) 競合状態の脆弱性
(12) 意図しないファイル公開
(13) アップロードファイルによるサーバ
側スクリプト実行
(14) 秘密情報表示時のキャッシュ不停止
(15) オープンリダイレクタ脆弱性(意図
しないリダイレクト)
(16) クローラへの耐性
71
https://www.j-lis.go.jp/lasdec-archive/cms/12,28369,84.htmlより引用
72. 4章 セキュリティ機能
4.1. ログイン処理
4.1.1. 利用者認証方式
4.1.2. アクセス制御機能
4.1.3. パスワードに利用できる文字
4.1.4. ログインフォームの実装方法
4.1.5. ログイン失敗時のメッセージ出力
4.1.6. アカウントロック機能
4.1.7. オフライン攻撃からのパスワード保護
4.1.8. セッション管理機能
4.1.9. セッションの開始
4.1.10. セッションの有効期間
4.1.11. セッションの終了
4.2. 認可処理
4.2.1. 認可処理の要件定義と文書化
4.2.2. 認可処理の実装
4.3. アカウント管理
4.3.1. 利用者登録(アカウントの作成)時における
登録メールアドレスの確認
4.3.2. 利用者IDの重複防止機能
4.3.3. 登録メールアドレス変更機能
4.3.4. パスワード変更機能
4.3.5. パスワードリセット機能
4.3.6. 管理者によるアカウント削除・一時利用停止
機能
4.3.7. 利用者によるアカウント削除機能
4.4. ログイン状態にある利用者の意図に反した機能
実行の防止機能
4.4.1. 該当画面の洗い出し
4.4.2. CSRF対策
4.4.3. クリックジャッキング対策
4.5. ログ出力
4.5.1. 出力するログの種類
4.5.2. 出力しないログの種類
4.5.3. アプリケーションログで取得するイベント
4.5.4. 出力するログの項目
4.5.5. 出力しないログの項目
4.5.6. ログからの情報漏えい・改ざん対策
4.5.7. ログの保管
4.6. 暗号化
4.6.1. 利用者と本システム間におけるWebアプリ
ケーション通信の暗号化
4.6.2. 内部の通信に関する補足
4.6.3. データベースの暗号化
4.6.4. ファイルの暗号化
72https://www.j-lis.go.jp/lasdec-archive/cms/12,28369,84.htmlより引用
74. アジャイル開発でのセキュアシステム構築
• 開発体制強化
• 開発者の教育
• セキュリティ
標準策定
• セキュリティ
担当者育成
• 機能単位のリ
スク分析
• セキュリティ
の個別要件確
定
• プラット
フォーム設計
• 脆弱性診断により脆弱
性がないことの確認
• セキュリティ要件の機
能的なテスト
• テスト結果を
元にリリース
の可否を検討
基本設計 詳細設計 プログラミング テスト リリース
リリース
判定
要件定義企画
• サービスレベルのリ
スク分析
• プラットフォームの
リスク分析
• セキュリティ機能に
関する方針検討
• セキュリティ予算確
保
プロジェクト
開始以前
74
• 設計レビュー
により開発標
準準拠の
チェック
• コードレビューに
より開発標準準拠
のチェック
合格
不合格
• 最初の1回のみ
• イテレーション毎に実施
イテレーション
• セキュリティ
機能の詳細化
• 方式設計によ
りセキュリ
ティバグ対策
方針
78. 業務レベルの脅威分析表にまとめる
業務 発生箇所 脅威 影響 対策
電話による
パスワード
リセット
本人確認 なりすまし 他人のパスワード変更
によるなりすましログ
イン
電話による本人確認には限
界があるので、他の方法で
緩和する
仮パスワード設
定
安全でないパス
ワード付与
仮パスワードの推測に
よるなりすまし
仮パスワードをシステムに
より設定する
担当者による悪用 担当者によるなりすま
し
仮パスワードを担当者から
隠蔽する方法を検討
第三者によるパス
ワードリセット
本来の利用者がログイ
ンできなくなる
仮パスワード設定後も本パ
スワードも有効とする
仮パスワードの
メール送信
メール誤配信 第三者によるパスワー
ドリセット
仮パスワード設定とメール
配信をシステムで同時に行
う
担当者による悪用 担当者による悪用なり
すまし
仮パスワードを担当者から
隠蔽する方法を検討
利用者によるパ
スワード変更
仮パスワードを変
更せず放置
ヘルプデスク担当者に
よるなりすまし
仮パスワードではメール変
更のみができるようにして
パスワード変更を強制メールからの仮パス
ワード漏洩時の脅威増
78
※ この例は業務レベルのものだが、同様に機能レベルの脅威分析も実施できる
82. [運用] Webサイト運用時のポイント
• 脆弱性対応・パッチ適用
– 脆弱性対応やパッチ適用をサイト公開前からベンダーと
打ち合わせ、必要な契約を結んでおく
– パッチの適用方針に従ってパッチが適用されていことを
確認する
– 商用ソフトウェアの場合はパッチ入手に費用がかかる場
合がある。ソフトウェア選定時に確認し、予算を計上し、
必要な契約を結んでおく
• アカウント管理
– 管理者のIDとパスワードが適時更新されていることを確
認する
82
83. [緊急時] インシデント対応のポイント
• あらかじめインシデント時の連絡体制を確認してお
く
• インシデントに気づくトリガーの例
– 監視業者や構築事業者からの連絡
– 侵入検知システムやファイル改ざん検知システムのア
ラート
– 社員が異変(画面改ざん等)に気づく
– 顧客からの連絡(もっとも避けたいパターン)
• インシデントの連絡があった場合は、あらかじめ取
り決めた連絡ルートに連絡して指示を仰ぐ
• サイト停止が基本だが、サイト停止の基準や決裁者
を決めておくこと
83