1.
オニギリペイのセキュリティ事故に学ぶ
安全なサービスの構築法
EG セキュアソリューションズ株式会社
徳丸 浩

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

6.
「オニギリペイ」のシステム構成
6
銀行A
銀行B
クレジットカード事業者C
オニギリペイ
データセンター
店舗（加盟店）
QRコード提示または読み込み

7.
「オニギリペイ」のセキュリティ要件
• 個人情報の漏えい等に対策すること
• 外部ハッカーからのサイバー攻撃に対策すること
• ウイルス対策を施すこと
• SQLインジェクション、XSS等の脆弱性に対応する
こと
• 納品前に脆弱性診断を実施し、検出された脆弱性を
修正すること
• 不正ログインへの対策を盛り込むこと
• 通信路および重要情報を暗号化すること
7

8.
オニギリペイの開発体制
8
発注者
オニギリコーポレーション
元請け
ライス総研
イクラアート
ウメボシソフト
オカカソフト
委託 委託
スマホ担当
その他の開発会社群
委託
デザイン担当
委託
Web担当

9.
ライス総研が提案したセキュリティ施策
• 弊社は従前からセキュアな開発を実施しています
• パスワードリスト攻撃対策として、ユーザIDはシス
テム側で発番します
• CentOS7上のPHP 5.4、MySQL 5.5を用います
• 世界的にセキュリティ面でも評価の高いAmazon
Web Services(AWS)上にシステムを構築します
• フリーのウイルス対策ソフトを導入します
• Tripwire（オープンソース版）により改ざん検知を
実施します
• 常時SSLにより通信を暗号化します
• パスワード等の重要情報を暗号化します
9

10.
オニギリペイは予定通り9月1日
にサービスをローンチしたが、
次々に試練を受けることになる
10

11.
試練#1 キャンペーンを実施したら、某筋から
お叱りを受ける
11

12.
「オニギリペイ」のキャンペーン企画
• オニギリコーポレーションの社長から
PayPayを上回るキャンペーンを実施せよ
と指示が出た
• PayPayは「最大20%還元」をうたっている
• オニギリペイでは、「最大21%還元キャンペーン」
を実施することを決定
• 同キャンペーン開始予定を大々的に宣伝した
12

13.
消費者庁から呼び出しを受ける
13

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/

15.
景品表示法違反行為を行った場合はどうなる?
15https://www.caa.go.jp/policies/policy/representation/fair_labeling/violation/
オニギリペイのケース

16.
消費者庁からの注意への対応
• 消費者庁からの「指導」を受け、キャンペーンの見
直しを迫られた
• キャンペーンの料率を20%に減額し、その旨を大規
模に広報することにより、お許しを得た
• 「PayPayを超えるキャンペーン」は頓挫し、発表済
みのキャンペーンを取り消すことで、消費者に不信
感を与える結果になってしまった
16

17.
試練#2 ログインIDを発番したのに不正ログイ
ンが多発
17

18.
事件の概要
• オニギリペイでは、パスワードリスト攻撃を避ける
ため、ユーザIDをシステム側で発番している
• それにも関わらず、twitter等で、不正ログインの報
告が相次ぐ
18
※架空のツイートです

19.
事件の真相はパスワードスプレー攻撃
19
A0001:password
A0002:123456
A0003:pokemon
A0004:qwerty
A0005:onigiri
A0006:phpcon
A0004:password
A0007:onigiri
攻撃者
オニギリペイ
パスワード試行
命令
A0001:123456
A0003:password
マルウェア感染した
IoT機器によるボット
ネットワーク

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

23.
試練#3 二段階認証を強制したのに不正ログイ
ンが止まらない
23

24.
事件の概要
• 二段階認証を強制しても不正ログインが止まらない
24
※架空のツイートです

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

28.
試練#4 ヘルプデスクが狙われる
28

29.
事件の概要
• 二段階認証の脆弱性を修正した後、パスワードを勝
手に変更された後不正利用されたユーザがあった
29
※架空のツイートです

30.
事件の原因はヘルプデスクから
のパスワードリセット
30

31.
正規のパスワードリセットの流れ
31
もしもし、パスワードがわからなく
なったのですが
承知しました。本人確認のための質
問をいくつかさせていただきます
ユーザーIDはこれこれ、氏名はしかじ
か、住所はかくかく、年齢は…
本人確認がとれました。パスワード
を再発行しますのでお待ち下さい
仮パスワードを受け取りました。あり
がとうございました
お客さまの登録済みメールアドレスに
仮パスワードを送信しました
えーっと、仮パスワードはoni1234
にしようか…メール送信機能で仮
パスワードをメールしてっと

32.
パスワードリセットに対する攻撃の流れ
32
もしもし、ユーザーIDとパスワードが
わからなくなったのですが
承知しました。本人確認のための質
問をいくつかさせていただきます
氏名はこれこれ、住所はかくかく、年
齢はしかじか、電話番号は…
本人確認がとれました。IDとパス
ワードをメールしますのでお待ち下
さい
サンキュー
かしこまりました。お客さまのIDは
A0123です。仮パスワードはoni1234
に設定しました
えーっと、いいのかな…面倒くさそ
うなお客だから、答えちゃえ
仮パスワードをoni1234にセットし
て…
いやそれが、メールアドレスが変わっ
たのでこの電話で教えて下さい

33.
攻撃を受けた要因とオニギリペイの対策
• 要因
– イレギュラー時のマニュアルとエスカレーションフロー
が整備されていない
– 住所、氏名などの個人情報は他人が知り得る情報なので、
これらだけでパスワードリセットするとなりすましの危
険性がある
– オペレーターが仮パスワードを知り得るのもよくない
• オニギリペイの対策
– 仮パスワードは登録済みメールアドレスへの通知のみと
した
– メールアドレスがわからない場合のフローを書面による
通知とした
– オペレーターのマニュアル整備と教育
33

34.
徳丸本2版にこう書いてある
本人確認ができたらパスワードをリセットして本人
に伝えますが、電話などでそのまま答えるのではなく、
管理用アプリケーションからリセット後のパスワード
を直接メールで送信するようにした方がよいでしょう。
そうする理由としては以下があります。
 管理者やヘルプデスク担当者がパスワードを見ない
ので悪用の心配がない
 本人を装った成りすましの電話であっても、パス
ワードを知られるリスクが減らせる
※ 安全なWebアプリケーションの作り方第2版 P503より引用
34

35.
試練#5 スマホアプリの脆弱性を指摘される
35

36.
オニギリコーポレーションに一通のメールが
オニギリコーポレーションCSIRT御中
徳丸と申します。お世話になります。
さて、貴社サービス「オニギリペイ」のスマホアプリを確認させていただい
たところ、下記のファイルにユーザーのパスワードが平文で保存されている
ことを確認しました（Android版の場合）。
/data/data/com.onigiripay/shared_prefs/com.onigiripay_preferences.xml
リモートからパスワードを盗まれるわけではありませんが、端末紛失時や盗
難時にパスワードが保護されていない状況となり危険です。
パスワードのような重要情報は安全な領域に保存されるべきかと思い、報告
いたします。
36

37.
脆弱性の要因とオニギリコーポレーションの対応
• 状況
– Webサーバー上ではパスワードはpassword_hashにてハッ
シュ値で保存されていた（オカカソフト担当）
– スマホアプリを担当したウメボシソフトはパスワードを
端末上で保護する方法について意識がなかった
– 元請けのライスデータ社は下請け企業に具体的なセキュ
リティ施策の指示をしておらず検収時の検査もなかった
• オニギリコーポレーションの対応
– ライスデータ社の担当者を呼びつけ厳重に注意した
37

38.
脆弱性の改修とスマホアプリのバージョンアップ
• 脆弱性対応
– パスワードは以下の安全な領域に保存するよう改修した
• iOS: KeyChain
• Android: KeyStore
• バージョンアップの呼びかけ
– 利用者のバージョンアップを
呼びかけた（右図）
– 脆弱性があったことは告知せず、
「軽微なバグを修正しました」
と案内（良くない）
38
Android版バージョン
アップのお知らせ🍙

39.
試練#6 スマホアプリのアップデートを広報し
たらアプリがリジェクトされる
39

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/

42.
試練#7 「あの有名な脆弱性」で大変なことに
42

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 より引用

46.
徳丸の願いが6年越しで実現した
46
https://blog.tokumaru.org/2013/12/php_21.html より引用

47.
試練#8 WAFを導入したらかえって脆弱になる
47

48.
事件の概要
• WAF用に構築したリバースプロキシが、オープンリ
バースプロキシとなっていた
• その結果、SSRF脆弱性が生じていた
• SSRF攻撃により、AWS IAMのクレデンシャルが漏
洩、S3に保存していた個人情報等が漏洩した
※ 1億人超の個人情報が漏洩した Capital Oneの事故をモデルにしています
参考: SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた
https://piyolog.hatenadiary.jp/entry/2019/08/06/062154
48

49.
mod_securityによるWAFの概要
49
Apache+mod_security Webサーバー
(Nginx)リバースプロキシとして構成
AWS
EC2

50.
攻撃の模様
50
Apache+mod_security
リバースプロキシとして構成
AWS
EC2
Amazon
S3
169.254.169.254
（IMDSのエンドポイント）
SSRF攻撃により
ISRM-WAF-Role
にアクセス
ISRM-WAF-Role
S3
個人情報などを保管

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

56.
オニギリペイはどうすれば
よかったか?
56

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

65.
概要レベルの業務フローでリスクを分析する
65
一般社団法人キャッシュレス推進協議会
「コード決済における不正流出したクレジットカード番号等䛾不正利用防止対策に関するガイドライン」より引用

66.
[発注] 発注がセキュリティを左右する
• セキュリティにはお金が掛かるし、予算を提示する
のは発注者である
• ビルを建てる場合…どの程度の耐震性を持たせるか
は発注者の意思
– 耐震性能によって、建築費用も変わってくる
• セキュリティを後付けにするのは効率が悪い
• 発注後のセキュリティ強化指示はすべて「追加予
算」となり、かつ業者の言いなりになりやすい
• 発注前にセキュリティ仕様を示していれば、「競争
原理」が働き、費用を抑えやすい
66

67.
[発注] RFPとは
67
• RFP: Request For Proposal （提案依頼書）…簡単に言うと提案仕様書
• RFPの内容に回答する形で、業者は提案書と見積書を作成する
仕様
検討
RFP作
成 提案依頼
A社提案 提案書
見積書
C社提案 提案書
見積書
業者選定 発注B社提案 提案書
見積書
RFP 提案書
依頼書

68.
[発注] RFPが重要である理由
• システムの概要はベンダーの提案書の内容がベース
となる
• 提案時の見積もりがシステムの概略予算となる
• つまり、RFPの回答の時点でシステムの大枠が決ま
り、セキュリティの概要もこの時点で決まる
• 発注者が、提案書の内容に関与できるのはRFPだけ
である
• 発注後の要求は、基本的に追加費用が掛かり、ベン
ダーの言いなりになりがち
68

69.
セキュリティ要件の例 「モデルプラン」
地方公共団体における情報システムセキュリティ要求仕様モデ
ルプラン（Webアプリケーション）とは
「地方公共団体における情報システムセキュリティ要求仕様
モデルプラン（Webアプリケーション）」は、地方公共団体に
おいてWebアプリケーションを導入するにあたって、システム
の脆弱性をなくし、安全に運用するために必要な要求仕様事項
を取りまとめた特記仕様書の例です。
同書の内容を一部カスタマイズして各団体の「Webアプリ
ケーションセキュリティに関する特記仕様書」を検討、作成い
ただき、入札仕様書に追加要件として添付することにより、
SQLインジェクション、クロスサイト・スクリプティングと
いったWebアプリケーションの脆弱性や、納品後（運用時）に
新たに発見された脆弱性についても計画的に解決するための道
筋をつけられるようになることを目的として作成しています。
69
https://www.j-lis.go.jp/lasdec-archive/cms/12,28369,84.htmlより引用

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