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