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

セキュリティ

Avatar for Cybozu Cybozu
July 06, 2025
11

 セキュリティ

Avatar for Cybozu

Cybozu

July 06, 2025
Tweet

Transcript

  1. ⽬次 ▌ 情報セキュリティの基礎 n CIA、情報資産・脆弱性・脅威 n CVE、CWE、CVSS ▌ Webの脆弱性を知る n

    SQLインジェクション n XSS n CSRF n アクセス制御の不備 ▌ ブラウザが提供するセキュリティ機能 ▌ 時代と共に変化するセキュリティ ▌ まとめとおまけ
  2. 共通脆弱性識別⼦ CVE ▌CVE(Common Vulnerabilities and Exposures) n ⾮営利団体のMITREが中⼼となって採番している、 個々の脆弱性を識別する番号 n

    例 n CVE-2021-44228:Log4Shell(Apache Log4j) n CVE-2025-29927:ミドルウェア回避(Next.js) ▌参考情報 n https://www.ipa.go.jp/security/vuln/CVE.html
  3. 脆弱性の評価 CVSS ▌CVSS(Common Vulnerability Scoring System) n 脆弱性の深刻度を数値化するための汎⽤的な仕組み n CVSSがあれば、世の中にある様々な脆弱性の深刻度を同じものさしで⽐較

    できる n v2、v3、v3.1、v4が存在している n v2、v3、v4はバージョンによって評価項⽬や評価⽅法が異なる n 参考情報: FIRST https://www.first.org/cvss/
  4. 脆弱性の評価 CVSSv3 ▌CVSSでは基本値、環境値、現状値の3種類の基準で脆弱性を評価 ▌基本値は、CIAに以下の5項⽬を加え、計8項⽬で脆弱性を評価 n 攻撃経路(AV):ネットワーク or 隣接 or ローカル

    or 物理 n 攻撃の複雑さ(AC):低 or ⾼ n 攻撃に必要な権限(PR):なし or 低 or ⾼ n 被害者の操作の有無(UI):不要 or 要 n 影響の範囲(S):変更なし or 変更あり ▌基本値は0.0-10.0の値+それぞれの評価項⽬で表現される n 例︓4.3(CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) ▌参考情報: https://www.ipa.go.jp/security/vuln/CVSSv3.html
  5. 脆弱性の評価 CVSSv3 例 ▌ 脆弱性︓攻撃者が⽤意した罠リンクをクリックすると意図せずパスワードが変 更されるCSRF n 攻撃経路(AV):ネットワーク or 隣接

    or ローカル or 物理 n 攻撃の複雑さ(AC):低 or ⾼ n 攻撃に必要な権限(PR):なし or 低 or ⾼ n 被害者が操作を必要か(UI):不要 or 要 n 影響の範囲(S):変更なし or 変更あり n 機密性の侵害(C):なし or 低 or ⾼ n 完全性の侵害(I):なし or 低 or ⾼ n 可⽤性の侵害(A):なし or 低 or ⾼
  6. DOM-Based XSS について ▌DOM-Based XSSを構成する「ソース」と「シンク」 n ソース︓攻撃者によってスクリプトを埋め込まれる可能性のある箇所 n location.href, location.search,

    window.name など n シンク︓ソースに含まれる⽂字列を⽤いることで実際にXSSの原因と なる箇所 n document.write, element.innerHTML, $.html(), eval など
  7. DOM-Based XSS の例 <div id=“sample”></div> <script> const txt = decodeURIComponent(location.hash.substring(1));

    // ソース document.getElementById(“sample”).innerHTML = txt; // シンク </script> 以下のようなURLにアクセスするとXSSが発⽣する http://xxx/test.html#<img src=“xxx” onerror=“alert('1ʼ)”/>
  8. DOM-Based XSSに特化した対策 ▌ Trusted Types n CSPで「trusted types」を指定することでシンクに代⼊できる値の型をTrusted Types 型に制限することができる

    n Trusted Types型以外がシンクを経由して代⼊されそうになるとエラーになる n 注意 n 対応しているブラウザが少ない n https://caniuse.com/?search=trustedtype n Trusted Typesでの定義するエスケープ処理が適切でないとDOM-based XSSは防げない n 参考情報︓ n https://developer.mozilla.org/en- US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/trusted- types
  9. CSRF例(対策前) パスワード変更 ページへ遷移を クリック /password-reset 新しい パスワードを⼊ ⼒ /password-update pass=abc

    罠リンク /password-update pass=hacked_password →攻撃者が⽤意したパスワードに更新される クリック
  10. CSRF例(対策後) csrf_token=6aS8... /password-update pass=abc csrf_token=6aS8... 罠リンク クリック /password_update pass=hacked_password →攻撃者はcsrf_tokenがわからないのでパス

    ワードの変更ができない × パスワード変更 ページへ遷移を クリック /password-reset 新しい パスワードを⼊ ⼒
  11. CSRFの原因と対策 原因 • 副作⽤のあるAPIをGETメソッドで実装している • CSRF対策チケットが発⾏・検証されていない • CSRF対策チケットの強度が弱い 対策 •

    副作⽤のあるAPIをPOSTメソッドで実装する(GETメソッドで実装しない) • ⼗分強度のあるCSRF対策チケットの付与、検証を⾏う • OriginヘッダやFetch Metadataの検証を⾏うことでリクエストの出⾃を確認 • https://blog.jxck.io/entries/2024-04-26/csrf.html • CookieにSameSiteの設定をする(⼀部のCSRF攻撃以外には有効)
  12. [補⾜] SameSiteについて ▌ リクエスト元に応じてクッキーをセットするかを指定できるCookieの属性値 ▌ None、Lax、Strictの3つが存在する n None: 全てのリクエストにCookieが付与される。3rd Party

    Cookieとも呼ばれる n Lax: ⼀部を除いて発⾏元と宛先が同⼀サイト以外のリクエストにはCookieが付与されない n 同⼀サイト以外でもトップレベルナビゲーション(フォームやリンクでの遷移など)による GETリクエストではCookieが付与される n Strict: 発⾏元と宛先が同⼀サイト以外のリクエストでは全てCookieが付与されない ▌ ⼀部のブラウザではSameSite属性を指定しなかった場合、Laxが指定される ▌ Safari、Firefoxなどのブラウザでは3rd Party Cookieはデフォルトでブロックされる n Chromeでも廃⽌の⽅向で進められていたが、廃⽌が撤回された n https://privacysandbox.com/news/privacy-sandbox-next-steps/
  13. アクセス制御の不備の原因と対策 原因 • ロジックの考慮漏れや実装の不備 • 必要以上の権限が付与されている • サーバやソフトウェアの設定が間違っている 対策 •

    権限の範囲を⾒直し、ロジックや実装に漏れがないかを確認する • 権限は必要最低限のものだけを付与する • 適切な設定をする
  14. ブラウザが提供するセキュリティ機構について ▌Same-Origin Policy(SOP) n (スキーム, ホスト名, ポート番号)の組が異なる場合、DOMの参照や通信 の⼀部を禁⽌する n (スキーム,

    ホスト名, ポート番号)の組のことをOriginと呼ぶ n Originが同⼀の時、Same-Origin、 異なる時Cross-Originと呼ぶ ▌Content Security Policy(CSP) n サーバーサイドWebアプリケーションが課した制約に違反する挙動をWebブ ラウザが検出する n 指定されたjavascript以外読み込まないなど n 詳細:https://developer.mozilla.org/ja/docs/Web/HTTP/CSP
  15. セキュリティ機能 ▌ブラウザのセキュリティ機能として、以下を指定することができる n X-Content-Type-Options n 指定したMIMEタイプを変更せずに従う n X-Frame-Options n 他のページのフレーム内での表⽰を制御する

    n クリックジャッキング対策 n Content-Disposition: attachment; n 内容が添付ファイルかインラインのデータとして扱うかを制御する n Strict-Transport-Security n HTTPSを強制する
  16. Cookieの扱い ▌Cookieの発⾏時に属性を指定することで扱いを制限できる n Expires:絶対的な有効期限を指定 n Max-Age:相対的な有効期限を指定 n Domain:利⽤可能なホストを指定 n Path:利⽤可能なパスを指定

    n Secure:HTTPSを利⽤しているときにのみ送信される n HttpOnly:jsなどからの呼び出し禁⽌ n SameSite:リクエスト元に応じてCookieをセットするかを指定 n もっと詳しく知りたい︓ https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies
  17. 2021年版のOWASP Top10 順位 項⽬ 1位 アクセス制御の不備 2位 暗号化の失敗 3位 インジェクション

    4位 安全が確認されていない不安な設計 5位 セキュリティの設計ミス 6位 脆弱で古くなったコンポーネント 7位 識別と認証の失敗 8位 ソフトウェアとデータの整合性の不具合 9位 セキュリティログとモニタリングの失敗 10位 サーバーサイドリクエストフォージェリ(SSRF) ※⻘が講義で扱ったもの、緑が新しい項⽬
  18. OWASP Top10から⾒る時代と共に変化するセキュリティ 2017年版 順 項⽬ 1位 インジェクション 2位 認証の不備 3位

    機微な情報の露出 4位 XML外部エンティティ参照(XXE) 5位 アクセス制御の不備 6位 不適切なセキュリティ設定 7位 クロスサイトスクリプティング(XSS) 8位 安全ではないデシリアライゼーション 9位 既知の脆弱性のあるコンポーネントの使⽤ 10位 不⼗分なロギングとモニタリング 2021年版 順位 項⽬ 1位 アクセス制御の不備 2位 暗号化の失敗 3位 インジェクション 4位 安全が確認されていない不安な設計 5位 セキュリティの設計ミス 6位 脆弱で古くなったコンポーネント 7位 識別と認証の失敗 8位 ソフトウェアとデータの整合性の不具合 9位 セキュリティログとモニタリングの失敗 10位 サーバーサイドリクエストフォージェリ(SSRF) 順位の変動や 新しいものが 追加 アプリロジックや開発⾃体に関するものが多くランキング
  19. もっと勉強したい⼈のための本 ▌徳丸浩『体系的に学ぶ 安全なWebアプリケーションの作り⽅ 第2版 脆 弱性が⽣まれる原理と対策の実践』 SBクリエイティブ ▌⽶内貴志『Webブラウザセキュリティ Webアプリケーションの安全性を⽀ える仕組みを整理する』

    ラムダノート ▌上野宣『Webセキュリティ担当者のための脆弱性診断スタートガイド 第 ⼆版 上野宣が教える情報漏えいを防ぐ技術』 翔泳社 ▌平野昌⼠『フロントエンド開発のためのセキュリティ⼊⾨ 知らなかったでは 済まされない脆弱性対策の必須知識』 翔泳社