$30 off During Our Annual Pro Sale. View Details »

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. セキュアに保つために必要な
    視点
    Webサイトを
    ariaki ( @ariaki4dev )
    Dec 12, 2020 | #phpcon2020

    View Slide

  2. 実況&感想ツイートお待ちしてます!
    #phpcon #track3
    ariaki @ariaki4dev - 今
    12 2k 2k
    Discord → #track3-3-secure-web-service

    View Slide

  3. Akira Morikawa | ariaki
    GM of Devevelopment Division // MyAnimeList Co.,Ltd.
    Tech Lead // MEDIADO Co.,Ltd.
    @ariaki4dev
    3

    View Slide

  4. \ 次回の登壇予定 /
    https://gijutsusyo.connpass.com/event/197166/
    4

    View Slide

  5. 対策の観点
    思考法
    フレームワーク
    攻撃事例
    など
    対策の手法
    具体的な攻撃/防御手順
    完全な防御策
    内部不正防止策
    など
    話すこと 話さないこと
    5

    View Slide

  6. What is Secure ?
    セキュアに保つための視点
    本日のテーマ
    6

    View Slide

  7. 「多くの利用者が安心できる状態」を目指す
    ● 安全(Secure) : 客観的な評価指標(→犯罪など意図的なもの)
    ● 安心(Safe) : 主観的な評価指標(→事故など意図的でないもの)
    安全 と 安心
    例)「私」が安心できる状態
    7

    View Slide

  8. 安全 = 許容不可能なリスク(危険)が存在しないこと
    安全 ↔ 危険
    危険とは(引用元:https://ja.wikipedia.org/wiki/%E5%8D%B1%E9%99%BA)
    ● 未来において、損害や損失が発生する可能性があること
    ● 最悪の場合は、そのものの存続が困難になる
    8

    View Slide

  9. 安心 = 自身の現在および未来に不安がないこと
    安心 ↔ 不安
    不安とは(引用元:https://ja.wikipedia.org/wiki/%E4%B8%8D%E5%AE%89)
    ● 心配に思ったり、恐怖を感じること
    ● 漠然と気味が悪い、よくないことが起こる感覚(予期不安)
    9

    View Slide

  10. 「観測可能」になることで安心できる
    未知への不安
    未知 既知
    人は得体の知れないものに怯える
    10
    から へと

    View Slide

  11. 未知を観測可能にするとは
    ● 構造的未知
    ○ プログラムやデータなどの構造
    ○ バックアップやインフラなどの要件、など
    ● 組織的未知
    ○ 開発・運営・CSなどの体制
    ○ 規約やポリシーなどの方針、など
    ● 状態的未知
    ○ 利用者がおかれている状況や状態
    ○ 利用者が次に選択できる行動、など


    11

    View Slide

  12. 利用者の過去〜現在〜未来の状態を容易に把握できることを目指す
    ✅ アクティビティ履歴の表示(例:ログイン履歴、決済履歴)
    ✅ 異常アクティビティの通知(例:いつもと違う場所からのログイン通知)
    ✅ 変更内容の通知(例:パスワード変更通知、メール変更通知)
    ✅ 状態表示の一元化/共通化(例:マイページ、ダッシュボード)
    ✅ 予定されたアクションの明示(例:次回決済日、利用有効期限)
    など
    状態的未知の軽減
    12

    View Slide

  13. 状態的未知の事例

    View Slide

  14. アカウントセキュリティ
    事例をもとに考えてみよう
    1. どのようにすれば発生しなかったのか
    2. どのようにすれば被害を最小限に抑えられたのか
    14

    View Slide

  15. アカウントセキュリティ
    事例① 標的型攻撃
    攻撃者が元カレのアカウントをハックし、個人情報を変更した。
    ● ユーザ名を”HeartBreaker”に、誕生日を自分のものにした
    ● 元カレは推測しやすい情報をパスワードに使用していた
    15

    View Slide

  16. アカウントセキュリティ
    事例② 偶然の攻撃
    クラスメートが偶然アカウントを乗っ取り、コンテンツを購入した。
    ● 利用者は学校の共用PCでサイトを使ってアクセスしていた
    ● 攻撃者は自身のアカウントと思い込み、購入を複数回繰り返した
    16

    View Slide

  17. 標的型攻撃
    偶然の攻撃
    は身近にある
    17

    View Slide

  18. アカウント攻撃の種類
    1. 標的型攻撃
    2. 偶然の攻撃
    3. フィッシング
    4. リスト攻撃
    5. インジェクション
    など
    18

    View Slide

  19. ログインの複雑さを担保する
    ✅ 複雑なパスワードを強制する
    ✅ FIDO(二要素認証など)を設定する
    ✅ 重要情報の変更結果を通知する
    ✅ 大量処理を検知する
    主なアカウント攻撃 // 標的型攻撃
    19

    View Slide

  20. 主なアカウント攻撃 // 偶然の攻撃
    誤操作の可能性を減少させる
    ✅ セッション生存期間を短くする
    ✅ 操作の重要度に応じて定期再認証を求める
    ✅ 購入前にアカウント情報を表示する
    ✅ 購入完了を通知する
    20

    View Slide

  21. 主なアカウント攻撃 // フィッシング
    起点となりやすいメールの信頼性をあげる
    ✅ SPF / DKIMなどのドメイン認証
    ✅ DNS逆引きレコードを設定する
    ✅ バウンスレート/エラーレートを下げる
    ✅ 重要なメールにリンクをつけない
    ✅ メールの送信条件や内容を周知する
    ✅ お問い合わせなど自動応答メールに本文を記載しない
    21

    View Slide

  22. 主なアカウント攻撃 // リスト攻撃
    ログイン時の本人性検証を強化する
    ✅ ボットによるログイン試行を拒否する
    ✅ 普段とは異なるアクティビティを拒否する
    ✅ 反復処理をブロックする(※成否にかかわらず行う)
    ○ アカウント単位
    ○ IPアドレス単位
    ○ サイト全体
    22

    View Slide

  23. Webサイトの基本的なセキュリティ対策をしっかり行う
    ✅ 入出力データを適切に処理する
    ✅ セキュリティヘッダーによる制御(参考:OWASP Security Header Project)
    ✅ リンクタグの rel=”noopener” オプション(参考:MDN Web Docs)
    ✅ XSS / CSRF などへの基本対策を行う
    主なアカウント攻撃 // インジェクション
    23

    View Slide

  24. その他に考えるべきことの例
    ✅ 平文通信を使っていないか
    ✅ 適切量のログ出力しているか
    ✅ 入力値をログ出力していないか
    ✅ ネットワークは多層化されているか
    ✅ DBに外部から接続させていないか
    ✅ CDNによって別ユーザに提供されないか
    ✅ 改ざん対策はなされているか
    ✅ 内部犯行対策はなされているか
    ✅ セッション有効期間は適切か
    など
    ✅ セッションハイジャック対策
    ✅ セッションフィーセクション対策
    ✅ 暗号アルゴリズム・強度・暗号利用モード
    ✅ ハッシュアルゴリズム・ソルト・ストレッチ
    ✅ 攻撃者にわかりやすい情報を与えていないか
    ✅ クッキー属性(Secure, HttpOnly)
    ✅ 適切なリカバリー手順はあるか
    ✅ SSL終端はどこか
    ✅ TLSバージョンは適切か
    ✅ HTTP/HTTPSが混在しないか 24

    View Slide

  25. 信頼境界
    コンポーネント
    ● 信頼境界を超えるすべての入力データを検証する
    ○ エスケープ・エスケープ不要なAPI利用・バリデーション
    ● 信頼境界を超えるすべての出力データを無害化する
    OS
    ミドルウェア
    コンポーネント
    外部システム
    ユーザ入力
    コンポーネント
    25

    View Slide

  26. 日本は「信頼しやすい」文化
    ● 日本は他国とくらべ相対的に治安がよく安全
    ○ 安全であることを前提にした仕組みが成り立っている国
    ○ 多くの人がリアルな行動において「平和ぼけ」している状態といえる
    ○ Webサイトの利用方法においても同じ
    ● Webサイトに対してどんな情報を躊躇なく預けられる?
    ○ クレジットカード番号
    ○ 氏名・年齢・住所などの重要な情報
    ○ ニックネーム・メールアドレスなどの軽微な情報
    ○ ログインすらしたくない 26

    View Slide

  27. 利用者に安心(信頼)されなければ
    サービスは成り立たない
    27

    View Slide

  28. 安心 安全
    28

    View Slide

  29. 安心できない状況を発生させないことが重要
    ✅ 安全/安心対策によって利便性が過度に阻害されない
    ✅ 次に行うべきアクションに迷わない
    ✅ ユーザに不利益な設計によって収益を確保しない
    ✅ 丁寧や説明やチュートリアルが準備されている
    ✅ センシティブな情報の表示を制御できる
    ✅ サービスが終了しても情報資産を残したい
    など
    安心のために
    29

    View Slide

  30. 次に、サービス提供者からみて
    安心な運用できていますか?
    30

    View Slide

  31. セキュリティ対策の基礎知識

    View Slide

  32. セキュリティの7要素 // ISO27002
    英語 日本語 説明
    Confidentiality 機密性 アクセス権限をもった人だけがアクセスできる
    Integrity 完全性 情報が改ざんされない
    Availability 可用性 権限をもった人が必要な情報にアクセスできる
    Authenticity 真正性 動作の主体が本物であることを証明する
    Accountability 責任追跡性 主体の動作を説明できる
    Reliability 信頼性 主体が一貫して期待通りの動作をする
    Non-Repudiation 否認防止 主体の動作を後で否認させない
    32

    View Slide

  33. 1. 資産の識別
    2. セキュリティ目標の設定
    3. 脅威の識別
    4. 脅威の評価
    5. 対策の選定
    (参考:https://www.ipa.go.jp/files/000046476.pdf)
    脅威分析の手順
    33

    View Slide

  34. 脅威の評価 // DREADモデル
    英語 説明
    Damage Potential 潜在的な損害
    Reproductivity 攻撃が成功する再現可能性
    Exploitability 攻撃に利用される可能性
    Affected Users 影響を受けるユーザ規模
    Discoverability 脆弱性が攻撃者に発見される可能性
    DREADは脅威の頭文字
    34

    View Slide

  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

    View Slide

  36. 脅威の分析 // STRIDEモデル
    英語 日本語 説明
    Spoofing なりすまし 他のもの・他人になりすます
    Tempering 改ざん 権限なしにコードやデータを変更する
    Repudiation 否認 ある機能を実行していないと主張する
    Information Disclosure 情報漏えい 権限のないユーザにデータを見せる
    Denial of Service サービス妨害 正当ユーザの利用を低下・停止させる
    Elevation of Previlege 権限の昇格 権限なしに権限を昇格できる
    STRIDEは脅威の頭文字
    36

    View Slide

  37. 脅威の分析 // STRIDEモデル
    DFDによるリスク分析
    図 説明 S T R I D E
    外部エンティティ ✔ ✔
    プロセス ✔ ✔ ✔ ✔ ✔ ✔
    データストア ✔ ✔ ✔ ✔
    フロー ✔ ✔ ✔
    37

    View Slide

  38. 脅威の分析 // STRIDEモデル
    小 中 大
    簡単 Low Important Critical
    普通 Low Moderate Important
    困難 Low Low Moderate
    脅威のリスクを評価(例)
    再現可能性
    影響度
    38

    View Slide

  39. 39
    リスク対応の判断
    小 大


    低減
    保有 移転
    回避
    リスク発生時の損害の影響度









    保有
    対処せずリスクを受け入れる
    低減
    対処により発生可能性を下げる
    移転
    リスクを他社などに移転する
    回避
    停止または別方法に変更する

    View Slide

  40. SANS Incident Response
    インシデント発生時の対応方針を6ステップにまとめている
    識別
    Identification
    封じ込め
    Containment
    根絶
    Eradication
    回復
    Recovery
    教訓
    Learned
    準備
    Preparation
    40

    View Slide

  41. NIST CSF ISMS
    CIS Controls
    PCI DSS
    GDPR
    攻撃対策 不正対策
    システム
    プロセス
    41

    View Slide

  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

    View Slide

  43. CIS Controls
    ● 最初に行うべき重要な対策を大きく20の領域に分けて示す
    ● 3段階のレベル(Basic / Foundational / Organizational)
    ● 5つの理念に基づく
    ○ 攻撃から防御を学ぶ
    ○ 優先順位づけ
    ○ 測定とメトリクス化
    ○ 継続的な診断とリスク低減
    ○ 自動化
    43

    View Slide

  44. アセスメント
    セキュリティ脅威へのアセスメントはいつやるか
    ● 大規模なもの
    ○ 初期リリース時
    ○ 大規模エンハンスメント時
    ○ 定期的(たとえば、年1回)
    ● 継続的なもの
    ○ CI/CDで常時実行
    ○ 毎週/毎月の定期タスクとして実施
    44

    View Slide

  45. アセスメント // 脆弱性テスト
    脆弱性テストを自身で行うためのツール
    ● OWASP ZAP
    ● Nikto
    ● Burp Suite
    ● Nessus
    ● VAddy ← PHPCON 2020 SPONSOR
    45

    View Slide

  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

    View Slide

  47. セキュリティ負債
    セキュリティ負債について定期的な検討と対策を行う
    ● 危殆化していないか?
    ○ 暗号アルゴリズム・ハッシュアルゴリズム
    ○ 古いバージョンのミドルウェア・プロトコル
    ● 対応方針は問題ないか?
    ○ IPアドレスベースでのアクセス制限
    ○ パスワードの定期変更
    など
    47

    View Slide

  48. PHP 5.x
    PHP 7.0-7.2
    PHP 7.3-
    https://w3techs.com/technologies/details/pl-php 48

    View Slide



  49. https://www.ssllabs.com/ssltest/analyze.html?d=phpcon.php.gr.jp 49

    View Slide

  50. セキュリティ負債の解消事例

    View Slide

  51. セキュリティ負債の解消事例
    事例① ハッシュアルゴリズムの変更
    あるシステムでパスワード格納時のハッシュアルゴリズムを変更したい。
    どのような対策を講じるべきか。
    Users
    id: int
    email: varchar(255)
    password: varchar(255)
    :
    51

    View Slide

  52. セキュリティ負債の解消事例
    事例① ハッシュアルゴリズムの変更/考察
    ● 全パスワードをリセット可能か?
    ○ サービスは何年続いているか
    ○ 利用者層のリテラシーはどの程度か
    ● 旧パスワードを検証→新ハッシュを作って格納するか?
    ○ テーブルのレコード数は何件あり、拡張可能か
    ○ 変更の原因はなにで、移行期間はどの程度とれるか
    52

    View Slide

  53. セキュリティ負債の解消事例
    事例② どこまでを正規ユーザにするか
    あるシステムでは通常ユーザ以外のアクセスが多く発生している。
    どこまでスクレイピングなどのアクセスを許容するべきか。
    53

    View Slide

  54. セキュリティ負債の解消事例
    事例② どこまでを正規ユーザにするか/考察
    ● アクセス規模はどの程度か?
    ○ スクレイピングのアクセス頻度は?
    ○ 許容可能な負荷か?
    ● 歴史的経緯は?
    ○ データ二次利用の実態は?
    ○ 過去どの程度にわたって行われているか?
    ● スロットリングは設定可能か? 54

    View Slide

  55. 負債返却の方法はきちんと議論しなければならない
    ✅ 利用者の平均的リテラシーは?
    ✅ 歴史的経緯や発生状況は?
    ✅ 負債の返却にかけるコストや時間は?
    ✅ 対策後のサポート体制・評価体制は?
    55

    View Slide

  56. 過去に受けた攻撃事例

    View Slide

  57. ⚠ 注意事項 ⚠
    1. これまで実際に遭遇した攻撃事例をご紹介します
    2. 防御意識を高めるためご紹介するものです
    3. 対象システムを言及しませんので、推測はしないでください
    4. 決して自身/他者の本番システムに対して試さないでください
    5. 実行される場合はすべて自己責任でお願いします
    6. 登壇者及びphpcon2020は実行結果について責任をもちません
    57

    View Slide

  58. 迷惑投稿/スパム
    攻撃内容
    攻撃者は、掲示板に外部有害サイトリンクの投稿を繰り返した。
    対応策
    ● 入力フレーズによって自動BANする
    ● 投稿回数や条件によって自動BANする
    58

    View Slide

  59. アカウント量産
    攻撃内容
    攻撃者は、アカウント生成スクリプトを用いてアカウントを大量作成した。
    対応策
    ● CAPTCHAを使ってボット判定する
    ● 同一IPアドレスから作成可能なアカウント数を制限する
    ● アカウント作成直後にとれる行動を制限する
    ● 休眠アカウントの行動を制限する
    59

    View Slide

  60. URL推測
    攻撃内容
    攻撃者は、セール告知URLから推測した商品URLにアクセスし、
    販売開始前に商品を購入した。
    対応策
    ● 商品の販売期間を設定する
    ● 告知URLから商品URLを推測できないようにする
    60

    View Slide

  61. URL総当たり
    攻撃内容
    攻撃者は、ランダムに生成されるURLに総当たりでアクセスし、
    許可されていないコンテンツを閲覧した。
    対応策
    ● リクエスト時に認証する
    ● アクセス回数に閾値を設ける
    61

    View Slide

  62. 署名検証の不備
    攻撃内容
    攻撃者は、加工された決済トランザクション情報を繰り返し送信し、
    複数回の決済を成功させた。
    対応策
    ● 一意のトランザクションIDによって重複を防ぐ
    ● 決済トランザクションに署名を設定、検証する
    62

    View Slide

  63. 高圧縮ZIP爆弾
    攻撃内容
    攻撃者は、加工された特殊なZIPファイルをサーバに送信し、
    展開によってディスクスペースを消費しつくした。
    (参考:https://www.bamsoftware.com/hacks/zipbomb/)
    対応策
    ● 最新版のunzipソフトウェアに更新する
    ● 最新版のアンチウイルスソフトで検知する
    ● 展開前にファイル構造やファイルサイズを検証する
    ● 一時領域にファイルを展開する
    63

    View Slide

  64. ImageMagickリソース消費
    攻撃内容
    攻撃者は、解像度の常に大きなJPEG画像をアップロードし、
    ImageMagickでの変換時にリソースを消費しつくした。
    (参考:JPEG pixel flood / GIF flooding / PNG compression)
    対応策
    ● ImageMagickが利用可能なリソースを制限する
    64

    View Slide

  65. PHP unserialize
    攻撃内容
    攻撃者は、悪意あるコードをクッキーに設定し、デシリアライズによって
    意図しないコードを実行した。(参考:徳丸浩の日記)
    対応策
    ● 入力値のデシリアライズをやめる
    ● 入力値をバリデーションする
    65

    View Slide

  66. 攻撃内容
    攻撃者は、クッキー値を加工してアクセスし、誤ったパース処理によって
    権限のないコンテンツが表示された。(参考:cls::blog)
    対応策
    ● parse_str() 関数の第二引数を設定する
    ● parse_str() を使わない
    PHP parse_str
    66

    View Slide

  67. 攻撃内容
    攻撃者は、プロバイダのDNSサーバ汚染によってアクセスを誘導し、
    過負荷によってサービス提供不能にされた。
    対応策
    ● 該当IPアドレス範囲のアクセス一時遮断
    DNSポイゾニング(DDoS)
    67

    View Slide

  68. 攻撃内容
    攻撃者は、加工したTCP SYNパケットを大量に送信することによって、
    conntrackが枯渇しサーバが接続不能になった。
    対応策
    ● kernel.net.ipv4パラメータのチューニング
    ● 該当IPアドレス帯域の一時遮断
    SYN Flood
    68

    View Slide

  69. 意外といろいろ受けます!
    69

    View Slide

  70. ✅ 攻撃を受けるのは有名サービスだけじゃない
    ✅ フレームワークなど既知の攻撃以外にも試行錯誤される
    ✅ 入力値のバリデーションで多くの攻撃を防げる
    ✅ 流行りの攻撃はだいたい受けるので傾向を知ろう
    ✅ 開発者リテラシーも重要になってきている
    ✅ とにかくログを丁寧に設計しよう
    70

    View Slide

  71. DDoS対策例

    View Slide

  72. DDoS対策例
    ● AWS WAFのRate Limit Ruleによって対策
    ○ IPアドレスベースで5分間のアクセスを制限
    ○ 対象パスを限定
    ● アクセス制限時にはボット検知(reCAPTCHA)
    ○ 表示画面はCloudFrontカスタムエラーレスポンスで実現
    ○ ブロック時は403 Forbiddenになるので地味につらい
    ○ API Gateway + Lambdaで検知用APIを実装
    ○ 人間と判定されたIPアドレスを一定期間ホワイトリストに追加
    72

    View Slide

  73. 73

    View Slide

  74. DDoS対策例
    All Blocked Request
    74

    View Slide

  75. DDoS対策例
    ● DDoSが発生した場合は手動(awk/sed)でアクセスログを調査
    ○ Top100 アクセス元URL
    ○ Top100 アクセス元IPアドレス
    ○ アクセス元IPアドレスごとのリクエスト調査
    ● 対象IPアドレスを手動でブロック
    ○ ほとんどが単一IPアドレスからのリクエスト過多
    ○ DDoSの場合は一時的に全体アクセスを絞る
    75

    View Slide

  76. DDoS対策例
    ● アクセス負荷の多くは遠慮のないスクレイピング行為
    ● 意図的なDDoSは理由を推測できるものがほとんど
    ● 攻撃の多くは負荷試験用ツール/サービスが使われている
    ● 攻撃時は重いURLから狙われる(たとえば検索系)
    ● コロナの影響で世界的にDDoSが増加傾向にある(参考:ITMedia)
    76

    View Slide

  77. まとめ

    View Slide

  78. 1. シロアリのいる家
    2. リスク↔コスト
    3. セキュリティ↔利便性
    4. 対岸の火事ではない
    78

    View Slide

  79. 宣伝

    View Slide

  80. View Slide

  81. ● アニメ・マンガに関する世界最大規模のユーザコミュニティ
    ● 2005年に誕生して16年続いている
    ● 20万件を超えるアニメ・マンガなどの情報や口コミが投稿される
    ● 海外のアニメファンにとって重要な情報入手経路
    ● 月間約2億PV・約1,300万MAU

    View Slide

  82. View Slide

  83. We are Hiring !!!
    ● プロジェクトマネージャー
    ● リードエンジニア(テックリード)
    ● リードインフラエンジニア(SRE)
    @ariaki4dev までご連絡ください!

    View Slide