セキュリティ 開運研修2022 / security 2022

Transcript

1. PSIRT
   開運研修 2022
   セキュリティ
   

   View Slide

2. もくじ
   PSIRTの紹介
   情報セキュリティの基礎
   CVE、CWE、CVSS
   脆弱性を知る
   SQLインジェクション
   XSS
   CSRF
   ブラウザが提供するセキュリティ機能
   まとめとおまけ資料
   

   View Slide

3. この時間の⽬標
   情報セキュリティの3要素を知る
   CVE、CWE、CVSSがなにものかを知る
   具体的な脆弱性の原因や対策を知る
   脆弱性をよりただしく理解し、対策するための基礎を⾝に着ける
   

   View Slide

4. PSIRTとは
   PSIRT = Product Security Incident Response Team
   製品のセキュリティ品質向上やインシデント対応・⽀援などを⾏うチーム
   サイボウズのPSIRTは対外的にはCy-PSIRTとして活動している
   

   View Slide

5. Cy-PSIRTの活動
   サイボウズ製品の脆弱性検証
   第三者機関による脆弱性検証
   社内検証に加え、２つのセキュリティ監査/検証を実施しています。
   監査結果は公開中︓https://www.cybozu.com/jp/productsecurity/
   検出された脆弱性の評価
   製品で利⽤されるOSSの脆弱性情報の収集
   製品関連の⼤きな脆弱性が発覚した際の社内調整
   脆弱性報奨⾦制度の運⽤
   外部のセキュリティ専⾨家に脆弱性を報告していただいたら、その脆弱性に応じて
   報奨⾦をお⽀払いする制度
   

   View Slide

6. CSIRT(セキュリティ室)との違い
   サイボウズにはCSIRTもある
   CSIRT:Computer Security Incident Response Team
   サイボウズのCSIRTは「セキュリティ室」と呼ばれています。
   セキュリティ室は会社の情報セキュリティ
   セキュリティ室とPSIRTは連携して動くことも
   

   View Slide

7. Webセキュリティ
   

   View Slide

8. 情報セキュリティの３要素
   情報セキュリティとは「CIA(機密性、完全性、可⽤性)」を維持すること
   Confidentiality
   認可されていない個⼈、
   エンティティまたはプロ
   セスに対して、情報を使
   ⽤させず、また開⽰しな
   い特性。
   Integrity
   正確さ及び完全さの特性。
   Availability
   認可されたエンティ
   ティが要求したときに、
   アクセス及び使⽤が可能
   である特性。
   

   View Slide

9. 情報資産
   情報セキュリティで保護すべき対象
   PC・スマートフォン
   設備
   印刷物
   情報
   ⼈
   情報資産
   

   View Slide

10. 脆弱性
    セキュリティ上の問題箇所
    ソフトウェア製品の本来の機能や性能を損なう原因となりうる箇所
    不適切な運⽤により、セキュリティが維持できなくなっている状態
    脆弱性
    

    View Slide

11. 脅威
    組織に損害を与える可能性のある潜在的な原因
    外部からの攻撃
    ⾃然災害
    ⼈的ミス
    脅威が脆弱性をつくことでリスクが発⽣する
    脅威
    リスクが発⽣
    

    View Slide

12. 共通脆弱性タイプ⼀覧 CWE
    CWE(Common Weakness Enumeration)
    ⾮営利団体のMITREが中⼼となって策定しているソフトウェアにおけるセキュリティ
    上の脆弱性の識別番号
    要するに、脆弱性の種類ごとに⼀意な番号を振ったもの
    例
    CWE-89:SQLインジェクション
    CWE-352:CSRF
    参考情報
    https://www.ipa.go.jp/security/vuln/CWE.html
    

    View Slide

13. 共通脆弱性識別⼦ CVE
    CVE(Common Vulnerabilities and Exposures)
    ⾮営利団体のMITREが中⼼となって採番している、
    個々の脆弱性を識別する番号
    例
    CVE-2014-6271:ShellShock(bash)
    参考情報
    https://www.ipa.go.jp/security/vuln/CVE.html
    

    View Slide

14. 脆弱性の評価 CVSS
    CVSS（Common Vulnerability Scoring System）
    脆弱性の深刻度を数値化するための汎⽤的な仕組み
    CVSSがあれば、世の中にある様々な脆弱性の深刻度を同じものさしで⽐べられる
    v2、v3、v3.1がある
    v3.1はv3のマイナーアップデート版
    v2とv3は評価項⽬や評価⽅法が異なる
    最近はv3 or v3.1で計算されることが多い
    

    View Slide

15. 脆弱性の評価 CVSS
    CVSSv3(Common Vulnerability Scoring System v3.0)とは
    脆弱性の深刻度を数値化するための世界中で使われるシステム
    基本値、環境値、現状値の3種類が存在する
    基本値は、CIAに以下の５項⽬を加え、計8項⽬で脆弱性を評価
    攻撃経路(AV):ネットワーク or 隣接 or ローカル or 物理
    攻撃の複雑さ(AC):低 or ⾼
    攻撃に必要な権限(PR):なし or 低 or ⾼
    被害者の操作の有無(UI):不要 or 要
    影響の範囲(S):変更なし or 変更あり
    基本値は0.0-10.0の値＋それぞれの評価項⽬で表現される
    例︓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
    

    View Slide

16. 脆弱性の原理と対策
    

    View Slide

17. CWE-89 SQLインジェクション
    SQLインジェクションとは
    Webアプリケーションを通じて任意のSQL⽂をデータベースに対して発⾏できる
    脆弱性
    原理
    攻撃者によるSQL⽂の構造を破壊するような⼊⼒を、アプリケーションが適切に処
    理せずにSQL⽂が発⾏されることで予期しないSQL⽂が実⾏される。
    

    View Slide

18. SELECT * FROM tbl_user WHERE id =ʻ{$_GET[ʻidʼ]}ʼ
    ʼ OR 1=1 --
    id =ʻʼ OR 1=1 --ʼ
    SQLインジェクション例
    SQL ⽂の構造を破壊され WHERE 句で指定される条件が常に「真」に
    なり、情報が漏えいします。
    診断時には AND(ʻ and 1=0) を使うことが推奨です。
    

    View Slide

19. SQLインジェクションの原因と対策
    ユーザーが⼊⼒した⽂字列を適切にエスケープしていない
    静的プレースホルダやテンプレートエンジン等、フレームワークの
    ⽀援機構を利⽤する
    参照：IPA「安全なSQLの呼び出し⽅」https://www.ipa.go.jp/files/000017320.pdf
    原因
    対策
    

    View Slide

20. CWE-79 クロスサイトスクリプティング(XSS)
    XSSとは
    Webアプリケーションを通じて任意のスクリプトを利⽤者のブラウザで実⾏させる
    脆弱性
    原理
    HTMLタグの構造を破壊する⼊⼒をすることでスクリプトを実⾏される
    種類
    蓄積型 XSS:攻撃コードがDBなどに保存されている
    反射型 XSS:攻撃コードがリクエストに含まれる
    DOM-Based XSS:DOM操作時に発⽣する
    

    View Slide

21. 反射型XSSの例
    さん
    index.php?name=AAA
    URL:
    GETリクエストパラメーター
    の値をそのまま表⽰させる
    AAAさん alert(1)さん
    index.php?name=alert(1)
    

    View Slide

22. XSSの原因と対策
    • ⼊⼒された値のエスケープ漏れ
    • ⽂字コードやコンテンツ型の⾃動判別への理解不⾜
    • ⼊⼒された値は正しくエスケープする
    • ⽂字コードは必ず宣⾔する
    • コンテンツ型が HTML と判定されないようにする
    原因
    対策
    

    View Slide

23. DOM-Based XSS についての補⾜
    DOM-Based XSSを構成する「ソース」と「シンク」
    ソース︓攻撃者によってスクリプトを埋め込まれる可能性のある箇所
    location.href, location.search, window.name など
    シンク︓ソースに含まれる⽂字列を⽤いることで実際にXSSの原因となる箇所
    document.write, element.innerHTML, $.html(), eval など
    

    View Slide

24. DOM-Based XSS の例
    
    <br/>const txt = decodeURIComponent(location.hash.substring(1)); // ソース<br/>document.getElementById(“sample”).innerHTML = txt; // シンク<br/>
    

    View Slide

25. DOM-Based XSSに特化した対策
    Trusted Types
    CSPで「trusted types」を指定することでシンクに代⼊できる値の型をTrusted
    Types型に制限することができる。
    Trusted Types型以外がシンクを経由して代⼊されそうになるとエラーになる。
    注意
    対応しているブラウザがまだ少ない
    https://caniuse.com/?search=trustedtype
    Trusted Typesでの定義するエスケープ処理が適切でないとDOM-based XSSは防げない
    詳細︓
    https://chromium.googlesource.com/chromium/src/+/master/d
    ocs/trusted_types_on_webui.md
    

    View Slide

26. CWE-352 クロスサイトリクエストフォージェリ
    (CSRF)
    CSRFとは
    被害者に罠リンクをクリックすることで意図せず処理させる脆弱性
    

    View Slide

27. CSRF例（対策前)
    パスワード変更
    ページへ遷移を
    クリック
    /password-reset 新しい
    パスワード
    を⼊⼒
    /password-update
    pass=abc
    罠リンク
    /password-update
    pass=hacked_password
    →攻撃者が⽤意したパスワードに更新さ
    れる
    クリック
    

    View Slide

28. CSRF例（対策後）
    csrf_token=6aS8...
    /password-update
    pass=abc
    csrf_token=6aS8...
    罠リンク
    クリック
    /password_update
    pass=hacked_password
    →攻撃者はcsrf_tokenがわからないので
    パスワードの変更ができない
    ×
    パスワード変更
    ページへ遷移を
    クリック
    /password-reset 新しい
    パスワード
    を⼊⼒
    

    View Slide

29. • ⼗分強度のあるCSRF対策チケットの付与、検証を⾏う
    • またはX-Requested-Withヘッダの付与・検証を⾏う
    • 実績のあるフレームワークを使う
    • CSRF対策チケットが発⾏・検証されていない
    • または X-Requested-With ヘッダが付与・検証されていない。[補⾜2]
    • CSRF対策チケットの強度が弱い
    CSRFの原因と対策
    原因
    対策
    

    View Slide

30. ブラウザが提供するセキュリティ機構
    Same-Origin Policy （SOP）
    (スキーム, ホスト名, ポート番号)の組が異なる場合、DOMの参照や通信の⼀
    部を禁⽌する。 [補⾜3]
    (スキーム, ホスト名, ポート番号)の組のことをOriginと呼ぶ。
    Originが同⼀の時、Same-Origin、 異なる時Cross-Originと呼ぶ。
    Content Security Policy（CSP）
    サーバーサイドWebアプリケーションが課した制約に違反する挙動をWebブラウザ
    が検出する
    指定されたjavascript以外読み込まないなど。
    詳細:https://developer.mozilla.org/ja/docs/Web/HTTP/CSP
    

    View Slide

31. セキュリティ機能
    ブラウザのセキュリティ機能として、以下を指定することができます
    X-Content-Type-Options
    指定したMIMEタイプに従う
    X-Frame-Options
    iframeの中に表⽰していいかを⽰す
    クリックジャッキング対策に
    Content-Disposition: attachment;
    このファイルはダウンロードする
    Strict-Transport-Security
    HTTPSを強制する
    

    View Slide

32. Cookieの扱い
    Cookieを発⾏時に属性を指定することで扱いを制限することができる。
    ［補⾜3］
    Expires:絶対的な有効期限を指定
    Max-Age:相対的な有効期限を指定
    Domain:利⽤可能なホストを指定
    Path:利⽤可能なパスを指定
    Secure:HTTPSを利⽤しているときにのみ送信される
    HttpOnly:jsなどからの呼び出し禁⽌
    SameSite:リクエスト元に応じてクッキーをセットするかを指定[補⾜4]
    もっと詳しく知りたい︓
    https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies
    

    View Slide

33. まとめ
    情報セキュリティはCIA(機密性・完全性・可⽤性)を維持すること。
    脆弱性を作り込まない基本的な対策は、ユーザーの⼊⼒は信⽤せず、
    実績のあるフレームワーク等の機構を⽤いて適切にエスケープやサニタイズ
    を⾏う。
    ブラウザの機能で⼀部の脆弱性の脅威は緩和されるが、過信せずにクラ
    イアントサイド/サーバーサイドWebアプリケーション側で対策を⾏う。
    

    View Slide

34. もっと勉強したい⼈のためのWeb資料
    安全なウェブサイトの作り⽅
    http://www.ipa.go.jp/security/vuln/websecurity.html
    Webアプリケーション脆弱性診断ガイドライン
    https://github.com/OWASP/www-chapter-
    japan/tree/master/secreq
    OWASP チートシート
    https://www.owasp.org/index.php/OWASP_Cheat_Sheet
    _Series
    OWASP Top 10 2021
    https://owasp.org/Top10/ja/
    

    View Slide

35. もっと勉強したい⼈のための本
    徳丸浩『体系的に学ぶ 安全なWebアプリケーションの作り⽅ 第2版 脆
    弱性が⽣まれる原理と対策の実践』 SBクリエイティブ
    ⽶内貴志『Webブラウザセキュリティ Webアプリケーションの安全性を⽀
    える仕組みを整理する』 ラムダノート
    上野宣『Webセキュリティ担当者のための脆弱性診断スタートガイド 第
    ⼆版 上野宣が教える情報漏えいを防ぐ技術』 翔泳社
    

    View Slide

36. 補⾜①
    [補⾜1]
    リクエストには、「シンプルリクエスト」「プリフライトリクエスト」があります。
    SOPで禁⽌されるのはプリフライトリクエストが必要になるリクエストの場合です。
    https://developer.mozilla.org/ja/docs/Web/HTTP/CORS#simple_requests
    [補⾜2]
    通常SOPではformタグのリクエストは制限されません。
    しかし、リクエストにX-Requested-Withヘッダの付与することを条件にするとformタグでのリクエストの送出はできな
    くなり、fetch等のAPIを使う必要があります。さらに、プリフライトリクエストが必要になるため、SOPの制限を受けます。
    つまり攻撃者がX-Requested-Withヘッダを付与する罠リンクを攻撃対象のサイトのSame-Originに配置しなけれ
    ばならないため、SOPが適切に機能するブラウザではCSRFの対策になります。
    

    View Slide

37. 補⾜②
    [補⾜3]
    多くのセキュリティ機構はOriginをベースに設定されていますが、Cookieが提案された当初はOriginの考えが定着しておら
    ず、現在となってはCookieはやや特殊なセキュリティ境界を持っています。SameSite属性はOriginに近い考えを適⽤でき
    ますが、若⼲異なります。
    詳細︓
    https://tools.ietf.org/html/rfc6265
    https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07
    https://web.dev/same-site-same-origin/
    [補⾜4]
    ⼀部のブラウザではSameSite属性を指定しなかった場合、Laxが指定されていると⾒なすようになっています。
    Samesite＝Laxが指定されている場合、リンクをクリックすることで発⽣するようなGETリクエストではCookieが付与されま
    すが、それ以外のリクエストで、かつリクエストの発⾏元と宛先が同⼀のSiteでない場合はCookieが付与されなくなります。そ
    の結果、Cookieで保管されているセッションID等が付与されなくなり、リクエストが受け付けられないので、CSRFが成⽴しな
    くなります。
    参考︓https://blog.tokumaru.org/2022/01/impact-conditions-for-no-CSRF-protection-sites.html
    

    View Slide

38. 脆弱性の評価 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 ⾼
    

    View Slide

39. おつかれさまでした
    講義はこれで終了です
    

    View Slide