Upgrade to Pro — share decks privately, control downloads, hide ads and more …

web-secure-phpcon2020

Akira Morikawa
December 12, 2020

 web-secure-phpcon2020

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

Akira Morikawa

December 12, 2020
Tweet

More Decks by Akira Morikawa

Other Decks in Technology

Transcript

  1. Akira Morikawa | ariaki GM of Devevelopment Division // MyAnimeList

    Co.,Ltd. Tech Lead // MEDIADO Co.,Ltd. @ariaki4dev 3
  2. 未知を観測可能にするとは • 構造的未知 ◦ プログラムやデータなどの構造 ◦ バックアップやインフラなどの要件、など • 組織的未知 ◦

    開発・運営・CSなどの体制 ◦ 規約やポリシーなどの方針、など • 状態的未知 ◦ 利用者がおかれている状況や状態 ◦ 利用者が次に選択できる行動、など 難 易 11
  3. 主なアカウント攻撃 // フィッシング 起点となりやすいメールの信頼性をあげる ✅ SPF / DKIMなどのドメイン認証 ✅ DNS逆引きレコードを設定する

    ✅ バウンスレート/エラーレートを下げる ✅ 重要なメールにリンクをつけない ✅ メールの送信条件や内容を周知する ✅ お問い合わせなど自動応答メールに本文を記載しない 21
  4. Webサイトの基本的なセキュリティ対策をしっかり行う ✅ 入出力データを適切に処理する ✅ セキュリティヘッダーによる制御(参考:OWASP Security Header Project) ✅ リンクタグの

    rel=”noopener” オプション(参考:MDN Web Docs) ✅ XSS / CSRF などへの基本対策を行う 主なアカウント攻撃 // インジェクション 23
  5. その他に考えるべきことの例 ✅ 平文通信を使っていないか ✅ 適切量のログ出力しているか ✅ 入力値をログ出力していないか ✅ ネットワークは多層化されているか ✅

    DBに外部から接続させていないか ✅ CDNによって別ユーザに提供されないか ✅ 改ざん対策はなされているか ✅ 内部犯行対策はなされているか ✅ セッション有効期間は適切か など ✅ セッションハイジャック対策 ✅ セッションフィーセクション対策 ✅ 暗号アルゴリズム・強度・暗号利用モード ✅ ハッシュアルゴリズム・ソルト・ストレッチ ✅ 攻撃者にわかりやすい情報を与えていないか ✅ クッキー属性(Secure, HttpOnly) ✅ 適切なリカバリー手順はあるか ✅ SSL終端はどこか ✅ TLSバージョンは適切か ✅ HTTP/HTTPSが混在しないか 24
  6. 日本は「信頼しやすい」文化 • 日本は他国とくらべ相対的に治安がよく安全 ◦ 安全であることを前提にした仕組みが成り立っている国 ◦ 多くの人がリアルな行動において「平和ぼけ」している状態といえる ◦ Webサイトの利用方法においても同じ •

    Webサイトに対してどんな情報を躊躇なく預けられる? ◦ クレジットカード番号 ◦ 氏名・年齢・住所などの重要な情報 ◦ ニックネーム・メールアドレスなどの軽微な情報 ◦ ログインすらしたくない 26
  7. セキュリティの7要素 // ISO27002 英語 日本語 説明 Confidentiality 機密性 アクセス権限をもった人だけがアクセスできる Integrity

    完全性 情報が改ざんされない Availability 可用性 権限をもった人が必要な情報にアクセスできる Authenticity 真正性 動作の主体が本物であることを証明する Accountability 責任追跡性 主体の動作を説明できる Reliability 信頼性 主体が一貫して期待通りの動作をする Non-Repudiation 否認防止 主体の動作を後で否認させない 32
  8. 1. 資産の識別 2. セキュリティ目標の設定 3. 脅威の識別 4. 脅威の評価 5. 対策の選定

    (参考:https://www.ipa.go.jp/files/000046476.pdf) 脅威分析の手順 33
  9. 脅威の評価 // DREADモデル 英語 説明 Damage Potential 潜在的な損害 Reproductivity 攻撃が成功する再現可能性

    Exploitability 攻撃に利用される可能性 Affected Users 影響を受けるユーザ規模 Discoverability 脆弱性が攻撃者に発見される可能性 DREADは脅威の頭文字 34
  10. 脅威の分析 // 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
  11. 脅威の分析 // STRIDEモデル 英語 日本語 説明 Spoofing なりすまし 他のもの・他人になりすます Tempering

    改ざん 権限なしにコードやデータを変更する Repudiation 否認 ある機能を実行していないと主張する Information Disclosure 情報漏えい 権限のないユーザにデータを見せる Denial of Service サービス妨害 正当ユーザの利用を低下・停止させる Elevation of Previlege 権限の昇格 権限なしに権限を昇格できる STRIDEは脅威の頭文字 36
  12. 脅威の分析 // STRIDEモデル DFDによるリスク分析 図 説明 S T R I

    D E 外部エンティティ ✔ ✔ プロセス ✔ ✔ ✔ ✔ ✔ ✔ データストア ✔ ✔ ✔ ✔ フロー ✔ ✔ ✔ 37
  13. 脅威の分析 // STRIDEモデル 小 中 大 簡単 Low Important Critical

    普通 Low Moderate Important 困難 Low Low Moderate 脅威のリスクを評価(例) 再現可能性 影響度 38
  14. 39 リスク対応の判断 小 大 低 高 低減 保有 移転 回避

    リスク発生時の損害の影響度 リ ス ク の 発 生 可 能 性 保有 対処せずリスクを受け入れる 低減 対処により発生可能性を下げる 移転 リスクを他社などに移転する 回避 停止または別方法に変更する
  15. CIS Controls • 最初に行うべき重要な対策を大きく20の領域に分けて示す • 3段階のレベル(Basic / Foundational / Organizational)

    • 5つの理念に基づく ◦ 攻撃から防御を学ぶ ◦ 優先順位づけ ◦ 測定とメトリクス化 ◦ 継続的な診断とリスク低減 ◦ 自動化 43
  16. セキュア標準 • コーディング標準 ◦ 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
  17. セキュリティ負債の解消事例 事例① ハッシュアルゴリズムの変更/考察 • 全パスワードをリセット可能か? ◦ サービスは何年続いているか ◦ 利用者層のリテラシーはどの程度か •

    旧パスワードを検証→新ハッシュを作って格納するか? ◦ テーブルのレコード数は何件あり、拡張可能か ◦ 変更の原因はなにで、移行期間はどの程度とれるか 52
  18. セキュリティ負債の解消事例 事例② どこまでを正規ユーザにするか/考察 • アクセス規模はどの程度か? ◦ スクレイピングのアクセス頻度は? ◦ 許容可能な負荷か? •

    歴史的経緯は? ◦ データ二次利用の実態は? ◦ 過去どの程度にわたって行われているか? • スロットリングは設定可能か? 54
  19. ⚠ 注意事項 ⚠ 1. これまで実際に遭遇した攻撃事例をご紹介します 2. 防御意識を高めるためご紹介するものです 3. 対象システムを言及しませんので、推測はしないでください 4.

    決して自身/他者の本番システムに対して試さないでください 5. 実行される場合はすべて自己責任でお願いします 6. 登壇者及びphpcon2020は実行結果について責任をもちません 57
  20. DDoS対策例 • AWS WAFのRate Limit Ruleによって対策 ◦ IPアドレスベースで5分間のアクセスを制限 ◦ 対象パスを限定

    • アクセス制限時にはボット検知(reCAPTCHA) ◦ 表示画面はCloudFrontカスタムエラーレスポンスで実現 ◦ ブロック時は403 Forbiddenになるので地味につらい ◦ API Gateway + Lambdaで検知用APIを実装 ◦ 人間と判定されたIPアドレスを一定期間ホワイトリストに追加 72
  21. 73

  22. DDoS対策例 • DDoSが発生した場合は手動(awk/sed)でアクセスログを調査 ◦ Top100 アクセス元URL ◦ Top100 アクセス元IPアドレス ◦

    アクセス元IPアドレスごとのリクエスト調査 • 対象IPアドレスを手動でブロック ◦ ほとんどが単一IPアドレスからのリクエスト過多 ◦ DDoSの場合は一時的に全体アクセスを絞る 75