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

セキュリティ

 セキュリティ

Cybozu
PRO

July 13, 2023
Tweet

More Decks by Cybozu

Other Decks in Technology

Transcript

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

    View Slide

  2. ⽬次
    ▌ PSIRTの紹介
    ▌ 情報セキュリティの基礎
    n CIA、情報資産・脆弱性・脅威
    n CVE、CWE、CVSS
    ▌ Webの脆弱性を知る
    n SQLインジェクション
    n XSS
    n CSRF
    ▌ ブラウザが提供するセキュリティ機能
    ▌ まとめとおまけ

    View Slide

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

    View Slide

  4. PSIRTの紹介

    View Slide

  5. PSIRTとは
    ▌PSIRT = Product Security Incident Response Team
    ▌製品のセキュリティ品質向上やインシデント対応・⽀援などを⾏うチーム
    ▌チームの理想:
    n エンドユーザに安全にサイボウズ製品を使えると⾔ってもらう
    n 開発チームにセキュリティ品質に⾃信を持って製品をリリースできると
    ⾔ってもらう
    ▌サイボウズのPSIRTは対外的にはCy-PSIRTとして活動している

    View Slide

  6. PSIRTの活動
    ▌製品の脆弱性検証(脆弱性診断)
    ▌検出された脆弱性の評価・報告・公開
    ▌第三者機関による脆弱性検証の依頼
    n 監査結果を公開:https://www.cybozu.com/jp/productsecurity/
    ▌製品で利⽤されるOSSの管理・脆弱性情報の収集
    ▌サイボウズ脆弱性報奨⾦制度の運営
    ▌インシデントハンドリング対応

    View Slide

  7. サイボウズ脆弱性報奨⾦制度
    ▌外部のセキュリティ専⾨家に脆弱性を報告していただいたら、その脆弱性
    に応じて報奨⾦をお⽀払いする制度
    n https://cybozu.co.jp/products/bug-bounty/
    ▌報告された脆弱性の調査や再現確認の実施や様々な施策の運営業
    務をPSIRTで対応
    n 施策の例: バグハン合宿
    https://blog.cybozu.io/entry/2019/07/02/080000
    7

    View Slide

  8. CSIRT(セキュリティ室)との違い
    ▌サイボウズにはCSIRTもある
    n CSIRT:Computer Security Incident Response Team
    n サイボウズのCSIRTは「セキュリティ室」と呼ばれています。
    ▌セキュリティ室は会社の情報セキュリティ
    n 「端末を紛失した︕」「不審なメールが届いた︕」など
    n ISMSやISMAPの対応もしている
    ▌セキュリティ室とPSIRTは連携して動くことも

    View Slide

  9. 情報セキュリティの基礎

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. CWE・CVE・CVSS

    View Slide

  15. 共通脆弱性タイプ⼀覧 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

    View Slide

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

    View Slide

  17. 脆弱性の評価 CVSS
    ▌CVSS(Common Vulnerability Scoring System)
    n 脆弱性の深刻度を数値化するための汎⽤的な仕組み
    n CVSSがあれば、世の中にある様々な脆弱性の深刻度を同じものさしで⽐較
    できる
    n v2、v3、v3.1が存在している
    n v2とv3は評価項⽬や評価⽅法が異なる
    n v4の検討も始まっている
    n 参考情報: FIRST https://www.first.org/cvss/

    View Slide

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

    View Slide

  19. Webの脆弱性

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  27. DOM-Based XSS の例

    <br/>const txt = decodeURIComponent(location.hash.substring(1)); // ソース<br/>document.getElementById(“sample”).innerHTML = txt; // シンク<br/>
    以下のようなURLにアクセスするとXSSが発⽣する
    http://xxx/test.html#

    View Slide

  28. 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 参考情報︓
    https://chromium.googlesource.com/chromium/src/+/master/
    docs/trusted_types_on_webui.md

    View Slide

  29. CWE-352 クロスサイトリクエストフォージェリ (CSRF)
    ▌CSRFとは
    n 被害者に罠リンクをクリックさせることで意図しない処理を実⾏させる
    脆弱性

    View Slide

  30. CSRF例(対策前)
    パスワード変更
    ページへ遷移を
    クリック
    /password-reset 新しい
    パスワードを⼊

    /password-update
    pass=abc
    罠リンク
    /password-update
    pass=hacked_password
    →攻撃者が⽤意したパスワードに更新される
    クリック

    View Slide

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

    View Slide

  32. CSRFの原因と対策
    原因
    • CSRF対策チケットが発⾏・検証されていない
    • または X-Requested-With ヘッダが付与・検証されていない。[補⾜1]
    • CSRF対策チケットの強度が弱い
    対策
    • ⼗分強度のあるCSRF対策チケットの付与、検証を⾏う
    • またはX-Requested-Withヘッダの付与・検証を⾏う
    • 実績のあるフレームワークを使う
    • CookieにSameSiteの設定をする(⼀部のCSRF攻撃以外には有効)

    View Slide

  33. [補⾜] SameSiteについて
    ▌リクエスト元に応じてクッキーをセットするかを指定できるCookieの属性値です。
    ▌None、Lax、Strictの3つが存在する。
    n None: 全てのリクエストにCookieが付与される。
    n Lax: ⼀部を除いて発⾏元と宛先が同⼀サイト以外のリクエストにはCookieが付与されない。
    n 同⼀サイト以外でもトップレベルナビゲーション(フォームやリンクでの遷移など)による
    GETリクエストではCookieが付与されます。
    n Strict: 発⾏元と宛先が同⼀サイト以外のリクエストでは全てCookieが付与されない。
    ▌⼀部のブラウザではSameSite属性を指定しなかった場合、Laxが指定されます。

    View Slide

  34. [補⾜] SameSiteとCSRF
    ▌SameSiteがCSRF対策と⾔われる理由
    n SamesiteにLaxが指定された場合、トップレベルナビゲーションかつGETリ
    クエストの場合を除いて、発⾏元と宛先が同⼀サイトでない場合には
    Cookieが付与されません。
    n そのため、Cookieで保管されているセッションID等も付与されなくなるため、
    サービス側でリクエストを正常に処理されないため、CSRF攻撃が成⽴しなく
    なります。
    ▌リンク遷移によるGETメソッドを⽤いたCSRF攻撃などは防げません。
    ▌参考︓https://blog.tokumaru.org/2022/01/impact-conditions-
    for-no-CSRF-protection-sites.html

    View Slide

  35. ブラウザが提供するセキュリティ機構

    View Slide

  36. ブラウザが提供するセキュリティ機構について
    ▌Same-Origin Policy (SOP)
    n (スキーム, ホスト名, ポート番号)の組が異なる場合、DOMの参照や通信
    の⼀部を禁⽌する。 [補⾜2]
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  40. もっと勉強したい⼈のための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_Ser
    ies
    ▌OWASP Top 10 2021
    https://owasp.org/Top10/ja/

    View Slide

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

    View Slide

  42. 補⾜

    View Slide

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

    View Slide

  44. 補⾜②
    [補⾜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/

    View Slide

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