オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法

後ろに座るとスライドが見えない…kadoyau.icon

Twitterにスライドが上がっていた

Phpconf2019

架空の決済システムオニギリペイでセキュリティをロールプレイ

p.5

p.6

チャージはクレカとかからできる

p.7

お手本ではない

一般的なRFPのかきぶり

p.9

元請けの提案

細かいツッコミはともかくまあちゃんとやってくれるんだろうと期待される

p.12

PayPayが最大20%還元なので21%還元キャンペーンをした

懸賞であるため、景品表示法で消費者庁に怒られる

広報段階で発覚したので指導ですんだと想定

p.18

ユーザーIDが連番だったので、不正ログインが相次いだ

パスワードスプレー攻撃

DDoSではないのでわっとはこない

様々なIPからちょろちょろくる

検知がむずい

password5-10、IDもかえる

ありがちなPWを狙う

brute forceだと

password固定でID変更

原因

ユーザIDが連番

弱いPWの許可

二段階認証がオプション

対策

IDそのものを推測しにくくする

オニギリの対策

二段階認証必須に

NIST SP800-63-3

制限は良くない。すべて数字でも良い

脆弱なパスワードは辞書をもっておいて登録させない

123456, password, pokemon

秘密の質問の禁止

定期変更強制の禁止

p.23

試練3：二段階認証が強制なのに不正ログイン

原因

2段階認証の実装不備

p.26

手動でURLを叩くと（二段階認証の実装が甘くて）バイパスできる

ちょっとひどい

現実的にこのレベルの問題もありうる

もっと複雑なものも考えたが時間がないので割愛

対策

未ログイン、二段階認証街、ログイン済に状態を分けるなど

p.28

試練4 ヘルプデスクからのパスワードリセットの悪用

ソーシャルハック

要因

エスカレーションフロー不足

住所氏名でリセットならなりすませる

オペレータが仮パスワードを知っている

オニギリの対策

運用でカバー

徳丸本

管理用アプリから自動メール送信するのがよい

ヘルプデスクはパスワードを知ることができない

なりすましでもメールは登録済に送られる

p.35 スマホアプリの脆弱性の指摘

webはhash化されていた

スマホは平文が必要なのでpreferenceにおいていた

元請けは指示なく、検査もなし

オニギリの対策

下請けに厳重注意

安全領域に保存するようにした

iOS KeyChain

Android KeyStore

アプリアップデート

「軽微なバグを終止しました」（よくない）

p.40 アプリリジェクト

警告メールを見落としていた

iOS版アプリにAndroid版アプリのお知らせを掲載していた

platformにはじかれる

App Store Reviewガイドライン：2.3.10

p.42 OS command injection

シナリオ上ちょっと苦しいが…

WebShellを設置されたが、改ざん検知した

個人情報漏洩がなかったので、公表されなかった

「本来リリースするべきだと思う」

GAFAとかだとある「問題はあったが漏洩はしていない」

日本だとあまりやられない

原因

ImageMagicのconvertコマンドのエスケープ漏れ

オニギリの対策

escapeshellargでエスケープ処理

mod_securityによるWAFをEC2に構築して追加

PHP 7.4でproc_openに追加機能

原理上OS command injectionがない

シェルを経由せずに処理する

OS commandを呼ぶことはあまりないが、つかうならこれをつかうのがおすすめ

PHPだってシェル経由でないコマンド呼び出し機能が欲しい | 徳丸浩の日記

p.48 WAF(firewall)導入で脆弱になる

apacheをリバースプロキシにした

proxyから任意のホストに接続できるのでIAMのcredientialが漏洩し、S3に保存した個人情報が漏れた

SSRFをうけた

XXE、SSRF、安全でないデシリアライゼーション入門でも同じ話をされていたkadoyau.icon

オニギリペイの対策

Apacheの設定を変更し、オープンリバースプロキシ状態を解消した

SSRFの対策はむずい

iptablesをつかって169.254.169.254へのアクセスをネットワーク的に遮断する

Amazonのマニュアルもこうなっている

p.54 IMDSでの対策も入った

p. 56 どうすればよかったのか？

徳丸本は機能仕様や実装設計を解説

もう少し上位での対応もする必要がある

企画時

リーガルチェック

監督官庁に相談

景品表示法には相談窓口がある

教科書的な方法4つ

本にかいてあることをやっとく

専門家に見てもらう

たいへん

上の3つの組み合わせ

1やって漏れたら3やるのがよくある

業界のガイドライン

忖度も必要になる

割賦販売法、イケてないけど従う必要あり

p.66

発注がセキュリティを左右する

RFPをつくって見積もりをもらう

できるだけ検討事項を盛り込んでいく

書いてないと機能追加（=追加コスト）になる

LASDEC モデルプラン

高木浩光＋徳丸浩

セキュリティ保証期間を設けた（発案高木）

4年前に作ったら開発者からは評判が悪かった

4件、2社はけんもほろろ。1社は「これふつうにやってるんで」

最近似たような判決が出始めていてこれに準拠したほうがよかったというのがある

p. 74 Agileの場合は？

業務フロー図にツッコミを入れるというやり方

そもそも業務フロー図ない

ツッコミには知識と経験が必要

ツッコミをまとめる

p.79 良い資料ないですか？

OWASPのやつは抽象的で使いづらい

IPAのIoT向けのガイドラインはけっこういいらしい

p.82 インシデント対応

発注者ができることはあまりないが…

脅威分析は無理だろうと思っていた。徳丸本よめばいいようにしていた

カバーしきれなくなった(のでこういう発表をしている