オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
•
66 likes•9,714 views
PHPカンファレンス2019「オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 」のスライドです。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
Similar to オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019) (20)
More from Hiroshi Tokumaru
More from Hiroshi Tokumaru (20)
Recently uploaded
Recently uploaded (8)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (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月)
- 4. 「オニギリペイ」とは 4
- 5. 「オニギリペイ」のRFP（概要） • この文書はオニギリコーポレーション㈱が提供するQR コード決済システム「オニギリペイ」のRFPである • バーコードおよびQRコードの表示あるいは読み取りに よる決済機能を実現すること • クレジットカードおよびオンラインバンキングからの入 金機能を実現すること • できる限りオープンソースソフトウェアを用いて構築す ること • アジャイル開発を用いること • パブリッククラウド上に構築すること ※ オニギリペイおよび関連各社はすべて架空のものです 5
- 7. 「オニギリペイ」のセキュリティ要件 • 個人情報の漏えい等に対策すること • 外部ハッカーからのサイバー攻撃に対策すること • ウイルス対策を施すこと • SQLインジェクション、XSS等の脆弱性に対応する こと • 納品前に脆弱性診断を実施し、検出された脆弱性を 修正すること • 不正ログインへの対策を盛り込むこと • 通信路および重要情報を暗号化すること 7
- 9. ライス総研が提案したセキュリティ施策 • 弊社は従前からセキュアな開発を実施しています • パスワードリスト攻撃対策として、ユーザIDはシス テム側で発番します • CentOS7上のPHP 5.4、MySQL 5.5を用います • 世界的にセキュリティ面でも評価の高いAmazon Web Services(AWS)上にシステムを構築します • フリーのウイルス対策ソフトを導入します • Tripwire（オープンソース版）により改ざん検知を 実施します • 常時SSLにより通信を暗号化します • パスワード等の重要情報を暗号化します 9
- 12. 「オニギリペイ」のキャンペーン企画 • オニギリコーポレーションの社長から PayPayを上回るキャンペーンを実施せよ と指示が出た • PayPayは「最大20%還元」をうたっている • オニギリペイでは、「最大21%還元キャンペーン」 を実施することを決定 • 同キャンペーン開始予定を大々的に宣伝した 12
- 14. 消費者庁からの注意 • 今回のキャンペーンは、「懸賞」によらずに提供される景品類として扱 われ、景品表示法におけ「総付景品」にあたる • 総付景品は取引金額の20%までと定められている （平成28年4月1日内閣府告示第１２３号 ） 14 取引価額 景品類の最高額 1,000円未満 200円 1,000円以上 取引価額の10分の2 総付景品の限度額 景品規制の概要 | 消費者庁 https://www.caa.go.jp/policies/policy/representation/fair_labeling/premium_regulation/
- 16. 消費者庁からの注意への対応 • 消費者庁からの「指導」を受け、キャンペーンの見 直しを迫られた • キャンペーンの料率を20%に減額し、その旨を大規 模に広報することにより、お許しを得た • 「PayPayを超えるキャンペーン」は頓挫し、発表済 みのキャンペーンを取り消すことで、消費者に不信 感を与える結果になってしまった 16
- 20. パスワードスプレイ攻撃の原理 • 少数のパスワード候補をIDを変えながら試す • 多数のIPアドレスからの分散攻撃 • わざと「ゆっくりとした」攻撃により監視をくぐり抜ける • 2013年11月に起こったGitHubを狙ったパスワード試行は、 パスワードスプレー攻撃の初期の例と考えられる 参考: GitHubに大規模な不正ログイン試行 | 徳丸浩の日記 https://blog.tokumaru.org/2013/11/github.html 20
- 21. 攻撃を受けた要因とオニギリペイの対策 • 要因 – ユーザIDが連番だった（A0001、A0002、…） – 弱いパスワードを許可していた – 二段階認証が必須ではなくオプションだった • オニギリペイ対策 – 二段階認証を必須にした 21
- 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
- 25. 事件の真相は２段階認証の実装不備 25 ユーザID パスワード ログイン A0001 *** メッセージに記載の 番号を入力 123456 ログイン 認証されました。 ご利用をお続けください ホーム画面に進む if (IDとパスワードが正しい) { $_SESSION['userid'] = $_POST['userid']; $token = random_int(0, 999999); $_SESSION['auth_token'] = $token; send_sms_token(電話番号、$token); 認証トークンの入力フォームを表示 } else { ログインエラー } if ($_SESSION['auth_token'] == $_POST['token']) { $_SESSION['auth_token'] = null; // クリアしておく header('Location: ' + 認証後URL); exit; } else { 二段階認証エラー }
- 26. ２段階認証はバイパスできた 26 ユーザID パスワード ログイン A0001 *** メッセージに記載の 番号を入力 ログイン ホーム : オニギリペイ オニギリペイにようこそ if (IDとパスワードが正しい) { $_SESSION['userid'] = $_POST['userid']; $token = random_int(0, 999999); $_SESSION['auth_token'] = $token; send_sms_token(電話番号、$token); 認証トークンの入力フォームを表示 } else { ログインエラー } 認証の確認方法 if (! empty($_SESSION['userid'])) { // 二段階認証の前にセッション変数はセットされている // ので認証成功 ... } 手動で遷移
- 27. 攻撃を受けた要因とオニギリペイの対策 • 要因 – 根本原因は２段階認証の実装不備 – ツールによる脆弱性診断では、この問題は検出されな かった • オニギリペイの対策 – セッション変数を追加して認証状態を管理した • 未ログイン • 二段階認証待ち • ログイン済 – 専門家による手動の脆弱性診断を実施 27
- 33. 攻撃を受けた要因とオニギリペイの対策 • 要因 – イレギュラー時のマニュアルとエスカレーションフロー が整備されていない – 住所、氏名などの個人情報は他人が知り得る情報なので、 これらだけでパスワードリセットするとなりすましの危 険性がある – オペレーターが仮パスワードを知り得るのもよくない • オニギリペイの対策 – 仮パスワードは登録済みメールアドレスへの通知のみと した – メールアドレスがわからない場合のフローを書面による 通知とした – オペレーターのマニュアル整備と教育 33
- 34. 徳丸本2版にこう書いてある 本人確認ができたらパスワードをリセットして本人 に伝えますが、電話などでそのまま答えるのではなく、 管理用アプリケーションからリセット後のパスワード を直接メールで送信するようにした方がよいでしょう。 そうする理由としては以下があります。 管理者やヘルプデスク担当者がパスワードを見ない ので悪用の心配がない 本人を装った成りすましの電話であっても、パス ワードを知られるリスクが減らせる ※ 安全なWebアプリケーションの作り方第2版 P503より引用 34
- 37. 脆弱性の要因とオニギリコーポレーションの対応 • 状況 – Webサーバー上ではパスワードはpassword_hashにてハッ シュ値で保存されていた（オカカソフト担当） – スマホアプリを担当したウメボシソフトはパスワードを 端末上で保護する方法について意識がなかった – 元請けのライスデータ社は下請け企業に具体的なセキュ リティ施策の指示をしておらず検収時の検査もなかった • オニギリコーポレーションの対応 – ライスデータ社の担当者を呼びつけ厳重に注意した 37
- 38. 脆弱性の改修とスマホアプリのバージョンアップ • 脆弱性対応 – パスワードは以下の安全な領域に保存するよう改修した • iOS: KeyChain • Android: KeyStore • バージョンアップの呼びかけ – 利用者のバージョンアップを 呼びかけた（右図） – 脆弱性があったことは告知せず、 「軽微なバグを修正しました」 と案内（良くない） 38 Android版バージョン アップのお知らせ🍙
- 40. 何が起こったか • iOS版のオニギリペイアプリがApp Storeから消えた • アプリがリジェクトされたことが判明 • 連絡くらいくれてもいいのに… • オニギリコーポレーションにリジェクト警告メール が来ていたが、担当者がスパムと思い込んで読んで いなかった 40
- 41. 原因と対策 • iOS版アプリに「Android版アプリのお知ら せ」を掲載したことが原因だった • お知らせを差し替え、再申請によりアプリが 復活 • 今後は、お知らせに他プラットフォームの情 報は掲載しないよう運営担当に徹底した App Store Reviewガイドライン 2.3.10 AppはiOS、Mac、Apple TV、Apple Watchでの使用を前提としてください。許可を 得た特定の相互作用的機能がある場合を除き、 他のモバイルプラットフォームの名前、アイコ ン、画像をAppまたはメタデータに含むことは できません。 41 Android版バージョン アップのお知らせ🍙 https://developer.apple.com/jp/app-store/review/guidelines/
- 43. 事件の概要 • オニギリペイのウェブアプリケーションにOSコマ ンドインジェクションがあり、不正アクセスされた • WebサーバーにWebShellを設置されたが、改ざん検 知システムにより検知され、サーバーをシャットダ ウン、個人情報漏洩には至らなかった • 個人情報漏えい等がなかったので、この事件は公表 されなかった – 改ざん検知システムで早期に発見できたのは良かった – 侵入自体はされているので公表を見送ったのは良くない 43
- 44. 攻撃を受けた要因とオニギリペイの対策 • 要因 – 画像処理の部分でImageMagickのconvertコマンドを起動 しており、エスケープ漏れがあった proc_open("convert $infile –crop $crop_option $outfile", • オニギリペイの対策 – escapeshellarg関数よりOSコマンド（シェル）用のエス ケープ処理を追加した – mod_securityによるWAF(Web Application Firewall)をEC2 上に構築して追加した 44 この変数のエスケープ 処理が漏れていた
- 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 より引用
- 48. 事件の概要 • WAF用に構築したリバースプロキシが、オープンリ バースプロキシとなっていた • その結果、SSRF脆弱性が生じていた • SSRF攻撃により、AWS IAMのクレデンシャルが漏 洩、S3に保存していた個人情報等が漏洩した ※ 1億人超の個人情報が漏洩した Capital Oneの事故をモデルにしています 参考: SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた https://piyolog.hatenadiary.jp/entry/2019/08/06/062154 48
- 51. 攻撃を受けた要因とオニギリペイの対策 • 要因 – WAFとして構成したApacheがオープンリバースプロキシ となっていて、任意のホストへの接続を許していた （SSRF脆弱性） – WAFのEC2インスタンスから、169.254.169.254へのアク セス制御をしていなかった • オニギリペイの対策 – Apacheの設定を見直し、オープンリバースプロキシの状 態を解消した 51
- 52. 参考: SSRF対策について • ネットワーク的な保護 URLの完全な検証は難しいので、ネットワーク的な保護も有効です。以下は、AWS のドキュメントで推奨されている iptables の設定例。 これにより、「docker0 ブリッジのコンテナがコンテナインスタンスのロールに指 定されている権限にアクセスするのを防止できます」としている。iptablesによる 設定は環境依存なので注意 sudo iptables --insert FORWARD 1 --in-interface docker+ -- destination 169.254.169.254/32 --jump DROP Amazon ECS コンテナインスタンスの IAM ロール - Amazon Elastic Container Service より引用 52
- 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/
- 54. EC2インスタンスメタデータサービスv2(IMDSv2)とは • IMDSv2は主にSSRF攻撃によるEC2メタデータ漏洩に対する 緩和策（多層防御）と位置づけられる – IMDSv2アクセスにはトークンが必要 – トークン取得のアクセスにはPUTメソッドを用いる – トークン指定はX-aws-ec2-metadata-tokenリクエストヘッダを設定 – 上記はSSRF攻撃では困難なので、SSRF攻撃の緩和策として働く • IMDSv1を禁止するコマンド $ aws ec2 modify-instance-metadata-options --instance-id i-12345 67890123456 --http-token required --http-endpoint enabled • IMDSによるメタデータ取得自体を禁止するコマンド $ aws ec2 modify-instance-metadata-options --instance-id i-12345 67890123456 --http-endpoint disabled 54
- 55. 終了 55
- 57. 各プロセスでの検討内容とインシデント例 プロセス 検討内容 インシデントの例 サービス企画 法律、各種ガイドライン、 業界慣行への準拠 試練1 キャンペーン企画 プラットフォー ム設計 プラットフォーム固有の問 題 試練8 EC2のメタデータ サービス(IMDS) 業務設計 業務上の脆弱性 試練4 パスワードリセット （管理者） 機能仕様 （コンテンツ） 機能上の脆弱性、（デベ ロッパー規約） 試練2 パスワードスプレイ 攻撃 デベロッパー規約 試練6 アプリリジェクト 実装設計 実装設計上の脆弱性 試練3 二段階認証の脆弱性 試練5 パスワードの保存 プログラミング プログラミング上の脆弱性 試練7 OSコマンドインジェ クション 57
- 58. サービス企画時の注意 • 関連法規・ガイドライン等の確認 • サービスレベルのリスク分析 • セキュリティ方針を立ててセキュリティ予算を確保 • 機能要件に加えてセキュリティ要件をまとめて、 RFPに反映する • ベンダー選定 – 準備（RFPの準備など） – コンペ – ベンダー選定 58
- 59. プロバイダーに関係の深い法律 • 個人情報保護法・GDPR • 割賦販売法 • 電気通信事業法 • プロバイダー責任制限法 • 著作権法・商標法 • 資金決済法 • 景品表示法・不正競争防止法景品表示法 • 青少年インターネット環境整備法 • 出会い系サイト規制法 • 特定電子メール法 • 特定商取引に関する法律 • 情報処理の高度化等に対処するための刑法等の一部を改正す る法律（コンピュータ・ウイルスに関する罪） 59
- 60. 法務的な検討 • 法規制・法的問題点の抽出 – 既存の同種ビジネスの調査 – 文献の検討 – 業界団体の自主規制等の調査 • 法規制・法的問題点の分析・検討 – 法規制等の解釈・検討 • 法務部門との検討 • 外部の専門家に相談 – 監督官庁に相談 ※ この項については TMI総合法律事務所[編]、企業の法務 新規ビジネス設 計のケースメソッド、商務法事、2019 を参考にしました 60
- 61. [参考]景品表示法の相談・被疑情報の受付窓口 御相談 事業者がこれから行う企画の相談は、次の担当部署へお願いいたします。 ※御相談いただく前に、まずはこちら(「運用基準・ガイドライン」、「よ くある質問コーナー(景品表示法Q&A)」)をご覧ください。 消費者庁 表示対策課 指導係 03-3507-8800(代表) また、御相談の内容によっては、回答までに相当期間要することがありま す。実施直前に御相談いただいても回答できない場合がありますので、時 間的余裕をもって御相談下さい。なお、来庁による御相談を御希望の方は、 事前に担当官と電話で日時を打合わせていただきますようお願いいたしま す。 ※文書で照会する方法もある（ノーアクションレター制度） 61 https://www.caa.go.jp/policies/policy/representation/contact/ より引用
- 62. 「起業の法務」は新規事業の法務検討にお勧め • 「はじめに」から 法律書であることの性格上、法務部門 向けの内容になっているが、事業部門 の事業開発担当者にも、法的思考や、 リーガル・アプローチを体感していた だくことができる構成を企図している • 第1編は新規ビジネスにおける法 務的課題と解決策の概観 • 第2編は具体的な新規ビジネスを 例示し、課題に対する具体的な アプローチを説明（これがすご い） 62 TMI総合法律事務所[編]、 企業の法務 新規ビジネス設計のケースメソッド、 商務法事、2019
- 63. リスクアセスメントの方法 (1) ベースラインアプローチ 既存の標準や基準をもとにベースライン（自組織の対策基準）を策定し、チェック していく方法。簡単にできる方法であるが、選択する標準や基準によっては求める 対策のレベルが高すぎたり、低すぎたりする場合がある (2) 非形式的アプローチ コンサルタント又は組織や担当者の経験、判断によりリスクアセスメントを行う。 短時間に実施することが可能であるが、属人的な判断に偏る恐れがある。 (3) 詳細リスク分析 詳細なリスクアセスメントを実施。情報資産に対し「資産価値」「脅威」「脆弱 性」「セキュリティ要件」を識別し、リスクを評価していく。 厳密なリスク評価が行えるものの多大な工数や費用がかかる (4) 組合せアプローチ 複数のアプローチの併用。よく用いられるのは、(1)ベースラインアプローチと(3)詳 細リスク分析の組合せ。ベースラインアプローチと詳細リスク分析の両方のメリッ トが享受できる。 63 IPA 「情報セキュリティマネジメントとPDCAサイクル」より引用 https://www.ipa.go.jp/security/manager/protect/pdca/risk_ass.html
- 64. 業界のガイドラインの例 • コード決済関連 – コード決済に関する統一技術仕様ガイドライン【利用者提示型】 – コード決済に関する統一技術仕様ガイドライン【店舗提示型】 – コード決済に関するオペレーションガイドライン【用語集】 – コード決済における不正流出したクレジットカード番号等の不正利 用防止対策に関するガイドライン – （いずれも一般社団法人キャッシュレス推進協議会） • クレジットカード決済 – クレジットカード取引におけるセキュリティ対策の強化に向けた実 行計画－２０１９－（クレジット取引セキュリティ対策協議会） – PCI DSS (PCI SSC(Payment Card Industry Security Standards Council)) 64
- 66. [発注] 発注がセキュリティを左右する • セキュリティにはお金が掛かるし、予算を提示する のは発注者である • ビルを建てる場合…どの程度の耐震性を持たせるか は発注者の意思 – 耐震性能によって、建築費用も変わってくる • セキュリティを後付けにするのは効率が悪い • 発注後のセキュリティ強化指示はすべて「追加予 算」となり、かつ業者の言いなりになりやすい • 発注前にセキュリティ仕様を示していれば、「競争 原理」が働き、費用を抑えやすい 66
- 67. [発注] RFPとは 67 • RFP: Request For Proposal （提案依頼書）…簡単に言うと提案仕様書 • RFPの内容に回答する形で、業者は提案書と見積書を作成する 仕様 検討 RFP作 成 提案依頼 A社提案 提案書 見積書 C社提案 提案書 見積書 業者選定 発注B社提案 提案書 見積書 RFP 提案書 依頼書
- 68. [発注] RFPが重要である理由 • システムの概要はベンダーの提案書の内容がベース となる • 提案時の見積もりがシステムの概略予算となる • つまり、RFPの回答の時点でシステムの大枠が決ま り、セキュリティの概要もこの時点で決まる • 発注者が、提案書の内容に関与できるのはRFPだけ である • 発注後の要求は、基本的に追加費用が掛かり、ベン ダーの言いなりになりがち 68
- 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より引用
- 73. セキュリティ保証期間 • 基本的に、Webサイトの稼働年限をあらかじめ定めて、その 期間中のセキュリティ対応を約束してもらうもの • セキュリティ保証期間は発注者が要求として定めるものです が、目安として5年を想定している – ハードウェアの耐用年数 – OS/ミドルウェアのサポート期間 – 言語、フレームワークなどアーキテクチャの「寿命」 • セキュリティ保証期間中に脆弱性が発見された場合、以下の 対応を求めている – 受託アプリケーションについては、追加費用無しの修補 – 仕入れソフトウェアやオープンソースソフトウェア(FLOSS)については、遅 滞なくパッチ適用すること Copyright © 2008-2017 EG Secure 73
- 74. アジャイル開発でのセキュアシステム構築 • 開発体制強化 • 開発者の教育 • セキュリティ 標準策定 • セキュリティ 担当者育成 • 機能単位のリ スク分析 • セキュリティ の個別要件確 定 • プラット フォーム設計 • 脆弱性診断により脆弱 性がないことの確認 • セキュリティ要件の機 能的なテスト • テスト結果を 元にリリース の可否を検討 基本設計 詳細設計 プログラミング テスト リリース リリース 判定 要件定義企画 • サービスレベルのリ スク分析 • プラットフォームの リスク分析 • セキュリティ機能に 関する方針検討 • セキュリティ予算確 保 プロジェクト 開始以前 74 • 設計レビュー により開発標 準準拠の チェック • コードレビューに より開発標準準拠 のチェック 合格 不合格 • 最初の1回のみ • イテレーション毎に実施 イテレーション • セキュリティ 機能の詳細化 • 方式設計によ りセキュリ ティバグ対策 方針
- 75. 脅威・リスク分析について • ウォーターフォール型開発では、要件定義前に脅威 分析を済ませておくのだが… • 脅威の中には、機能や実装に依存するものもあるの で、アジャイル型開発ではすべての脅威分析を事前 にすませることはできない • 脅威分析もインクリメンタルに行う – ビジネスモデルやコア機能による脅威分析は計画段階で 行う – イテレーションによる追加機能により脅威が発生しそう な場合は、イテレーションの中で脅威分析を行う 75
- 76. 業務フロー図で業務内容を可視化 顧客 ヘルプデスク担当者 ヘルプデスクシステム 76 問合せ受付け 本人確認 仮パスワード設定 顧客検索 ユーザ マスター パスワード変更 仮パスワード メール通知 メール送信 変更成功を連絡 問い合わせ クローズ ログイン・ パスワード変更 電話問合せ メールシステム 仮パスワード メール受け取り
- 77. 業務フロー図に「ツッコミ」を入れていく 顧客 ヘルプデスク担当者 ヘルプデスクシステム 77 問合せ受付け 本人確認 仮パスワード設定 顧客検索 ユーザ マスター パスワード変更 仮パスワード メール通知 メール送信 変更成功を連絡 問い合わせ クローズ ログイン・ パスワード変更 電話問合せ メールシステム 本人確認の情報 は大丈夫か? 仮パスワードを オペレータに決 めさせる? 他人に仮パスワードを誤配 送するリスクは? 担当者による悪用は? 仮パスワード メール受け取り 仮パスワードを変 更せずにクローズ する可能性
- 78. 業務レベルの脅威分析表にまとめる 業務 発生箇所 脅威 影響 対策 電話による パスワード リセット 本人確認 なりすまし 他人のパスワード変更 によるなりすましログ イン 電話による本人確認には限 界があるので、他の方法で 緩和する 仮パスワード設 定 安全でないパス ワード付与 仮パスワードの推測に よるなりすまし 仮パスワードをシステムに より設定する 担当者による悪用 担当者によるなりすま し 仮パスワードを担当者から 隠蔽する方法を検討 第三者によるパス ワードリセット 本来の利用者がログイ ンできなくなる 仮パスワード設定後も本パ スワードも有効とする 仮パスワードの メール送信 メール誤配信 第三者によるパスワー ドリセット 仮パスワード設定とメール 配信をシステムで同時に行 う 担当者による悪用 担当者による悪用なり すまし 仮パスワードを担当者から 隠蔽する方法を検討 利用者によるパ スワード変更 仮パスワードを変 更せず放置 ヘルプデスク担当者に よるなりすまし 仮パスワードではメール変 更のみができるようにして パスワード変更を強制メールからの仮パス ワード漏洩時の脅威増 78 ※ この例は業務レベルのものだが、同様に機能レベルの脅威分析も実施できる
- 79. 脅威分析を具体的にすすめるには? • ウェブシステムに対する脅威分析の資 料はあまり良いものがない • IoTシステムに関するIPAの資料がよく できているのでお勧め – 先の脅威分析も右の資料の脅威分析表を拡 張したもの • すべてのインターネットシステムは IoTシステムのサブセットなので、流 用は容易 – スマホ・アプリが入ることで、広義に はIoTシステムとも捉えられる • すべてを詳細に分析することは難しい ので既存のガイドラインを活用して、 脅威分析の手間を減らすとよい（組み 合わせ的アプローチ） 79 https://www.ipa.go.jp/files/ 000052459.pdf
- 80. セキュリティ施策の優先度とスケジュール策定 • セキュリティ機能については、必要不可欠なものと、追加的 なものがある • 必要不可欠なセキュリティ機能はWebサイトの公開までに実 現する • 追加的なセキュリティ機能は、リリース後の導入もあり得る 80 企画 イテレーション1 イテレーション2 イテレーション3 イテレーション4 コア機能実装 コンセプト確認 ログイン機能の モックアップ実装 会員管理 ログイン・ログアウト サイト 公開 二段階認証 WAFの導入 専門家による 脆弱性診断
- 81. 脆弱性テスト（脆弱性診断） • アジャイル型開発ではソフトウェアのリリースを頻繁に行う ので、リリース毎にサイト全体の診断を実施するのは現実的 でない • インクリメンタルな脆弱性診断の実施が望まれるが… • ソフトウェア改修の際に既存機能に脆弱性混入（リグレッ ション）の可能性 • そのためにも、脆弱性テストの自動化が鍵 • 汎用の脆弱性診断ツールを用いる（例: OWASP ZAPのAPIの 活用） • 汎用のテストツールで脆弱性診断できないか? • 継続的テストに特化したツール・サービスを用いる • ソースコード診断ツールを用いる 81
- 82. [運用] Webサイト運用時のポイント • 脆弱性対応・パッチ適用 – 脆弱性対応やパッチ適用をサイト公開前からベンダーと 打ち合わせ、必要な契約を結んでおく – パッチの適用方針に従ってパッチが適用されていことを 確認する – 商用ソフトウェアの場合はパッチ入手に費用がかかる場 合がある。ソフトウェア選定時に確認し、予算を計上し、 必要な契約を結んでおく • アカウント管理 – 管理者のIDとパスワードが適時更新されていることを確 認する 82
- 83. [緊急時] インシデント対応のポイント • あらかじめインシデント時の連絡体制を確認してお く • インシデントに気づくトリガーの例 – 監視業者や構築事業者からの連絡 – 侵入検知システムやファイル改ざん検知システムのア ラート – 社員が異変（画面改ざん等）に気づく – 顧客からの連絡（もっとも避けたいパターン） • インシデントの連絡があった場合は、あらかじめ取 り決めた連絡ルートに連絡して指示を仰ぐ • サイト停止が基本だが、サイト停止の基準や決裁者 を決めておくこと 83
- 84. まとめ • オニギリペイ（架空）の事例をもとに安全なインター ネットの構築法を説明 • 脅威分析・リスク分析の勧め – 「徳丸本に書いてあること」はそのまま使えば、その分の脅威 分析は省略できる（ベースラインアプローチ） • 安全なシステムの発注について • アジャイル開発にセキュア開発を適用する 84