セキュリティ

Transcript

1. 開運研修 2025(講義) セキュリティ
2. ⽬次 ▌ 情報セキュリティの基礎 n CIA、情報資産・脆弱性・脅威 n CVE、CWE、CVSS ▌ Webの脆弱性を知る n SQLインジェクション n XSS n CSRF n アクセス制御の不備 ▌ ブラウザが提供するセキュリティ機能 ▌ 時代と共に変化するセキュリティ ▌ まとめとおまけ
3. この時間の⽬的 ▌情報セキュリティの3要素を知る ▌CVE、CWE、CVSSが何かを知る ▌具体的な脆弱性の原因や対策を知る ▌脆弱性をより正しく理解し、対策するための基礎を⾝に着けてもらう
4. 情報セキュリティの基礎
5. 情報セキュリティの３要素 ▌情報セキュリティとは「CIA(機密性、完全性、可⽤性)」を維持すること Confidentiality 認可されていない個⼈、 エンティティまたはプロセスに 対して、情報を使⽤させず、 また開⽰しない特性。 Integrity 正確さ及び完全さの特性。 Availability 認可されたエンティティが要 求したときに、アクセス及び使 ⽤が可能である特性。
6. 情報資産 ▌情報セキュリティで保護すべき対象 n PC・スマートフォン n 設備 n 印刷物 n 情報 n ⼈ 情報資産
7. 脆弱性 ▌セキュリティ上の問題箇所 n ソフトウェア製品の本来の機能や性能を損なう原因となりうる箇所 n 不適切な運⽤により、セキュリティが維持できなくなっている状態 脆弱性
8. 脅威 ▌組織に損害を与える可能性のある潜在的な原因 n 外部からの攻撃 n ⾃然災害 n ⼈的ミス ▌脅威が脆弱性をつくことでリスクが発⽣する 脅威 リスクが発⽣
9. CWE・CVE・CVSS
10. 共通脆弱性タイプ⼀覧 CWE ▌CWE（Common Weakness Enumeration） n ⾮営利団体のMITREが中⼼となって策定しているソフトウェアにおけ るセキュリティ上の弱点(脆弱性)の識別番号 n 例 n CWE-89:SQLインジェクション n CWE-352:CSRF ▌参考情報 n https://www.ipa.go.jp/security/vuln/CWE.html
11. 共通脆弱性識別⼦ 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
12. 脆弱性の評価 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/
13. 脆弱性の評価 CVSSv3 ▌CVSSでは基本値、環境値、現状値の3種類の基準で脆弱性を評価 ▌基本値は、CIAに以下の５項⽬を加え、計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
14. 脆弱性の評価 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 ⾼
15. 余談: CVEプログラム存続の危機 ▌CVEプログラムは開始以来、25年間⽶国国⼟安全保障省から資⾦提 供を受けたMITREが中⼼となって運営 ▌しかし、資⾦提供契約を更新しないことが2025年4⽉15⽇に通知され、 4⽉16⽇には契約が失効することが明らかになった ▌そこで、CVEプログラムの安定運⽤を⽬指すためのCVE財団が発⾜ ▌その後、⽶国政府による資⾦提供契約がギリギリで延⻑されたと発表 ▌参考情報 n https://www.publickey1.jp/blog/25/cve_foundationcve.html ※ 上記は2025/06/11 時点の情報です
16. Webの脆弱性
17. CWE-89 SQLインジェクション ▌SQLインジェクションとは n Webアプリケーションを通じて任意のSQL⽂をデータベースに対して発 ⾏できる脆弱性 ▌原理 n 攻撃者によるSQL⽂の構造を破壊するような⼊⼒を、アプリケーション が適切に処理せずにSQL⽂が発⾏されることで予期しないSQL⽂が 実⾏される
18. SQLインジェクション例 ▌SQL ⽂の構造を破壊され WHERE 句で指定される条件が常に「真」 になり、情報が漏えいする 診断時には AND(ʻ and 1=0) を使うことが推奨 SELECT * FROM tbl_user WHERE id =ʻ{$_GET[ʻidʼ]}ʼ ʼ OR 1=1 -- id =ʻʼ OR 1=1 --ʼ
19. SQLインジェクションの原因と対策 原因 ユーザーが⼊⼒した⽂字列を適切にエスケープしていない 対策 静的プレースホルダやテンプレートエンジン等、フレームワークの⽀援機構を利 ⽤する 参照︓IPA「安全なSQLの呼び出し⽅」 https://www.ipa.go.jp/files/000017320.pdf
20. CWE-79 クロスサイトスクリプティング(XSS) ▌XSSとは n Webアプリケーションを通じて任意のスクリプトを利⽤者のブラウザで実⾏させる 脆弱性 ▌原理 n HTMLタグの構造を破壊する⼊⼒をすることでスクリプトが実⾏される ▌種類 n 蓄積型 XSS:攻撃コードがDBなどに保存されている n 反射型 XSS:攻撃コードがリクエストに含まれる n DOM-Based XSS:DOM操作時に発⽣する
21. 反射型XSSの例 URL: index.php?name=AAA AAAさん <h1><?php echo $_GET['name'] ?>さん</h1> GETリクエストパラメーター の値をそのまま表⽰させる index.php?name=<script>alert(1)</script> <script>alert(1)</script>さん
22. XSSの原因と対策 原因 • ⼊⼒値のエスケープ漏れ • ⽂字コードやコンテンツ型の⾃動判別への理解不⾜ 対策 • ⼊⼒値を正しくエスケープする • ⽂字コードは必ず宣⾔する • コンテンツ型が HTML と判定されないようにする
23. DOM-Based XSS について ▌DOM-Based XSSを構成する「ソース」と「シンク」 n ソース︓攻撃者によってスクリプトを埋め込まれる可能性のある箇所 n location.href, location.search, window.name など n シンク︓ソースに含まれる⽂字列を⽤いることで実際にXSSの原因と なる箇所 n document.write, element.innerHTML, $.html(), eval など
24. 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ʼ)”/>
25. 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
26. CWE-352 クロスサイトリクエストフォージェリ (CSRF) ▌CSRFとは n 被害者に罠リンクをクリックさせることで意図しない処理を実⾏させる 脆弱性
27. CSRF例（対策前) パスワード変更 ページへ遷移を クリック /password-reset 新しい パスワードを⼊ ⼒ /password-update pass=abc 罠リンク /password-update pass=hacked_password →攻撃者が⽤意したパスワードに更新される クリック
28. CSRF例（対策後） csrf_token=6aS8... /password-update pass=abc csrf_token=6aS8... 罠リンク クリック /password_update pass=hacked_password →攻撃者はcsrf_tokenがわからないのでパス ワードの変更ができない × パスワード変更 ページへ遷移を クリック /password-reset 新しい パスワードを⼊ ⼒
29. 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攻撃以外には有効）
30. [補⾜] 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/
31. [補⾜] SameSiteがCSRF対策になる理由 ▌宛先が同⼀サイトでない場合、Cookieが付与されず処理が失敗するため n トップレベルナビゲーションかつGETリクエストの場合は付与されるため、 リンク遷移によるGETメソッドを⽤いたCSRF攻撃などは防げない ブラウザで管理されているドメイン2のCookie ・SameSite=Lax ・SessionID=ab34f5678EtZ ドメイン2へのPOSTリクエスト 1. 同⼀サイトではないのでCookieが付与されない 発⾏元:ドメイン1 宛先:ドメイン2 2. Cookieがない=SessionIDが ないので処理が失敗する => 結果的にCSRFが成⽴しない 参考:https://blog.tokumaru.org/2022/01/impact-conditions-for-no-CSRF-protection-sites.html
32. アクセス制御の不備 ▌アクセス制御の不備とは 実装や設定の不備により本来、権限のない操作(閲覧・変更・削除)が 実⾏できてしまう脆弱性 ▌悪⽤された際の被害 n 情報の漏洩や改ざん n 例:本来、管理者しか閲覧できない情報を⼀般ユーザが閲覧できてし まう
33. アクセス制御の不備の例 ▌パラメータの変更により本来閲覧権限がないものが閲覧できてしまう Aさん(userID=1) Aさんのみがアクセスできるページ 攻撃者(userID=2) [通常のリクエスト] GET/personal_page?userID=1 攻撃者がuserIDをAさんのものに変更 [改ざんしたリクエスト] GET /personal_page?userID=1 =>Aさんのページにアクセスできる
34. アクセス制御の不備の原因と対策 原因 • ロジックの考慮漏れや実装の不備 • 必要以上の権限が付与されている • サーバやソフトウェアの設定が間違っている 対策 • 権限の範囲を⾒直し、ロジックや実装に漏れがないかを確認する • 権限は必要最低限のものだけを付与する • 適切な設定をする
35. [補⾜] ソフトウェアとアクセス権限 ▌ソフトウェアでは様々なアクセス権限が実装されている ▌機能に対してそれぞれの権限で何ができて、何ができてはいけないかを把 握する ▌基本的には、必要最低限のものだけを付与 それぞれで何ができるか 何ができてはいけないかを考える 管理者権限 各機能ごとの権限 ユーザごとの権限 その他の権限 ソフトウェアに含まれる様々な権限
36. ブラウザが提供するセキュリティ機構
37. ブラウザが提供するセキュリティ機構について ▌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
38. セキュリティ機能 ▌ブラウザのセキュリティ機能として、以下を指定することができる n X-Content-Type-Options n 指定したMIMEタイプを変更せずに従う n X-Frame-Options n 他のページのフレーム内での表⽰を制御する n クリックジャッキング対策 n Content-Disposition: attachment; n 内容が添付ファイルかインラインのデータとして扱うかを制御する n Strict-Transport-Security n HTTPSを強制する
39. 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
40. 時代と共に変化するセキュリティ
41. OWASP Top 10(2021年) ▌セキュリティは時代と共に変化する それを象徴するものにOWASP Top 10がある ▌OWASPが提供するWebアプリケーションセキュリティに関する最も重⼤ な10リスクを⽰したドキュメント n https://owasp.org/Top10/ja/ ▌実際のデータを元にランキング形式で掲載 ▌2021年が最新版
42. 2021年版のOWASP Top10 順位 項⽬ 1位 アクセス制御の不備 2位 暗号化の失敗 3位 インジェクション 4位 安全が確認されていない不安な設計 5位 セキュリティの設計ミス 6位 脆弱で古くなったコンポーネント 7位 識別と認証の失敗 8位 ソフトウェアとデータの整合性の不具合 9位 セキュリティログとモニタリングの失敗 10位 サーバーサイドリクエストフォージェリ(SSRF) ※⻘が講義で扱ったもの、緑が新しい項⽬
43. 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) 順位の変動や 新しいものが 追加 アプリロジックや開発⾃体に関するものが多くランキング
44. まとめ ▌情報セキュリティはCIA(機密性・完全性・可⽤性)を維持すること ▌脆弱性を作り込まない基本的な対策は、ユーザーの⼊⼒は信⽤せず、 実績のあるフレームワーク等の機構を⽤いて適切にエスケープやサニタイ ズを⾏うこと ▌ブラウザの機能で⼀部の脆弱性の脅威は緩和されるが、過信せずにクラ イアントサイド/サーバーサイドのWebアプリケーション側で対策を⾏う ▌時代ともにセキュリティは変わるので常に新しい情報を確認すること
45. もっと勉強したい⼈のためのWeb資料 ▌安全なウェブサイトの作り⽅ http://www.ipa.go.jp/security/vuln/websecurity.html ▌Webアプリケーション脆弱性診断ガイドライン 第1.2版 https://github.com/WebAppPentestGuidelines/WebAppPe ntestGuidelines/tree/master/WebAppPentestGuidelines ▌OWASP チートシート https://www.owasp.org/index.php/OWASP_Cheat_Sheet _Series
46. もっと勉強したい⼈のための本 ▌徳丸浩『体系的に学ぶ 安全なWebアプリケーションの作り⽅ 第2版 脆 弱性が⽣まれる原理と対策の実践』 SBクリエイティブ ▌⽶内貴志『Webブラウザセキュリティ Webアプリケーションの安全性を⽀ える仕組みを整理する』 ラムダノート ▌上野宣『Webセキュリティ担当者のための脆弱性診断スタートガイド 第 ⼆版 上野宣が教える情報漏えいを防ぐ技術』 翔泳社 ▌平野昌⼠『フロントエンド開発のためのセキュリティ⼊⾨ 知らなかったでは 済まされない脆弱性対策の必須知識』 翔泳社