web-secure-phpcon2020

Webサービスをセキュアに保つために必要な視点
https://fortee.jp/phpcon-2020/proposal/cd82aea5-dc1a-4b20-a176-f9d8db222718

Transcript

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