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

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

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

Cybozu

June 21, 2022
Tweet

More Decks by Cybozu

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  7. Webセキュリティ

    View full-size slide

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

    View full-size slide

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

    情報資産

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  12. 共通脆弱性タイプ⼀覧 CWE
    CWE(Common Weakness Enumeration)
    ⾮営利団体のMITREが中⼼となって策定しているソフトウェアにおけるセキュリティ
    上の脆弱性の識別番号
    要するに、脆弱性の種類ごとに⼀意な番号を振ったもの

    CWE-89:SQLインジェクション
    CWE-352:CSRF
    参考情報
    https://www.ipa.go.jp/security/vuln/CWE.html

    View full-size slide

  13. 共通脆弱性識別⼦ CVE
    CVE(Common Vulnerabilities and Exposures)
    ⾮営利団体のMITREが中⼼となって採番している、
    個々の脆弱性を識別する番号

    CVE-2014-6271:ShellShock(bash)
    参考情報
    https://www.ipa.go.jp/security/vuln/CVE.html

    View full-size slide

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

    View full-size slide

  15. 脆弱性の評価 CVSS
    CVSSv3(Common Vulnerability Scoring System v3.0)とは
    脆弱性の深刻度を数値化するための世界中で使われるシステム
    基本値、環境値、現状値の3種類が存在する
    基本値は、CIAに以下の5項⽬を加え、計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 full-size slide

  16. 脆弱性の原理と対策

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. DOM-Based XSS の例

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size 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 full-size slide

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

    View full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size slide