Slide 1
Slide 1 text
セキュアに保つために必要な
視点
Webサイトを
ariaki ( @ariaki4dev )
Dec 12, 2020 | #phpcon2020
Slide 2
Slide 2 text
実況＆感想ツイートお待ちしてます！
#phpcon #track3
ariaki @ariaki4dev - 今
12 2k 2k
Discord → #track3-3-secure-web-service
Slide 3
Slide 3 text
Akira Morikawa | ariaki
GM of Devevelopment Division // MyAnimeList Co.,Ltd.
Tech Lead // MEDIADO Co.,Ltd.
@ariaki4dev
3
Slide 4
Slide 4 text
＼ 次回の登壇予定 ／
https://gijutsusyo.connpass.com/event/197166/
4
Slide 5
Slide 5 text
対策の観点
思考法
フレームワーク
攻撃事例
など
対策の手法
具体的な攻撃/防御手順
完全な防御策
内部不正防止策
など
話すこと 話さないこと
5
Slide 6
Slide 6 text
What is Secure ?
セキュアに保つための視点
本日のテーマ
6
Slide 7
Slide 7 text
「多くの利用者が安心できる状態」を目指す
● 安全（Secure） ： 客観的な評価指標（→犯罪など意図的なもの）
● 安心（Safe） ： 主観的な評価指標（→事故など意図的でないもの）
安全 と 安心
例）「私」が安心できる状態
7
Slide 8
Slide 8 text
安全 ＝ 許容不可能なリスク（危険）が存在しないこと
安全 ↔ 危険
危険とは（引用元：https://ja.wikipedia.org/wiki/%E5%8D%B1%E9%99%BA）
● 未来において、損害や損失が発生する可能性があること
● 最悪の場合は、そのものの存続が困難になる
8
Slide 9
Slide 9 text
安心 ＝ 自身の現在および未来に不安がないこと
安心 ↔ 不安
不安とは（引用元：https://ja.wikipedia.org/wiki/%E4%B8%8D%E5%AE%89）
● 心配に思ったり、恐怖を感じること
● 漠然と気味が悪い、よくないことが起こる感覚（予期不安）
9
Slide 10
Slide 10 text
「観測可能」になることで安心できる
未知への不安
未知 既知
人は得体の知れないものに怯える
10
から へと
Slide 11
Slide 11 text
未知を観測可能にするとは
● 構造的未知
○ プログラムやデータなどの構造
○ バックアップやインフラなどの要件、など
● 組織的未知
○ 開発・運営・CSなどの体制
○ 規約やポリシーなどの方針、など
● 状態的未知
○ 利用者がおかれている状況や状態
○ 利用者が次に選択できる行動、など
難
易
11
Slide 12
Slide 12 text
利用者の過去〜現在〜未来の状態を容易に把握できることを目指す
✅ アクティビティ履歴の表示（例：ログイン履歴、決済履歴）
✅ 異常アクティビティの通知（例：いつもと違う場所からのログイン通知）
✅ 変更内容の通知（例：パスワード変更通知、メール変更通知）
✅ 状態表示の一元化／共通化（例：マイページ、ダッシュボード）
✅ 予定されたアクションの明示（例：次回決済日、利用有効期限）
など
状態的未知の軽減
12
Slide 13
Slide 13 text
状態的未知の事例
Slide 14
Slide 14 text
アカウントセキュリティ
事例をもとに考えてみよう
1. どのようにすれば発生しなかったのか
2. どのようにすれば被害を最小限に抑えられたのか
14
Slide 15
Slide 15 text
アカウントセキュリティ
事例① 標的型攻撃
攻撃者が元カレのアカウントをハックし、個人情報を変更した。
● ユーザ名を”HeartBreaker”に、誕生日を自分のものにした
● 元カレは推測しやすい情報をパスワードに使用していた
15
Slide 16
Slide 16 text
アカウントセキュリティ
事例② 偶然の攻撃
クラスメートが偶然アカウントを乗っ取り、コンテンツを購入した。
● 利用者は学校の共用PCでサイトを使ってアクセスしていた
● 攻撃者は自身のアカウントと思い込み、購入を複数回繰り返した
16
Slide 17
Slide 17 text
標的型攻撃
偶然の攻撃
は身近にある
17
Slide 18
Slide 18 text
アカウント攻撃の種類
1. 標的型攻撃
2. 偶然の攻撃
3. フィッシング
4. リスト攻撃
5. インジェクション
など
18
Slide 19
Slide 19 text
ログインの複雑さを担保する
✅ 複雑なパスワードを強制する
✅ FIDO（二要素認証など）を設定する
✅ 重要情報の変更結果を通知する
✅ 大量処理を検知する
主なアカウント攻撃 // 標的型攻撃
19
Slide 20
Slide 20 text
主なアカウント攻撃 // 偶然の攻撃
誤操作の可能性を減少させる
✅ セッション生存期間を短くする
✅ 操作の重要度に応じて定期再認証を求める
✅ 購入前にアカウント情報を表示する
✅ 購入完了を通知する
20
Slide 21
Slide 21 text
主なアカウント攻撃 // フィッシング
起点となりやすいメールの信頼性をあげる
✅ SPF / DKIMなどのドメイン認証
✅ DNS逆引きレコードを設定する
✅ バウンスレート／エラーレートを下げる
✅ 重要なメールにリンクをつけない
✅ メールの送信条件や内容を周知する
✅ お問い合わせなど自動応答メールに本文を記載しない
21
Slide 22
Slide 22 text
主なアカウント攻撃 // リスト攻撃
ログイン時の本人性検証を強化する
✅ ボットによるログイン試行を拒否する
✅ 普段とは異なるアクティビティを拒否する
✅ 反復処理をブロックする（※成否にかかわらず行う）
○ アカウント単位
○ IPアドレス単位
○ サイト全体
22
Slide 23
Slide 23 text
Webサイトの基本的なセキュリティ対策をしっかり行う
✅ 入出力データを適切に処理する
✅ セキュリティヘッダーによる制御（参考：OWASP Security Header Project）
✅ リンクタグの rel=”noopener” オプション（参考：MDN Web Docs）
✅ XSS / CSRF などへの基本対策を行う
主なアカウント攻撃 // インジェクション
23
Slide 24
Slide 24 text
その他に考えるべきことの例
✅ 平文通信を使っていないか
✅ 適切量のログ出力しているか
✅ 入力値をログ出力していないか
✅ ネットワークは多層化されているか
✅ DBに外部から接続させていないか
✅ CDNによって別ユーザに提供されないか
✅ 改ざん対策はなされているか
✅ 内部犯行対策はなされているか
✅ セッション有効期間は適切か
など
✅ セッションハイジャック対策
✅ セッションフィーセクション対策
✅ 暗号アルゴリズム・強度・暗号利用モード
✅ ハッシュアルゴリズム・ソルト・ストレッチ
✅ 攻撃者にわかりやすい情報を与えていないか
✅ クッキー属性（Secure, HttpOnly）
✅ 適切なリカバリー手順はあるか
✅ SSL終端はどこか
✅ TLSバージョンは適切か
✅ HTTP/HTTPSが混在しないか 24
Slide 25
Slide 25 text
信頼境界
コンポーネント
● 信頼境界を超えるすべての入力データを検証する
○ エスケープ・エスケープ不要なAPI利用・バリデーション
● 信頼境界を超えるすべての出力データを無害化する
OS
ミドルウェア
コンポーネント
外部システム
ユーザ入力
コンポーネント
25
Slide 26
Slide 26 text
日本は「信頼しやすい」文化
● 日本は他国とくらべ相対的に治安がよく安全
○ 安全であることを前提にした仕組みが成り立っている国
○ 多くの人がリアルな行動において「平和ぼけ」している状態といえる
○ Webサイトの利用方法においても同じ
● Webサイトに対してどんな情報を躊躇なく預けられる？
○ クレジットカード番号
○ 氏名・年齢・住所などの重要な情報
○ ニックネーム・メールアドレスなどの軽微な情報
○ ログインすらしたくない 26
Slide 27
Slide 27 text
利用者に安心（信頼）されなければ
サービスは成り立たない
27
Slide 28
Slide 28 text
安心 安全
28
Slide 29
Slide 29 text
安心できない状況を発生させないことが重要
✅ 安全/安心対策によって利便性が過度に阻害されない
✅ 次に行うべきアクションに迷わない
✅ ユーザに不利益な設計によって収益を確保しない
✅ 丁寧や説明やチュートリアルが準備されている
✅ センシティブな情報の表示を制御できる
✅ サービスが終了しても情報資産を残したい
など
安心のために
29
Slide 30
Slide 30 text
次に、サービス提供者からみて
安心な運用できていますか？
30
Slide 31
Slide 31 text
セキュリティ対策の基礎知識
Slide 32
Slide 32 text
セキュリティの7要素 // ISO27002
英語 日本語 説明
Confidentiality 機密性 アクセス権限をもった人だけがアクセスできる
Integrity 完全性 情報が改ざんされない
Availability 可用性 権限をもった人が必要な情報にアクセスできる
Authenticity 真正性 動作の主体が本物であることを証明する
Accountability 責任追跡性 主体の動作を説明できる
Reliability 信頼性 主体が一貫して期待通りの動作をする
Non-Repudiation 否認防止 主体の動作を後で否認させない
32
Slide 33
Slide 33 text
1. 資産の識別
2. セキュリティ目標の設定
3. 脅威の識別
4. 脅威の評価
5. 対策の選定
（参考：https://www.ipa.go.jp/files/000046476.pdf）
脅威分析の手順
33
Slide 34
Slide 34 text
脅威の評価 // DREADモデル
英語 説明
Damage Potential 潜在的な損害
Reproductivity 攻撃が成功する再現可能性
Exploitability 攻撃に利用される可能性
Affected Users 影響を受けるユーザ規模
Discoverability 脆弱性が攻撃者に発見される可能性
DREADは脅威の頭文字
34
Slide 35
Slide 35 text
脅威の分析 // STRIDEモデル
Microsoftによって提唱された脅威分析モデル
1. DFDを作成する
2. 信頼境界を設定する
3. 脅威の一覧を作成する（STRIDE）
4. 脅威のリスクを評価する
5. 脅威の軽減策を立案・作成する
6. 確認する
（参考：https://www.microsoft.com/en-us/securityengineering/sdl）
（事例：https://tech.plaid.co.jp/threat-analysis/）
35
Slide 36
Slide 36 text
脅威の分析 // STRIDEモデル
英語 日本語 説明
Spoofing なりすまし 他のもの・他人になりすます
Tempering 改ざん 権限なしにコードやデータを変更する
Repudiation 否認 ある機能を実行していないと主張する
Information Disclosure 情報漏えい 権限のないユーザにデータを見せる
Denial of Service サービス妨害 正当ユーザの利用を低下・停止させる
Elevation of Previlege 権限の昇格 権限なしに権限を昇格できる
STRIDEは脅威の頭文字
36
Slide 37
Slide 37 text
脅威の分析 // STRIDEモデル
DFDによるリスク分析
図 説明 S T R I D E
外部エンティティ ✔ ✔
プロセス ✔ ✔ ✔ ✔ ✔ ✔
データストア ✔ ✔ ✔ ✔
フロー ✔ ✔ ✔
37
Slide 38
Slide 38 text
脅威の分析 // STRIDEモデル
小 中 大
簡単 Low Important Critical
普通 Low Moderate Important
困難 Low Low Moderate
脅威のリスクを評価（例）
再現可能性
影響度
38
Slide 39
Slide 39 text
39
リスク対応の判断
小 大
低
高
低減
保有 移転
回避
リスク発生時の損害の影響度
リ
ス
ク
の
発
生
可
能
性
保有
対処せずリスクを受け入れる
低減
対処により発生可能性を下げる
移転
リスクを他社などに移転する
回避
停止または別方法に変更する
Slide 40
Slide 40 text
SANS Incident Response
インシデント発生時の対応方針を6ステップにまとめている
識別
Identification
封じ込め
Containment
根絶
Eradication
回復
Recovery
教訓
Learned
準備
Preparation
40
Slide 41
Slide 41 text
NIST CSF ISMS
CIS Controls
PCI DSS
GDPR
攻撃対策 不正対策
システム
プロセス
41
Slide 42
Slide 42 text
NIST Cyber Security Framework
● セキュリティに関する指針や管理手法を示すフレームワーク
● セキュリティへの取り組みや対応状況を説明しやすい
● コア（5/23要素）・ティア（4段階）・プロファイル（As-is, To-be）
Tier 1: Partial
Tier 2: Risk Informed
Tier 3: Repeatable
Tier 4: Adoptable
42
Slide 43
Slide 43 text
CIS Controls
● 最初に行うべき重要な対策を大きく20の領域に分けて示す
● 3段階のレベル（Basic / Foundational / Organizational）
● 5つの理念に基づく
○ 攻撃から防御を学ぶ
○ 優先順位づけ
○ 測定とメトリクス化
○ 継続的な診断とリスク低減
○ 自動化
43
Slide 44
Slide 44 text
アセスメント
セキュリティ脅威へのアセスメントはいつやるか
● 大規模なもの
○ 初期リリース時
○ 大規模エンハンスメント時
○ 定期的（たとえば、年１回）
● 継続的なもの
○ CI/CDで常時実行
○ 毎週/毎月の定期タスクとして実施
44
Slide 45
Slide 45 text
アセスメント // 脆弱性テスト
脆弱性テストを自身で行うためのツール
● OWASP ZAP
● Nikto
● Burp Suite
● Nessus
● VAddy ← PHPCON 2020 SPONSOR
45
Slide 46
Slide 46 text
セキュア標準
● コーディング標準
○ CERT - Top 10 Secure Coding Practices / 日本語訳
○ OWASP - Secure Coding Practices
● セキュリティ動向
○ CWE/SANS - Top 25 Software Errors / 日本語訳
○ OWASP - Top 10 (2017)
● クラウドベストプラクティス
○ AWS Security Best Practices
○ Google Cloud Security Best Practices
○ Microsoft Azure Security Best Practices
46
Slide 47
Slide 47 text
セキュリティ負債
セキュリティ負債について定期的な検討と対策を行う
● 危殆化していないか？
○ 暗号アルゴリズム・ハッシュアルゴリズム
○ 古いバージョンのミドルウェア・プロトコル
● 対応方針は問題ないか？
○ IPアドレスベースでのアクセス制限
○ パスワードの定期変更
など
47
Slide 48
Slide 48 text
PHP 5.x
PHP 7.0-7.2
PHP 7.3-
https://w3techs.com/technologies/details/pl-php 48
Slide 49
Slide 49 text
https://www.ssllabs.com/ssltest/analyze.html?d=phpcon.php.gr.jp 49
Slide 50
Slide 50 text
セキュリティ負債の解消事例
Slide 51
Slide 51 text
セキュリティ負債の解消事例
事例① ハッシュアルゴリズムの変更
あるシステムでパスワード格納時のハッシュアルゴリズムを変更したい。
どのような対策を講じるべきか。
Users
id: int
email: varchar(255)
password: varchar(255)
:
51
Slide 52
Slide 52 text
セキュリティ負債の解消事例
事例① ハッシュアルゴリズムの変更／考察
● 全パスワードをリセット可能か？
○ サービスは何年続いているか
○ 利用者層のリテラシーはどの程度か
● 旧パスワードを検証→新ハッシュを作って格納するか？
○ テーブルのレコード数は何件あり、拡張可能か
○ 変更の原因はなにで、移行期間はどの程度とれるか
52
Slide 53
Slide 53 text
セキュリティ負債の解消事例
事例② どこまでを正規ユーザにするか
あるシステムでは通常ユーザ以外のアクセスが多く発生している。
どこまでスクレイピングなどのアクセスを許容するべきか。
53
Slide 54
Slide 54 text
セキュリティ負債の解消事例
事例② どこまでを正規ユーザにするか／考察
● アクセス規模はどの程度か？
○ スクレイピングのアクセス頻度は？
○ 許容可能な負荷か？
● 歴史的経緯は？
○ データ二次利用の実態は？
○ 過去どの程度にわたって行われているか？
● スロットリングは設定可能か？ 54
Slide 55
Slide 55 text
負債返却の方法はきちんと議論しなければならない
✅ 利用者の平均的リテラシーは？
✅ 歴史的経緯や発生状況は？
✅ 負債の返却にかけるコストや時間は？
✅ 対策後のサポート体制・評価体制は？
55
Slide 56
Slide 56 text
過去に受けた攻撃事例
Slide 57
Slide 57 text
⚠ 注意事項 ⚠
1. これまで実際に遭遇した攻撃事例をご紹介します
2. 防御意識を高めるためご紹介するものです
3. 対象システムを言及しませんので、推測はしないでください
4. 決して自身/他者の本番システムに対して試さないでください
5. 実行される場合はすべて自己責任でお願いします
6. 登壇者及びphpcon2020は実行結果について責任をもちません
57
Slide 58
Slide 58 text
迷惑投稿／スパム
攻撃内容
攻撃者は、掲示板に外部有害サイトリンクの投稿を繰り返した。
対応策
● 入力フレーズによって自動BANする
● 投稿回数や条件によって自動BANする
58
Slide 59
Slide 59 text
アカウント量産
攻撃内容
攻撃者は、アカウント生成スクリプトを用いてアカウントを大量作成した。
対応策
● CAPTCHAを使ってボット判定する
● 同一IPアドレスから作成可能なアカウント数を制限する
● アカウント作成直後にとれる行動を制限する
● 休眠アカウントの行動を制限する
59
Slide 60
Slide 60 text
URL推測
攻撃内容
攻撃者は、セール告知URLから推測した商品URLにアクセスし、
販売開始前に商品を購入した。
対応策
● 商品の販売期間を設定する
● 告知URLから商品URLを推測できないようにする
60
Slide 61
Slide 61 text
URL総当たり
攻撃内容
攻撃者は、ランダムに生成されるURLに総当たりでアクセスし、
許可されていないコンテンツを閲覧した。
対応策
● リクエスト時に認証する
● アクセス回数に閾値を設ける
61
Slide 62
Slide 62 text
署名検証の不備
攻撃内容
攻撃者は、加工された決済トランザクション情報を繰り返し送信し、
複数回の決済を成功させた。
対応策
● 一意のトランザクションIDによって重複を防ぐ
● 決済トランザクションに署名を設定、検証する
62
Slide 63
Slide 63 text
高圧縮ZIP爆弾
攻撃内容
攻撃者は、加工された特殊なZIPファイルをサーバに送信し、
展開によってディスクスペースを消費しつくした。
（参考：https://www.bamsoftware.com/hacks/zipbomb/）
対応策
● 最新版のunzipソフトウェアに更新する
● 最新版のアンチウイルスソフトで検知する
● 展開前にファイル構造やファイルサイズを検証する
● 一時領域にファイルを展開する
63
Slide 64
Slide 64 text
ImageMagickリソース消費
攻撃内容
攻撃者は、解像度の常に大きなJPEG画像をアップロードし、
ImageMagickでの変換時にリソースを消費しつくした。
（参考：JPEG pixel flood / GIF flooding / PNG compression）
対応策
● ImageMagickが利用可能なリソースを制限する
64
Slide 65
Slide 65 text
PHP unserialize
攻撃内容
攻撃者は、悪意あるコードをクッキーに設定し、デシリアライズによって
意図しないコードを実行した。（参考：徳丸浩の日記）
対応策
● 入力値のデシリアライズをやめる
● 入力値をバリデーションする
65
Slide 66
Slide 66 text
攻撃内容
攻撃者は、クッキー値を加工してアクセスし、誤ったパース処理によって
権限のないコンテンツが表示された。（参考：cls::blog）
対応策
● parse_str() 関数の第二引数を設定する
● parse_str() を使わない
PHP parse_str
66
Slide 67
Slide 67 text
攻撃内容
攻撃者は、プロバイダのDNSサーバ汚染によってアクセスを誘導し、
過負荷によってサービス提供不能にされた。
対応策
● 該当IPアドレス範囲のアクセス一時遮断
DNSポイゾニング（DDoS）
67
Slide 68
Slide 68 text
攻撃内容
攻撃者は、加工したTCP SYNパケットを大量に送信することによって、
conntrackが枯渇しサーバが接続不能になった。
対応策
● kernel.net.ipv4パラメータのチューニング
● 該当IPアドレス帯域の一時遮断
SYN Flood
68
Slide 69
Slide 69 text
意外といろいろ受けます！
69
Slide 70
Slide 70 text
✅ 攻撃を受けるのは有名サービスだけじゃない
✅ フレームワークなど既知の攻撃以外にも試行錯誤される
✅ 入力値のバリデーションで多くの攻撃を防げる
✅ 流行りの攻撃はだいたい受けるので傾向を知ろう
✅ 開発者リテラシーも重要になってきている
✅ とにかくログを丁寧に設計しよう
70
Slide 71
Slide 71 text
DDoS対策例
Slide 72
Slide 72 text
DDoS対策例
● AWS WAFのRate Limit Ruleによって対策
○ IPアドレスベースで5分間のアクセスを制限
○ 対象パスを限定
● アクセス制限時にはボット検知（reCAPTCHA）
○ 表示画面はCloudFrontカスタムエラーレスポンスで実現
○ ブロック時は403 Forbiddenになるので地味につらい
○ API Gateway + Lambdaで検知用APIを実装
○ 人間と判定されたIPアドレスを一定期間ホワイトリストに追加
72
Slide 73
Slide 73 text
73
Slide 74
Slide 74 text
DDoS対策例
All Blocked Request
74
Slide 75
Slide 75 text
DDoS対策例
● DDoSが発生した場合は手動（awk/sed）でアクセスログを調査
○ Top100 アクセス元URL
○ Top100 アクセス元IPアドレス
○ アクセス元IPアドレスごとのリクエスト調査
● 対象IPアドレスを手動でブロック
○ ほとんどが単一IPアドレスからのリクエスト過多
○ DDoSの場合は一時的に全体アクセスを絞る
75
Slide 76
Slide 76 text
DDoS対策例
● アクセス負荷の多くは遠慮のないスクレイピング行為
● 意図的なDDoSは理由を推測できるものがほとんど
● 攻撃の多くは負荷試験用ツール/サービスが使われている
● 攻撃時は重いURLから狙われる（たとえば検索系）
● コロナの影響で世界的にDDoSが増加傾向にある（参考：ITMedia）
76
Slide 77
Slide 77 text
まとめ
Slide 78
Slide 78 text
1. シロアリのいる家
2. リスク↔コスト
3. セキュリティ↔利便性
4. 対岸の火事ではない
78
Slide 79
Slide 79 text
宣伝
Slide 80
Slide 80 text
No content
Slide 81
Slide 81 text
● アニメ・マンガに関する世界最大規模のユーザコミュニティ
● 2005年に誕生して16年続いている
● 20万件を超えるアニメ・マンガなどの情報や口コミが投稿される
● 海外のアニメファンにとって重要な情報入手経路
● 月間約2億PV・約1,300万MAU
Slide 82
Slide 82 text
No content
Slide 83
Slide 83 text
We are Hiring !!!
● プロジェクトマネージャー
● リードエンジニア（テックリード）
● リードインフラエンジニア（SRE）
@ariaki4dev までご連絡ください！