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

開運研修2021 セキュリティ / Security 2021

開運研修2021 セキュリティ / Security 2021

Cybozu

May 28, 2021
Tweet

More Decks by Cybozu

Other Decks in Technology

Transcript

  1. 開運研修 2021
    セキュリティ
    PSIRT ⼤塚 純平

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  4. Cy-CSIRT(セキュリティ室)との違い
    ▌サイボウズにはCSIRTもある
    n CSIRT:Computer Security Incident Response Team
    n サイボウズのCSIRTは「セキュリティ室」と呼ばれています。
    ▌セキュリティ室は会社の情報セキュリティ
    n PCなくした︕, あやしいメールが届いた︕ など
    ▌セキュリティ室とPSIRTは役割は違えど連携しています。

    View full-size slide

  5. Webセキュリティ

    View full-size slide

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

    View full-size slide

  7. 情報資産
    ▌情報セキュリティで保護すべき対象
    n PC
    n 設備
    n 印刷物
    n 情報
    n ⼈
    情報資産

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  12. 脆弱性の評価 CVSSv3
    ▌CVSSv3(Common Vulnerability Scoring System v3.0)とは
    n 脆弱性の深刻度を数値化するための世界中で使われるシステム
    n CIAに以下の5項⽬を加え、計8項⽬で脆弱性を評価
    n 攻撃経路(AV):ネットワーク or 隣接 or ローカル or 物理
    n 攻撃の複雑さ(AC):低 or ⾼
    n 攻撃に必要な権限(PR):なし or 低 or ⾼
    n 被害者が操作を必要か(UI):不要 or 要
    n 影響の範囲(S):変更なし or 変更あり
    n 0.0 ~ 10.0 の101段階

    View full-size slide

  13. 脆弱性の原理と対策

    View full-size slide

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

    View full-size slide

  15. 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

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  21. DOM-Based XSS の例

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

    View full-size slide

  22. 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 full-size slide

  23. Trusted Types 例
    // サーバー側からtrusted typesの制限を課せられている

    <br/>const myPolicy = trustedTypes.createPolicy(“example”, {<br/>createHTML: (unsafe) => {<br/>/* 適切にエスケープされたsafe変数を⽣成する処理 */<br/>return safe;<br/>}<br/>});<br/>const txt = decodeURIComponent(location.hash.substring(1)); // ソース<br/>// エラー<br/>document.getElementById(“sample”).innerHTML = txt;<br/>// Trusted Typesを経由しているためエラーにならない<br/>document.getElementById(“sample”).innerHTML = myPolicy.createHTML(txt);<br/>

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

  29. セキュリティ機能
    ▌以下を指定することで特定のセキュリティ機能を付与できます。
    n X-XSS-Protection[補⾜3]
    n X-Content-Type-Options
    n X-Frame-Options
    n クリックジャッキングを防ぐ
    n Content-Disposition: attachment;
    n Strict-Transport-Security

    View full-size slide

  30. Cookieの扱い
    ▌Cookieを発⾏時に属性を指定することで扱いを制限することができる。
    [補⾜4]
    n Expires:絶対的な有効期限を指定
    n Max-Age:相対的な有効期限を指定
    n Domain:利⽤可能なホストを指定
    n Path:利⽤可能なパスを指定
    n Secure:HTTPSを利⽤しているときにのみ送信される
    n HttpOnly:jsなどからの呼び出し禁⽌
    n SameSite:リクエストもとに応じてクッキーをセットするかを指定

    View full-size slide

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

    View full-size slide

  32. お願い
    ▌脆弱性は極秘情報です。
    n 皆さんが配属され、各チームに関係のある脆弱性情報が⾒えるように
    なりますが、オープンな場(権限が付いてないレコードのコメントや⽇
    報・分報など)で再現⼿順に関する議論はお控えください。

    View full-size slide

  33. 参考資料/書籍
    ▌ 安全なウェブサイトの作り⽅
    http://www.ipa.go.jp/security/vuln/websecurity.html
    ▌ ウェブ健康診断仕様
    http://www.ipa.go.jp/files/000017319.pdf
    ▌ Webアプリケーション脆弱性診断ガイドライン
    https://github.com/OWASP/www-chapter-japan/tree/master/secreq
    ▌ OWASP チートシート
    https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
    ▌ 脆弱性診断スタートガイド
    ▌ 安全なWebアプリケーションの作り⽅

    View full-size slide

  34. 補⾜①
    [補⾜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の対策になります。
    また、SESSIONIDなどのCookieにSameSite属性を付与することでもある程度CSRFを防⽌できます。

    View full-size slide

  35. 補⾜②
    [補⾜3]
    現在では多くのWebブラウザで X-XSS-Protection の廃⽌の動きがあります。
    https://caniuse.com/?search=X-XSS-Protection
    ChromeはXSS Auditor (X-XSS-Protection が有効のときに動作するXSS検出機構)を削除
    https://www.chromestatus.com/feature/5021976655560704
    Firefoxはもともと対応していない
    https://bugzilla.mozilla.org/show_bug.cgi?id=528661
    EdgeはXSS filter を削除
    https://blogs.windows.com/windows-insider/2018/07/25/announcing-windows-10-
    insider-preview-build-17723-and-build-18204/

    View full-size slide

  36. 補⾜③
    [補⾜4]
    多くのセキュリティ機構はOriginをベースに設定されていますが、Cookieが提案された当初はOriginの考えが定着し
    ておらず、現在となってはCookieはやや特殊なセキュリティ境界を持っています。SameSite属性はOriginに近い考
    えを適⽤できますが、厳密には異なります。
    詳細︓
    https://tools.ietf.org/html/rfc6265
    https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07

    View full-size slide

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